«Пять лет назад я был дураком. Через пять лет скажу то же самое». 8 (не)банальных советов от белорусского сеньора

Я начал разрабатывать приложения для платформы Android 1.1 восемь лет назад. Когда пришёл на собеседование, честно признался, что не умею писать под Android и iOS, но есть общие знания по программированию, понимание логики, алгоритмов. Мне сказали, что возьмут на испытательный срок в фирму, если за месяц начну писать под Android. Тогда только зарождалась индустрия мобильной разработки, поэтому был единственный способ чему-то учиться — читать документацию и пробовать. Наверное, поэтому до сих пор так ценю метод проб и ошибок.

Вот топ рекомендаций для программистов, которые хотят постоянно расти и осваивать новые технологии.

1. Бесконечно пробовать и делать ошибки.

Главное — не одни и те же дважды. Сделали проект, посмотрели, откуда вылезли баги, что не так реализовали, и больше не повторяем. На мой взгляд, ничто не заменит практику. Поэтому начинающего программиста очень полезно «бросить в реку» — в большой сложный проект, который обязывает постоянно искать что-то новое в коде программы, спрашивать у старших коллег, находить решения, применять их и таким образом наращивать профессиональные компетенции.

2. Не бояться спрашивать.

К сожалению, очень часто джуниоры считают зазорным признать, что они чего-то не знают. Когда я начинал, спросить было не у кого, на stackoverflow.com информацию искал по крупицам.

3. Прежде всего стараться понять, как делать нельзя.

Простая аналогия. Знание «как делать можно» — это потолок сверху. А понимание «как делать нельзя» — это опора снизу. Если человек знает, как нельзя, он постепенно методом проб и ошибок сам приходит к тому, как можно и нужно. Если же программист знает исключительно то, как можно, это его ограничивает в развитии, и в случае возникновения нестандартной ситуации, он впадает в ступор. Многие знанием «как нельзя» пренебрегают. Во всех школах говорят, как можно и нужно. А надо сказать, как нехорошо, посмотреть ошибочные варианты, потом уже продемонстрировать, как делать верно. Нам не потолки надо себе воздвигать, а постоянно идти вверх.

Из простых примеров: приходит человек на собеседование и хвалится, как много он знает. Прошу написать сортировку по возрастанию — её пишут. Меняю условие и говорю, что необходимо чётные позиции отсортировать по возрастанию, а нечётные по убыванию. В результате получаю ответ: «А нас такому не учили». Возникает вопрос, достаточно ли только впитывать те крохи, которые дают, или надо всё же учиться думать, опираясь на них.

4. Не рассчитывать исключительно на шаблоны и фреймворки.

Сейчас очень много библиотек с готовыми решениями. Но если человек привык пользоваться только чужими наработками, он теряется при малейшем отклонении от заданного пути. Раньше не было для Android готового решения для бокового меню, поэтому писали сами. Сейчас есть, но всё равно даже многочисленные готовые решения не всегда подходят под конкретные требования. Например, в очередном проекте попросили предусмотреть возможность открыть меню со всех четырёх сторон — пришлось самому писать.

5. Не воспринимать всё, что написано в книгах, как Отче наш.

И не переносить слепо на свои проекты, иначе вы перенесёте не только хорошие решения но и все подводные камни.

6. Регулярно слушать подкасты Google, читать habr.com, stackoverflow.com, официальный сайт Android, изучать исходники популярных библиотек на GitHub. Для начинающих могу порекомендовать startandroid.ru.

7. Не пытаться охватить всё сразу.

Теоретические знания обязательно должны быть подкреплены практическими. Поэтому как только что-то узнали, прочитали, сразу надо попробовать написать код и проверить, как он работает.     

8. Полезно составлять свои библиотеки, аккумулировать в них примеры решений наиболее часто встречающихся задач.

 Я последние года четыре после каждого крупного проекта вношу лучшие решения в свой «сборник полезностей» и активно им пользуюсь. Не считаю зазорным заглянуть в уже готовое — главное понимать, когда это уместно, а когда стоит пересмотреть свои взгляды. Моя личная библиотека уже переписывалась пять раз и получила немалое количество фиксов и доработок. На момент написания колонки происходит очередная доработка под новый проект github.com/vkatz/vkatz-lib/tree/dev.

Если взглянуть на то, что я писал пять лет назад, у меня будет единственная мысль — какой дурак это делал, можно было в десять раз лучше, почему так криво,  плохо и неудобно, где оптимизация?

Если вы посмотрели на свой код пятилетней давности и не задали себе похожих вопросов, возможно, вы что-то делаете не так.