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

Hello, world! После того, как вы выучили всё необходимое и наконец попали на работу стажером или джуниором, наверное, можно расслабиться, правда? Как бы не так! Всё только начинается… Вокруг вас много нового и непонятного, и как не напортачить вот так с порога? Вот об этом сегодня и поговорим. В данной статье я хочу разобрать распространённые ошибки новичков и дать несколько советов из собственного опыта по их избежанию.Итак, начнем же без лишних предисловий:

1. Страх обратиться за помощью к более опытным коллегам

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

2. Не пытаться искать информацию самостоятельно

Пожалуй, данная ошибка является обратной стороной предыдущей. Я имею в виду, когда вы при каждой проблеме или затыке начинаете дергать ваших коллег и знакомых. Спрашивать — это хорошо, но и с вопросами не нужно перегибать, иначе можно просто надоесть. Первое, что нужно делать, если всплыл какой-то непонятный момент — применять свои поисковые навыки в лучшей системе поиска — Google. С подавляющим большинством непонятных ошибок и прочих моментов кто-то уже сталкивался. И вы будете изрядно удивлены, погуглив и увидев количество людей, которым знакома аналогичная проблема, и которые уже получили исчерпывающие ответы, пригодные для использования в работе. Исходя из этого, нередко можно услышать от коллеги ответ на какой-то вопрос — “Погугли”. На этот ответ не стоит обижаться, ведь всё же ваш коллега не личный учитель, который должен донести все тонкости вашей области работы. В таком наставничестве вам помогут безграничные просторы интернета. Иногда программиста ещё называют человек с чёрным поясом по google поиску. Поэтому при “затыке” в первую очередь гуглим проблему, и если решение найдено не было (редко, но бывает), тогда уже начинаем спрашивать коллег. Спрашивать их сразу стоит скорее не при каком-то затыке или непонятной ошибке, а при выборе подхода для решения какой-то задачи. Ведь они могут видеть дальше вашего и сразу сказать, чем тот или иной подход может обернуться в долгой перспективе.

3. Слепой копипаст

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

4. Бросать неверное решение

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

5. Страх задавать вопросы о текущем задании

Работа на проекте как правило сводится к выполнению некоторых задач (Tasks). Например, в Jira. И эти задачи не всегда подробно и доступно описывают. Их пишут как правило тимлиды, и это тоже люди, если что. Они тоже могут что-то забыть дописать или не учесть, что вы мало знакомы с тем или иным функционалом. Ну или у вас нет каких-то доступов по проекту (например, доступ к Базе данных, к серверу логов и так далее). И вот, получив задачу, поизучав ее уже более чем пару часов, вы всё так же сидите и недоуменно смотрите на экран. И вместо того, чтобы продолжать безрезультатно разбираться в этом, вам стоит начать задавать наводящие/уточняющие вопросы создателю данной таски. Скажем, в приложении, которое вы используете для коммуникации в команде (например, Microsoft Teams) или непосредственно комментарием под данной таской. С одной стороны, если вы напишете вопрос в личку, скорее всего ответ будет более быстрым, так как человек увидит вопрос сразу. С другой же стороны, задавая вопрос в Джире, у вас есть свидетельство того, что вы что-то делаете, а именно — разбираете задачу. Есть способ ускорить этот процесс: задать вопрос комментом в Джире и в личку сбросить ссылку на этот комментарий с просьбой посмотреть.

6. Слишком большие надежды на тимлида

Опять же, это обратная сторона предыдущего пункта. Тимлид — это человек, который является главным в какой-то команде разработчиков. Как правило большая часть времени такого члена команды уходит на различного рода коммуникации. И при этом он ещё и пишет код, чтобы не забывать, что это вообще такое. Ну, как вы поняли, это ну очень занятой персонаж. И излишнее дерганье по каждому чиху явно его не обрадует. Представьте, если каждый член команды будет его засыпать кучей вопросов. Так можно и рехнуться, не правда ли?И не будет удивительно, что при множестве вопросов с вашей стороны он будет вам долго отвечать. Что же можно предпринять, чтобы сократить количество вопросов тимлиду:

• Более глубоко изучить документацию данного проекта, чтобы уменьшить количество белых пятен.
• Задавать вопросы остальным членам команды. Вполне возможно, они знакомы с данным функционалом не меньше лида, а то и больше, ведь скорее всего тот функционал писал кто-то из них.

Как вариант, в IDE можно смотреть аннотации: кто и когда последний раз изменял код в определенной строке. Таким образом мы и выясним, кому наиболее правильно будет задать данный вопрос. Как вы уже наверное поняли, в вопросах тимлиду, как и в вопросах коллегам, нужно стараться держать золотую середину — не бояться задавать вопросы, но и не доставать их чрезмерным количеством.

7. Боязнь code review

Code review или обзор кода — это такой себе этап перед заливкой кода в общее приложение (в общую ветку, например — master или dev). Данную проверку проводит разработчик, не имеющий отношения к этой таске, который может свежим взглядом обнаружить, ошибки, неточности или недоработки в code style, которые остались незамеченными в начальной фазе разработки. Если замечания есть, они оставляются комментариями к определенным участкам кода. В таком случае разработчик, выполнявший эту таску, должен исправить ошибки согласно ревью (или обсудить свои решения с ревьюером, возможно, убедив его в правильности своего решения). После — снова отправить на ревью, и так до тех пор, пока у ревьюера не будет замечаний. Ревьюер служит “фильтром” перед заливкой кода. Так вот, многие начинающие программисты воспринимают code review как критику и осуждение. Они её не ценят и боятся, и это неправильно. Именно код ревью, позволяет нам улучшать наш код. Ведь мы получаем важные сведения о том, что мы делаем не так и на что стоит обратить внимание. Необходимо смотреть на каждое код ревью как на часть обучения, на то, что может помочь стать лучше. Когда человек оставляет комментарии к вашему коду, он делится с вами своим опытом, своими best practices. Как по мне, нельзя стать хорошим программистом без получения code review. Потому что ты и не знаешь, насколько твой код хорош и есть ли там косяки с точки зрения опытного человека со стороны.

8. Склонность к заумным решениям

Часто различные задачи/проблемы могут иметь несколько различных путей решения. И из всего доступного множества решений новички как правило применяют наиболее сложные и “заумные”. И ведь правда: если начинающий программист буквально вчера изучил множество различных алгоритмов, паттернов, структур данных, то у него руки так и чешутся внедрить какой-то из них. Да и хочется, так сказать, заявить о себе. Поверьте, я сам был таким и знаю, о чём говорю :) Была у меня ситуация, когда я долго писал один функционал, который вышел весьма и весьма сложным. Потом его переписал разработчик уровня Senior+. Конечно же, мне стало интересно посмотреть, что и как он переделал. Просмотрел его реализацию и изумился, насколько она стала проще. Да и кода стало меньше раза так в три. И при этом тесты на данный функционал не изменились и не упали! То есть, общая логика осталась всё та же. Из этого я сделал для себя вывод, что: самые гениальные решения всегда простые. После этого осознания писать код стало намного проще, и он ощутимо стал более высокоуровневым. Ну тогда когда же стоит тогда применять паттерны и алгоритмы, спросите вы? Тогда, когда применение их и будет самым простым и компактным способом.

9. Изобретение велосипедов

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

10. Не писать тесты

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

11. Чрезмерное комментирование

Многие разработчики страдают перфекционизмом, и новички в этом случае не исключение. Вот только побочка этого стремления иногда заключается в том, что они начинают комментировать всех и всё. Даже то что не нужно, ибо так очевидно:

Cat cat = new Cat(); // cat Object

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

12. Плохие именования

Часто новички фальшивят с наименованиями классов, переменных, методов и т. д. Например, когда создают класс, имя которого совершенно не описывает его предназначение. Или создается переменная с коротким именем, что-то вроде x, и когда создаются еще две переменные с именами n и y, вспомнить, за что отвечает x, становится очень трудно. В таких случаях приходится тщательно вдумываться в код и под микроскопом (возможно, с использованием дебагера), изучать данный функционал, чтобы просто понять, что там такое происходит. Тут нам на помощь и приходят правильные именования в коде, которые я упомянул выше. Правильные названия улучшают читабельность кода, соответственно экономя время на ознакомление, ведь гораздо проще использовать метод, в котором название приблизительно описывает его функционал. В коде все состоит из названий (переменные, методы, классы, объекты файлы и т. д.), этот пункт становится весьма важным при создании правильного, чистого кода. Стоит помнить, что имя должно передавать смысл: почему, например, переменная существует, что она делает и каким образом используется. И ещё не раз отмечу, что лучшим комментарием для описания переменной служит ее правильное имя. Для более глубокого изучения комментариев и правильных именований советую почитать нестареющую классику: ”Чистый код. Создание, анализ и рефакторинг”, Роберт Мартин. На этой ноте, первая часть данной статьи (размышлений) подошла к концу. Продолжение следует…