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

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

Вся система образования построена на том, что людям объясняют, как надо делать. Но один из лучших способов развиваться — это понять, как и почему делать не надо, и, отталкиваясь от этого, постоянно идти вверх. Об этом в своей колонке пишет Вячеслав Кацубо, Senior Android developer в neoviso.

Читать далее...

Я начал разрабатывать приложения для платформы 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.

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

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

Хотите сообщить важную новость? Пишите в Телеграм-бот.

А также подписывайтесь на наш Телеграм-канал.

Горячие события

Gismart Online Meetup
9 декабря

Gismart Online Meetup

Минск

Читайте также

10 айтишных профессий, которым можно не бояться AI и автоматизации
10 айтишных профессий, которым можно не бояться AI и автоматизации
10 айтишных профессий, которым можно не бояться AI и автоматизации
1 комментарий
Чего не хватает разработчикам для работы в период коронавируса? (исследование)
Чего не хватает разработчикам для работы в период коронавируса? (исследование)
Чего не хватает разработчикам для работы в период коронавируса? (исследование)
29 самых востребованных языков программирования и технологий разработки (+прогноз на 2 года)
29 самых востребованных языков программирования и технологий разработки (+прогноз на 2 года)
29 самых востребованных языков программирования и технологий разработки (+прогноз на 2 года)
1 комментарий
GitHub представил программу сертификации для разработчиков
GitHub представил программу сертификации для разработчиков
GitHub представил программу сертификации для разработчиков

Обсуждение

3

>>> К сожалению, очень часто джуниоры считают зазорным признать, что они чего-то не знают

Это проблема вообще всех. От уборщицы до главы компании и заказчика. Джуниор - как раз самый безобидный в этом плане, у него мало шансов использовать свое незнание во вред.

0

К сожалению, все чаще та же болезнь касается не только джуниоров)))

0

8 заповедей разработчика. Создаем библию айтишника на dev.by)

2

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

Тут я согласен и мне кажется уместным привести еще и такую аналогию/интерпретацию. Она из области классификации и распознавания объектов.

Предположим, есть 2 класса. Условно, Хорошие (с1) и Плохие (с2) объекты. Как известно, для обучения классификатора нам так или иначе нужно построить границу между классами в пространстве признаков. Добавление только лишь примеров класса с1 может сколько-то улучшать решение (всю внешнюю область считаем классом с2). Однако, никаких гарантий, что край области с1 и есть граница (марджин) нет и вероятность даже при очень большом числе (eg 10000000) представителей с1 может быть невысокой. Однако, стоит добавить совсем немного с2 и мы уже точно знаем -- что там не с1.

Идея не новая и не моя. Иногда называется "О пользе контр-примеров класса". Существует математическое доказательство (по крайней мере для случая бинарных пространств).

1

Судья это миллион юзеров проклинающих ваш «гениальный» дизайн и 50 мб бессмысленных фреймворков)

0

смищно же:)

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже