Что еще очень важно для начинающего? Как он сам пишет код.
Можно дать такой совет
— Скачайте код проектов от известных компаний. Посмотрите примеры проектов для библиотеки Moxy, примеры проектов для API от крутых вендоров (Яндекс, Гугль). Посмотрите, как называются внутренние поля объекта, аргументы функций, сами объекты и классы. Обратите внимание на размер методов, на размер классов. Особое внимание — на то, на какие классы разбиваются разные задачи.
Подумайте, почему сделано так. Если не можете понять, почему — попробуйте просто повторить, попробуйте просто начать кодировать в таком стиле.
Идеальнее всего, конечно, применять такой совет на примерах от той компании, в которую хотите устроиться. Но можете брать примеры от лучших и известных разработчиков на GitHub.
Но следует добавить раздел «архитектуры MVP, MVC, VIPER», так как по ним спрашивают на собеседованиях сейчас практически всегда (термин VIPER используется при разработке под iOS, но в Андроиде недостающие компоненты в MVP (роутер, интерактор) в хороших проектах все равно реализуются, хотя и не называются именно так — поэтому понимание и нужно)
как сказал проект-менеджер на митинге в нашем отделе
— вы думаете, другие отделы в компании работают по хорошему ТЗ и документированному API?
Нет, у них еще хуже )
не нужно чертить прибор, нужно сразу его строить
не надо составлять ТЗ на программу — просто пишите ее!
не объявляйте interface, рубите сразу рабочие классы реализации
// игры не будут выглядеть так, как было задумано разработчиками
Это немного надумано. Я играю сейчас в старые игры на плоских мониторах, играю на карманных устройствах, играю на большом телевизоре — ни один из этих вариантов не вызывает ощущение «что-то не то» из-за экрана. Что действительно ломает аркадную игру — это не то управление. Идеально, когда есть джойстик со всеми кнопками, в которые можно уложит раскладку аркады. Обратный случай — просто сенсорный экран у телефона. Тут все ломается, никакие кнопки на экране не могут заменить нормальных живых клавиш, потому что и тесно, и не так они нажимаются по ощущениям.
А про ЭЛТ-экран — это какая-то религиозно-хипстерская ерунда про ламповость.
посмотрите игры вроде Minecraft, Forest, Rust — они примерно показывают, что можно делать безработному человеку в мире, где развиты инструменты для крафтинга
Этот совет годится для программистов, у которых уже есть какой-то бессознательный набор знаний, которые они могут применять. Для тех, кто программирует регулярно меньше года (или нерегулярно всю жизнь) — большая часть знаний находится пока в сознательной области, и «не думать» не получится
// Большой плюс робота в том, что если вы получили от него хороший кофе сегодня, то сможете попробовать этот же напиток и через год. В кафе, где работают бариста-люди, так не получится
Через месяц уже робот сгрузит патч, в котором операции с Float будут заменены на операции с Double или, еще лучше, с BigDecimal — и этого будет достаточно, чтобы изменить вкус.
Хотя я согласен, что робот будет заметно стабильнее, чем бариста. Но кроме патчей, не следует также еще забывать о том, что могут и будут меняться ингредиенты — как из-за смены поставщика, так и из-за смены экономической политики хозяина точки.
У нас в библиотеке университета стоит кофейный автомат — никто не мешает хозяину засыпать в него хороший кофе. Но естественно, он засыпает в него самый дешевый.
это означает не «заставить закон», а что-то сделать (заставить? стимулировать? какой глагол?) с исполнительными органами
исполнительные органы завалены работой, кадры сокращаются, не хватает рук даже на более тяжелые уголовные преступления
это означает, что закон изначально был сделан плохим как решение
это все равно что объявить в софт-компании — «Так, с завтрашнего дня вводим 100-процентное тестирование» при отсутствии тестировщиков и опыт test-drive development
Это плохое решение. Хорошее решение — давайте начнем проводить семинары по TDD и искать тестировщиков попутно. А пока введем не 100-процетное тестирование, а удлиним сроки разработки, которые будут соответствовать более реальным.
Решение должно быть минимальным, но достаточным для того, чтобы оно действительно что-то решало. Законы, которые опираются на то, чего нет — плохие законы. Они не работают. А вот решение, которое перенесло исполнение на достаточный и существующий аппарат — магазины — увы, оказывается рабочим. Поэтому оно работает. И работает с меньшими затратами, чем реформирование милиции или иного органа, который бы контролировал публичное распитие.
ассемблерные программы трудно поддерживать, развивать по функционалу и вообще изменять. После достижения некоей черты по мощности функционала, боюсь, программы вообще нереально писать на ассемблере.
Хотя я сам скучаю по тем временам, когда весь набор инструментов с операционкой и рабочими файлами мог поместиться хотя бы на 1 CD. Это было уже вполне себе время, когда можно было создавать и цифровые шедевры, и сложные офисные пакеты, не уступающие современным.
Моя любимая версия ACDSee — 2.3. Она уже 32-битная и, несмотря на то, что выпущена в 1998 году, до сих пор отлично выполняет свои функции на последних версиях Windows
интересно было бы еще как-то оценить собственно степень говно-кода у тех и у других
Можно дать такой совет
— Скачайте код проектов от известных компаний. Посмотрите примеры проектов для библиотеки Moxy, примеры проектов для API от крутых вендоров (Яндекс, Гугль). Посмотрите, как называются внутренние поля объекта, аргументы функций, сами объекты и классы. Обратите внимание на размер методов, на размер классов. Особое внимание — на то, на какие классы разбиваются разные задачи.
Подумайте, почему сделано так. Если не можете понять, почему — попробуйте просто повторить, попробуйте просто начать кодировать в таком стиле.
Идеальнее всего, конечно, применять такой совет на примерах от той компании, в которую хотите устроиться. Но можете брать примеры от лучших и известных разработчиков на GitHub.
Но следует добавить раздел «архитектуры MVP, MVC, VIPER», так как по ним спрашивают на собеседованиях сейчас практически всегда (термин VIPER используется при разработке под iOS, но в Андроиде недостающие компоненты в MVP (роутер, интерактор) в хороших проектах все равно реализуются, хотя и не называются именно так — поэтому понимание и нужно)
— вы думаете, другие отделы в компании работают по хорошему ТЗ и документированному API?
Нет, у них еще хуже )
не нужно чертить прибор, нужно сразу его строить
не надо составлять ТЗ на программу — просто пишите ее!
не объявляйте interface, рубите сразу рабочие классы реализации
Это немного надумано. Я играю сейчас в старые игры на плоских мониторах, играю на карманных устройствах, играю на большом телевизоре — ни один из этих вариантов не вызывает ощущение «что-то не то» из-за экрана. Что действительно ломает аркадную игру — это не то управление. Идеально, когда есть джойстик со всеми кнопками, в которые можно уложит раскладку аркады. Обратный случай — просто сенсорный экран у телефона. Тут все ломается, никакие кнопки на экране не могут заменить нормальных живых клавиш, потому что и тесно, и не так они нажимаются по ощущениям.
А про ЭЛТ-экран — это какая-то религиозно-хипстерская ерунда про ламповость.
расходимся
Через месяц уже робот сгрузит патч, в котором операции с Float будут заменены на операции с Double или, еще лучше, с BigDecimal — и этого будет достаточно, чтобы изменить вкус.
Хотя я согласен, что робот будет заметно стабильнее, чем бариста. Но кроме патчей, не следует также еще забывать о том, что могут и будут меняться ингредиенты — как из-за смены поставщика, так и из-за смены экономической политики хозяина точки.
У нас в библиотеке университета стоит кофейный автомат — никто не мешает хозяину засыпать в него хороший кофе. Но естественно, он засыпает в него самый дешевый.
исполнительные органы завалены работой, кадры сокращаются, не хватает рук даже на более тяжелые уголовные преступления
это означает, что закон изначально был сделан плохим как решение
это все равно что объявить в софт-компании — «Так, с завтрашнего дня вводим 100-процентное тестирование» при отсутствии тестировщиков и опыт test-drive development
Это плохое решение. Хорошее решение — давайте начнем проводить семинары по TDD и искать тестировщиков попутно. А пока введем не 100-процетное тестирование, а удлиним сроки разработки, которые будут соответствовать более реальным.
Решение должно быть минимальным, но достаточным для того, чтобы оно действительно что-то решало. Законы, которые опираются на то, чего нет — плохие законы. Они не работают. А вот решение, которое перенесло исполнение на достаточный и существующий аппарат — магазины — увы, оказывается рабочим. Поэтому оно работает. И работает с меньшими затратами, чем реформирование милиции или иного органа, который бы контролировал публичное распитие.
Увы.
OS/360 мы обязаны книгой «Мифический человеко-месяц» ))
Хотя я сам скучаю по тем временам, когда весь набор инструментов с операционкой и рабочими файлами мог поместиться хотя бы на 1 CD. Это было уже вполне себе время, когда можно было создавать и цифровые шедевры, и сложные офисные пакеты, не уступающие современным.
Моя любимая версия ACDSee — 2.3. Она уже 32-битная и, несмотря на то, что выпущена в 1998 году, до сих пор отлично выполняет свои функции на последних версиях Windows
Тут остается лишь продумать схему — «как быстро разрабатывать оригинальное и странное», потому что большинство из оригинального просто не зайдет
Это все равно, что арестовать памятник или высечь море.
Если решение плохое — нельзя заставить его «быть хорошим»