Перевод статьи «Philosophy of a Good Developer».
Какого разработчика можно счесть хорошим? Конечно, ответ на этот вопрос лежит не только в технической плоскости, он гораздо шире. Даже если вы очень хороши по технической части, вы все равно можете быть плохим разработчиком.
В этой статье я буду делиться своими мыслями и выводами, к которым пришел, пробыв достаточно долго в роли менеджера продукта, программиста и технаря. Кому-то из вас некоторые пункты могут показаться очевидными, но они включены в этот список не без причины. И я уверен, что большинство читателей найдет в этом списке что-нибудь полезное для себя (так что не убегайте, правило № 6 важнее всех остальных).
Итак, давайте посмотрим, что же может сделать разработчика хорошим разработчиком.
Правило № 1. Не будьте волком-одиночкой
Работая над коммерческим проектом, перво-наперво следует усвоить, что ваш код это не просто ваш код. Его будут читать и проверять много других людей. И даже если прямо сейчас вы работаете над проектом в одиночку, в будущем все равно кто-нибудь будет читать ваш код и пытаться разобраться в нем.
Ваш код должен быть читаемым, причем не только для вас самого, но и для любого человека, который может присоединиться к работе над проектом в дальнейшем. Поэтому убедитесь, что вы:
1. Не используете идиотские имена переменных
Да, я знаю, что большинство из вас грешили чем-то подобным. Кому-то это может казаться безобидной шуткой, но на самом деле все иначе. Не используйте случайные имена: так делают только новички. Имя вашей переменной должно всегда ясно сообщать о ее назначении. Вы должны понимать, что ваш код предназначен не только для интерпретации компьютером, но и для чтения людьми.
2. Всегда используете комментарии
Определяя функцию, нужно не только выбрать ей подходящее имя, но и добавить комментарий. Конечно, не обязательно делать это повсеместно, но комментарии помогают более четко передать ваши намерения. Главное правило здесь — пишите комментарий, если он может сэкономить время другого разработчика, который будет пытаться разобраться в коде. Если разработчику, читающему код, приходится все время прыгать туда-сюда, пытаясь понять, что делает простая функция, это плохой код. Продумывайте результаты своих действий наперед и добавляйте комментарии в код при необходимости.
Использование генераторов документации вроде Jsdoc тоже может помочь. Они не только способны улучшить вид ваших комментариев, но и поддерживают такие замечательные функции IDE как предпросмотр определений.
О Jsdoc можно почитать в этой статье.
3. Делаете wiki проекта
Этот пункт часто игнорируют, и очень зря. Дело в том, что программирование это не линейный процесс. Пытаясь заставить что-нибудь работать, вы можете столкнуться с десятком проблем. И даже если это просто проблема с установкой MongoDB на вашу машину с Linux, запишите всю информацию, которая может помочь вашим коллегам в решении подобной проблемы (на случай, если они тоже с ней столкнутся).
Хорошо документированный код всегда имеет хорошо документированную wiki. Как запустить среду разработки, как использовать систему дизайна, как экспортировать переменные окружения локально — о чем бы ни шла речь, напишите wiki! Поверьте мне, это сохранит много времени вам и вашим коллегам. Вот пара ссылок, которые могут вам пригодиться в этом деле:
4. Правильно форматируете код
И последнее (но от этого не менее важное). Для упрощения форматирования я рекомендую пользоваться инструментами вроде prettier. Также можно включить функцию «форматировать при сохранении» — мне она очень нравится. Вот полное руководство, как это делается.
Помните, что работа над проектом это коллективный труд. Относитесь ко времени других людей бережно — применяйте на практике изложенные выше советы. Как сказал Нед Старк,
«Волк-одиночка погибает, а стая выживает».
Правило № 2. Вы не сможете запомнить всё
Вот представьте. Идет ваш обычный рабочий день, вы над чем-то трудитесь и вдруг замечаете: что-то (не то, над чем работаете в данный момент) сломано. Вы знаете, как это исправить, но вот прямо сейчас совсем не до того. Поэтому вы решаете вернуться к этому вопросу позже. Но так и не возвращаетесь.
Звучит знакомо? Ну, вот так уж устроен человеческий мозг. Вы можете представить его в виде RAM. Он помнит какие-то вещи, связанные с рабочим процессом, пока занят этим процессом, а потом стирает их из памяти. Вот поэтому нам нужно все записывать. Компьютеры сохраняют нужное на жесткий диск, и мы точно так же должны делать записи, если хотим позже что-то вспомнить. Кажется, что я говорю об очевидных вещах, но очень многие из нас все еще имеют проблемы с этим.
Записывание всех важных вещей имеет очень большое значение для создания отличного ПО, потому что позволяет вам сосредоточиться на текущей задаче, а при необходимости взглянуть на работу более широко. Больше об этом в п.6!
Использование TODO-комментариев очень эффективно. Они не только помогут вам вспомнить о необходимости заняться какими-то задачами, но и позволят вашим коллегам понять, что нужно сделать, если вдруг вы по каким-то причинам не сделаете этого сами.
Но если вы хотите подойти к делу серьезно, я рекомендую использовать такой инструмент как Todo Plus.
С его помощью можно как создавать список задач, так и отслеживать все свои TODO-комментарии в отдельном файле.
В общем, не держите все в своем дворце памяти: записывайте!
Правило № 3. Становитесь на место своего пользователя
Вы, разработчики, технически являетесь первыми пользователями вашего приложения. Ваша работа не ограничена написанием логики или созданием отдельных фич. Вы также должны убедиться, что созданные вами вещи пригодны к использованию.
Постоянно задавайтесь вопросом: «Если бы я был пользователем, смог бы я это использовать?» Ответ при этом всегда должен быть утвердительным. В первую очередь проверяйте весь функционал на соответствие вашим стандартам (у вас как разработчика эти стандарты и ожидания должны быть высокими). Не ждите, пока команда QA вручит вам список багов! Если вам сложно посмотреть на приложение с токи зрения пользователя, сядьте с менеджером проекта и разберитесь. И даже если вам не удастся охватить все полностью, все равно нужно стараться.
Это особенно важно для full stack разработчиков. Если вы хотите быть таковым не по должности, а по сути, вы должны уметь делать хорошо очень много разных вещей, включая UIX дизайн.
Правило № 4. Не срезайте путь
Многие лучшие подходы к разработке основаны на этом правиле. Я уверен, что у вас бывали ситуации, когда вам нужно было повторить какой-то кусок кода многократно, и вы просто копипастили его. В глубине души вы знали, что избыточность это не хорошо и, придерживаясь принципа разделения ответственности, вам, вероятно, следовало бы сделать из этого кода отдельную функцию. Но ваш ленивый мозг убедил вас, что на это уйдет много времени, и вы решили не заморачиваться. В конце концов, вы экономите время, которое можно потратить на создание новых фич, верно? Не верно! Поступая так, вы снижаете производительность приложения, а кроме того вам придется потратить куда больше времени на пересмотр и удаление излишнего кода. А это, уж поверьте мне, ужасно раздражает!
Если что-то делаете, делайте это хорошо!
Вы ежедневно будете сталкиваться со многими ситуациями, подобными этой, и у вас всегда будет два варианта на выбор: простой и правильный. Делайте все, как положено, не пытайтесь срезать путь.
Правило № 5. Не ищите виновных
Будучи менеджером проектов, я неоднократно сталкивался с тем, что когда что-то ломается, разработчики начинают показывать пальцами друг на друга. А это идет только во вред совместной работе.
Мы должны понимать, что разработка это командная игра. Если вы знали о существовании проблемы и не сделали ничего, чтобы исправить ситуацию, и даже просто не осветили эту проблему, вы тоже несете ответственность за случившийся сбой. Любой проект — ваш общий, все члены команды ответственны за него, так что в случае чего не ищите виновных.
В хороших командах люди понимают это на подсознательном уровне, и я видел, насколько хорошо у них все получается. Хорошие менеджеры стремятся внедрять этот подход в своих коллективах, а вот плохие движутся как раз в обратном направлении (но это отдельный разговор).
Правило № 6. Учитесь видеть крупный план картины
Это именно тот навык, который может выделить вас на фоне коллег. Конечно, работая, как все, вы конце месяца получите свою заслуженную зарплату. Но я призываю вас смотреть на вещи шире. Осознаете вы это или нет, но ваше имя ассоциируется с компанией, где вы работаете, и с продуктом, которым вы занимаетесь. Вы не просто пишете код, вы оставляете свой след.
Вам нужно искать возможность периодически делать шаг назад и пересматривать свой взгляд на вещи. Способность видеть картину крупным планом позволяет вам ориентироваться на миссию компании и работать над задачами, учитывая их значимость для достижения поставленных целей.
Ведь, в конечном итоге, если вы создаете никому не нужный мусор, то это на вашей совести. И наоборот, если ваше творение безупречно, это ваша заслуга.
Заключение
Чтобы стать хорошим разработчиком программ, нужны не только технические навыки. Если вы уделяете внимание только их развитию, это довольно низкий уровень. Нужно учитывать и другие вещи:
- Работая над коммерческим проектом, не следует действовать, как волк-одиночка: пишите читаемый код и документируйте все.
- Вы не можете помнить обо всем: делайте записи и используйте TODO-комментарии, чтобы иметь возможность позже вернуться к пропущенным вещам.
- Нужно ставить себя на место пользователя и создавать функционал, который люди смогут использовать. Прежде чем передать свой код QA, оценивайте его, руководствуясь собственными стандартами.
- Все попытки срезать путь идут только во вред. Так что старайтесь делать все правильно, а не быстро.
- Взаимные обвинения между членами команды, когда что-то пошло не так, ведут вас в никуда. Все члены команды несут ответственность за свой продукт.
- Программное обеспечение это нечто большее, чем набор функций. Старайтесь почаще охватывать взглядом крупный план ваших приложений. Ваши творения это след, который вы оставляете после себя.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]