Разбор типичных ошибок начинающих программистов: часть 2

Всем снова привет! Мы продолжаем рассматривать проблемы, с которыми может столкнуться молодой и неокрепший программист на своей первой работе. С первой частью можно ознакомиться вот тут.Продолжаем:

13. Несоблюдение стиля написания кода

На проектах как правило поддерживается один стиль написания кода. То есть, разные разработчики следуют неким писанным или неписанным правилам, чтобы их код не отличался от других. Не нужно пытаться как-то выделиться с помощью своеобразного стиля написания кода: плюсиков это на ваш счёт не добавит. Если вы новенький на проекте, вам стоит сразу узнать, есть ли какая-то документация, описывающая общий подход к стилю написания кода. Возможно, есть некоторые файлы стиля под конкретно ваш проект, которые нужно попросить сбросить и импортировать в среду, в которой вы работаете (например IntelliJ IDEA), чтобы она уже могла в свою очередь делать подсказки согласно заданному файлом стилю. К примеру, в стиле будет прописано использование модификатора final везде, где это возможно, и IntelliJ IDEA будет выделять желтым переменные, в которых это не соблюдается.

14. Падать духом из-за ошибок

Ошибки — это то, с чем вам придется свыкнуться. Они были, есть и будут. Не важно, новичок вы или серьёзным архитектор, ошибки будут с вами всегда. Возможно, их уровни и количество изменятся, но они будут сопровождать вас всю последующую карьеру. Бывает, что у тебя всю неделю что-то не получается, падает какая-то ошибка, и вот уже вечер пятницы, и ты как побитая собака ползешь домой, так и не починив ту чертову ошибку. Непередаваемое чувство( Но это не то, из-за чего стоит падать духом. Ведь ещё одно важное отличие опытного разработчика от новичка — отношение к ошибкам. Опытные специалисты не принимают их близко к сердцу, а расценивают скорее как опыт. И никто не будет вас ругать за ошибку: это нормально, все через моменты затыка проходят. Опять же, вы можете попросить помощь у коллег. Также не нужно забывать о таких ребятах как проджект менеджеры (ПМ). Если вы над чем-то крепко зависли, сразу нужно писать проджекту. Он может помочь с поиском человека, который спец в этой области. Да и вообще его нужно держать в курсе ваших проблем на проекте. Это его работа — помогать решать разного рода проблемы, помимо коммуникаций и взаимодействий между членами команды. Подводя итог: ошибки — это нормально, не убивайтесь из-за них, а принимайте как вызов вам и вашим навыкам, ведь в конце концов это всего лишь часть работы.

15. Отсутствие четкого плана

Ничто хорошее не создаётся с легкостью. Любой разработчик должен понимать: чтобы написать определенный функционал, будь то модуль или всего лишь метод, нужно спланировать, что и как будет сделано. Как правило в разработке функционала любой сложности нужно придерживаться следующего порядка действий:Многие ошибки, которые возникают в коде начинающих программистов, касаются какого-то из пунктов этого порядка действий. Конечно, не стоит исключать, что есть моменты, когда нужно без раздумий бросаться писать код, только увидев таск. Но как правило это работает только для каких-то незначительных задач и методов, решение которых очевидно и не требует особых размышлений. Вышеизложенное правило разработки больше подходит для сложных и крупных задач, которые можно разделить на подзадачи. Браться за написание кода без ясного понимания, что ты хочешь написать, не очень хорошая идея. Сперва нужно всё тщательно обдумать, спланировать. Также полезно взять лист бумаги и карандаш и попытаться визуально отобразить свои идеи реализации (постоянно так делаю при планировке сложного функционала). Большую часть времени у программиста забирает не написание кода, а обдумывание структуры необходимого функционала. Ведь когда ты уже все спланировал и обдумал, написать код — это чисто механическое действие без каких-либо трудностей.

16. Перерабатывание

Пожалуй, каждый новичок думает, что если он будет работать до ночи, он начнёт справляться лучше со своими задачами и быстрее, так сказать, въедет во всё. Я тоже раньше так думал, но сейчас это не так. Я заметил такой момент: наступает какое-то время, какой предел, переступив за который ты уже перестаешь адекватно мыслить. Ты начинаешь изрядно тупить, залипать и делать по часу те вещи, которые мог бы сделать за 10 минут на свежую голову. И как правило, после пересечения этой черты усталости ты утыкаешься в какую-то проблему, которая кажется непреодолимой. Но придя утром на работу ты её решаешь в мгновение ока. Так вот, когда вы чувствуете что достигли этой точки, не сидите допоздна, а просто идите домой и хорошенько отдохните. Ведь если просидеть до поздней ночи, особо выдающихся результатов за эти часы мучений вы уже не достигнете, но при этом рискуете плохо (мало) отдохнуть перед следующим рабочим днем и запороть ещё и его. Подумайте о здоровье: стоит ли вот так в начале своей карьеры его подрывать? Я думаю, что нет. Нынче дорого болеть. Также подумайте о работодателе. Перерабатывая, вы делаете хуже не только себе, но и ему. Кому нужен вечно невыспавшийся сотрудник, который от усталости не может реализовать простейшую сортировку? Да, несомненно, бывают моменты, когда дедлайн горит, все пошло не так и вот это мое любимое — «надо было ещё вчера». Но как правило такие ситуации редкость, да и после них нужно сесть и тщательно обдумать, как это вообще могло получиться и как этого избежать в своем будущем.

17. Пренебрежение английским

Многие начинающие разработчики ставят изучение технологий на первое место, а английский — как-нибудь на потом. Это серьезная ошибка, так как довольно часто программист идеально подходит на рассматриваемую позиции джуна (или стажёра), но его не берут из-за слабого английского. Да, несомненно, есть случаи, когда можно пройти и без английского. Как правило таких людей берут под проекты на внутреннем рынке. Но локальные компании платят не такие же деньги за разработчиков, что и зарубежные. И выбить приличный рейт даже со временем будет очень и очень сложно. Поэтому английский язык не стоит упускать, чтобы сразу ориентироваться на англоязычные проекты, а не откладывать их в долгий ящик. Ведь если задуматься на минуточку, сейчас английский язык — это язык международного общения. В какую страну вы бы ни поехали, вы сможете находить общий язык с людьми, если знаете английский. В проектах так же. Не важно, какой это будет проект: немецкий, австралийский, французский или какой-то другой, всё равно вся коммуникация, все таски, документация и прочее будут на английском. Ну а если на секундочку задуматься, ведь это же весьма удобно, не так ли?

18. Погоня за модными технологиями

Начиная свой путь, разработчики часто пытаются угнаться за освоением новейших технологий. Правильно ли это? С одной стороны, да: новейшие технологии, проекты… Но стоит ли делать это главным приоритетом? Возможно, лучше поднажать на “классический набор” специалиста вашей области? Ведь новое — это конечно хорошо, но нужно не забывать об основополагающих технологиях вашего направления. А уже только потом, после того как вы немного обрастете опытом и глубокими знаниями основ, можно пробовать что-то новое. Учтите еще, что новые технологии имеют превосходство в одних нюансах, но при этом проигрывают в других. И до тех пор, пока у начинающего разработчика не будет понимания этих особенностей, лучше использовать проверенные временем решения. К примеру, если программист разрабатывает приложение, которое взаимодействует с некоторыми данными, то не стоит спешить использовать самое последнее NoSQL-решение только потому, что это в моде. Скорее всего подойдет и обычная SQL база-данных (MySQL, PostrgreSQL..), которая давно проверена временем, имеет подробную документацию и решения всех проблем на StackOverFlow :)

19. Изучение множества технологий или нескольких языков сразу

Выше мы говорили об освоении модных технологий новичками. А как обстоят дела с изучением множества технологий или нескольких языков сразу? Вы явно слышали о программистах, знающих более одного языка программирования и владеющих множеством технологий. Но я поспешу заметить, что эти люди далеко не новички в программировании. Это люди с большим количеством лет опыта за плечами. Они уже успели стать мастерами в своей изначальной технологии, и пошли дальше и дальше. Что же до новичков, пытающихся освоить всё и сразу, здесь отлично подходит пословица: “за двумя зайцами погонишься — ни одного не поймаешь”. Последствием может быть то, что вы ни одно направление не освоите хорошо, а только по вершкам пробежитесь. Более востребованным будет специалист, который глубоко знает один язык, нежели все, но по чуть-чуть. Поэтому если вы хотите знать множество языков и технологий, к этому нужно подходить с умом. Для начала у вас должен быть базовый, основной язык, который нужно глубоко изучить. И только потом, отталкиваясь от него, изучать дополнительные направления. Например, стать гуру по Java, потом изучить Python как вспомогательный язык, после можно и изучить что-то с фронтовой части react/angular. В таком случае эти технологии не взаимозаменяемые, как например C# и Java, а дополняющие друг друга, расширяющие ваши карьерные возможности. Но опять же повторюсь: не стоит пытаться учить всё сразу, нужно последовательно. Так сказать, ловить зайцев по одному.

20. Неправильно поставленные цели

Как вы ставите себе цели? Стать крутым разработчиком? Запомните раз и навсегда: цели нужно ставить физические, или другими словами — достижимые. О чём говорю? К примеру, вы ставите себе цель: хочу стать богатым. И как вы поймете, что вы уже достигли эту цель? Или как вы измеряете, насколько вы стали к ней ближе? Ну а если вы поставите цель “хочу заработать миллион” — это уже немного понятнее, не правда ли? Заработав 10 тысяч, вы станете на 10 тысяч ближе к своей цели, и вам останется 990 тысяч. Впереди немало, но зато вы можете пощупать свой прогресс и понять, где находится финишная черта вашей цели, и это вам и не даст опустить руки. Что касается карьеры, как насчёт того, чтобы поставить себе более ощутимую цель? Например: хочу стать тимлидом. Или сеньором. Ну или архитектором, в конце концов. Ну а большую задачу нужно разделить на маленькие подзадачи. Вы же не станете тимлидом вот так с порога карьеры. Ставьте сроки, если это возможно и уместно, и фокусируйтесь на текущем этапе.

1. Если мы говорим о становлении сеньором, то первой маленькой целью будет найти работу джуниором или стажировку в компанию.
2. Далее в качестве целей можно ставить углубление знаний в определенных технологиях. В Java — подготовка к сертификации Oracle первого уровня. Ставим себе срок на подготовку и идём к цели.
3. После, к примеру, можно задаться целью подтянуть английский на один уровень (скажем, с B1 до B2). Составляем план подготовки, планируем время и движемся к цели.

И так, шаг за шагом (параллельно получая опыт в разработке) мы и можем достичь нашей конечной цели.

21. Теория без практики

Неоспорим факт, что изучение новых технологий, углубление в уже изученные — это то, что делает нас лучше в качестве профессионалов в своей области. Но в начале пути разработчики редко осознают, что поглощение технических книг одну за другой не несет огромной пользы, если новые знания не будут испытаны на практике. Я сам не раз на это натыкался. Бывало так, что убьешь кучу времени на какую-то книгу, но при этом не практикуешь ничего из неё, и почти все новообретенные знания забываются: остается лишь общее смутное воспоминание о том, как всё примерно работает. Итог — куча потерянного времени без ощутимого результата. Зачем нам тратить время впустую? Жизнь-то не бесконечна. Поэтому когда изучаете новую технологию, не зацикливайтесь на теории: параллельно пишите приведенные примеры, экспериментируйте с новой технологией, и только так у вас что-то закрепится в голове. Да, скорость потребления новых материалов изрядно просядет, но при этом качество усвоения возрастет в разы. Ну и если освоить одну технологию хорошо, следующие будут усваиваться уже проще (как и с изучением языков).

22. Излишний перфекционизм

Большая часть разработчиков — перфекционисты: люди, которые стремятся к идеальности. А значит, их код тоже должен быть идеальным. И вот код уже написан, протестирован, отредактирован и вроде бы пора уже заливать его в общую ветку. Но создателю всё равно ещё код не нравится, и он начинает его и так, и так перекручивать, тратя на это большое количество времени. Ну а время в этом случае — деньги клиента. Начинающие программисты больше подвержены этому стремлению к совершенству. Опытные разработчики уже привыкли к чувству, что код идеальным никогда не будет, и что нужно стараться его написать лучше, но при этом не перегибать в стремлении приблизиться к идеалу. Так, что запомните: нужно научиться держать золотую середину, и не как-нибудь на скорую руку, но пытаться воссоздать Мону Лизу в коде.

23. Не думать об архитектуре

Опять же скажу: не стоит всё делать лишь бы как. Помимо читаемости и быстродействия, нужно думать и о том, как ваш код может повлиять на остальное приложение в целом. Насколько сложно будет расширять ваш код и так далее. Дело в том, что новички в силу нехватки опыта могут сразу и не заметить, как их новый функционал повлияет на приложение в будущем. Для этого несомненно нужно много практики. Но что же тогда делать новичкам? Не кодить? В таких случаях нам на помощь и приходят различный парадигмы праграммирования. Как вот например S.O.L.I.D. или различные паттерны программирования, которые могут вам донести полезные практики. К этим парадигмам тоже следует относиться с осторожностью и не перебарщивать. И как же определить степень перегиба? Тут как раз вам и поможет код ревью от более опытного коллеги, который, посмотрев со стороны, сможет вас направить в нужную сторону.

24. Синдром самозванца

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

25. Редко делать коммиты

Запомните: коммиты нужно делать часто! Ну, не каждые полчаса, но если у вас стоит задача реализовать функционал, который вы пишете неделю, то это должен быть не один коммит в пятницу вечером, а к примеру пять коммитов. Практически любую большую задачу можно условно разбить на задачи поменьше. И вот выполнение этих задач поменьше вы и коммитите. Да, и не забывайте эти коммиты сразу заливать на удалённый сервер. Иначе вы можете всю неделю делать коммиты, и к примеру в пятницу в обед что-то случается с вашим компьютером, и вот целая неделя насмарку! А если вы делали коммиты на удалённый сервер, просто с другого компьютера стянете ветку с последним коммитом и продолжите работу. И ещё одно: не выкладывайте новый функционал в работающий продакшн сервер в пятницу вечером. Просто поверьте. Оно вам не надо. Это чревато тем, что могут вылезти неожиданные ошибки, за фиксингом которых вы проведете свои выходные. А это не весело. На выходных нужно отдыхать. На этом, пожалуй, на сегодня всё. P. S. Последний совет: пишите много кода. P. S. S. Пишите БЕЗУМНО много кода, ведь только так можно набраться столь необходимого опыта.