От джуна до сеньора как стать востребованным разработчиком

Стиль

Один из важнейших элементов работы над кодом — стиль языка программирования, а точнее, следование стилю, предлагаемому авторами языка. В современном мире практически все языки программирования имеют свой guideline, который предписывает, как оформлять код, какими правилами нужно руководствоваться и как избежать типичных ошибок.

У каждого языка программирования своя специфика, область применения, особенности синтаксиса, и поэтому важно соблюдать единообразие в коде. Люди, долгое время работающие с одним языком программирования, читают его быстро и часто полагаются на визуальную интуицию. Они видели конструкции этого языка так часто, что могут заметить ошибку даже при беглом просмотре.

Если ваш код будет соответствовать стилю языка, на котором написан, это будет огромным плюсом и очень упростит жизнь и вам, и всем тем, кому придется поддерживать этот код в будущем.

Множество современных языков программирования имеет в своем составе специальные инструменты — linters, которые позволяют форматировать код, находить типичные ошибки синтаксиса и многое-многое другое. Регулярное использование этих

инструментов окупается тем, что код будет выглядеть предсказуемо и узнаваемо для любого человека, знакомого с данным языком программирования.

Однако из этого правила есть исключения. Большие (и не очень) компании часто могут отступать от стиля языка по тем или иным причинам: особенности использования синтаксиса языка, договоренность среди разработчиков, особенности ведения разработки (давайте представим, что все разработчики этой гипотетической компании работают на мониторах с разрешением, позволяющим без проблем вместить только 80 символов на строке. Кошмарный, ужасный случай).

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

Вы можете спросить у старших разработчиков, по какой причине был выбран именно такой стиль и насколько он актуален. Не исключено, что решение об отказе от guideline языка программирования было принято очень давно и требует пересмотра. В таком случае поздравляю вас, вы только что повесили на себя массу дополнительной работы по приведению кодовой базы в пристойный вид.

Тезисы

Guideline языка программирования важен, ознакомьтесь с ним как следует.

Правила проекта важнее, чем guideline языка программирования.

Linters — ваши друзья и помощники, используйте их.

Задание

Найдите linters для языка программирования, на котором вы пишете регулярно, или для того языка, который используется на вашем проекте. Проверьте ими код проекта и ужаснитесь, наскольковсеплохо(или, наоборот, порадуйтесь, какздорово работаетевыивашиколлеги). Попробуйтенайтипроблемные местаипредложитьисправитьих. Длявасэтобудетхорошим опытом работы с кодом проекта, а для проекта — полезным рефакторингом.

История из жизни

Наодномизсвоихпервыхместработыяписалfrontend дляразрабатываемыхсайтов, используяJavaScript. Наэтудолжность я устроился, уже имея некоторый опыт работы с JavaScript и(какмнеказалось) гениальныйметодформатированиякода. Боюсь, чтоуменянеосталосьпримеровтогосамогоформатирования (я очень рад, что все примеры утеряны), однако, увидевэтоткодгодспустя, янепростонеузналего, ноещеидолго ругался на автора, создавшего такую бестолковую мешанину изпробеловиотступов. Ксчастью(иликсожалению), память позволила мне воссоздать, как это выглядело. Узрите же!

if ( user.loggedIn ) { user.lastLogin=new Date();

sendNotifications( [

'Welcome home, '+user.name,

] );

if ( user.acl[ 'dashboard.view' ] || false )

{

nav.redirect( 'dashboard.view' );

}

}

Именование и здравая логика

Основа всех языков программирования — текст программы, способ изложения идей разработчика (привет, ассемблер). Поэтому невероятно важно сохранять читаемость текста программы, простоту его восприятия. Для авторов некоторых языков программирования удобство написания текста программы было большим приоритетом (да, Python, мы говорим про тебя). Авторы других языков, видимо, считали, что вы будете в восторге от обилия скобочек и палочек (да, Objective-C, мы в курсе, что ты в комнате).

Опираясь на guideline языка, вы должны следить, чтобы то, что вы пишете, соответствовало тому, что вы хотите сказать. Если вы заводите переменную sum, в которой храните текущую температуру в фаренгейтах, — поверьте, для вас уже разогревают котел в аду. Старайтесь соблюдать баланс в выразительности: переменная activeSessionsUsersWithGuestRole тоже вряд ли кого-то обрадует. Продуманные названия переменных, классов и функций облегчат жизнь не только вам, но и вашим коллегам.

В реальности код большого проекта расширяется так быстро, что хорошее, продуманное именование не поспевает за ним, но это не значит, что вы не должны уделять этому внимания.

Старайтесь делать по одной вещи зараз. Если вы пишете новый код, называйте элементы так, чтобы по ним можно было читать код как рассказ (или хотя бы как хокку). Если вы работаете с уже написанным кодом, будьте бдительны, потому что иногда переменная sum может оказаться указателем на открытый файл. Если вы уверены в своих силах, выделите немного времени и поправьте то, что выглядит нелогичным с точки зрения чтения кода.

Если вам кажется, что ваш код понятен, поставьте себя на место человека, который видит его в первый раз. Или хотя бы на свое место, если вам придется править этот код спустя 5 или 10 лет (да, такие вещи случаются). Хорошие названия — это инвестиция, которая окупается в долгосрочной перспективе. Не пожалейте минуты, чтобы назвать переменную правильно, и вам не придется тратить полчаса в будущем, чтобы понять, зачем она нужна.

Тезисы

Названияэлементовпрограммыдолжныбытьпродуманны и логичны.

Названияэлементовпрограммыдолжныбытьсбалансированы, без избыточности и излишней краткости.

Задание

Попробуйте «прочитать» код вашего проекта как текст, как роман, несосредотачиваясьнаегологике. Постарайтесьпонять по тексту, что должен делать тот или иной участок кода. Найдитенесколькосамыхзапутанныхинепонятныхмествтексте кода проекта. Подумайте, как вы могли бы упростить его, сделать понятнее при чтении.

История из жизни

Ксожалению, тотпример, которыйяпривелвтексте, — невымы- сел. Я действительно находил переменную sum, которая хранила температуру в фаренгейтах. Учитывая тот факт, что код находился в цикле агрегации данных, я потратил немало времени, преждечемпонял, чтоsum неявляетсясуммойвсехзаписейотемпературныхизменениях. «Спасибо» тебе, неизвестный разработчик. Этонесамыйстрашныйпримердурацкогоназвания переменной, и я готов дать руку на отсечение, что и сам именовал свои переменные довольно идиотским образом.

Повторное использование кода

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

Самое простое, что вы можете сделать, — скопировать код и перенести его в новое место (сделать Copy–Paste, как это называют в индустрии), заменив те части, которые того требуют. В этот момент вам следует остановиться, проверить КАЖДУЮ перенесенную строку и задать себе вопросы: будет ли эта строка работать в этой части проекта? Не нарушена ли логика кода? Все ли части скопированного кода имеют смысл в этом месте проекта? Исправили ли вы все комментарии, названия и связи в скопированном коде?

Копирование кода и дублирование считаются дурным тоном, однако в реальности этим занимаются все разработчики, дело лишь в том, насколько они внимательны и предусмотрительны.

Если вы внезапно поняли, что переносите один и тот же код слишком часто и теперь в разных частях проекта появляются одинаковые участки кода, — будьте настороже. Такие дубликаты

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

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

Однако будьте бдительны: при принятии решения о выделении кода в отдельную сущность (функцию, метод, компонент и т. д.) подумайте, будет ли этот шаг логичным и целесообразным. Если вы, к примеру, пишете код, вычисляющий hash, пожалуйста, удостойте его отдельной функции. Если же вы собираетесь создать компонент, который суммирует два числа, дайте процессору отдохнуть — просто напишите операцию сложения во всех местах, где нужно.

Тезисы

Copy–Paste — это нормально (прочь, критики).

Тщательно проверяйте скопированный код на его новом месте.

Есливыкопируетеодинитотжекодслишкомчасто, очень вероятно, что он требует отдельного места жительства, а не сотен копий по всему проекту.

Задание

Проверьте код вашего проекта и найдите места, в которых происходят очень похожие действия. Оцените аналитически, действительно ли эти места похожи и как бы они выглядели, еслибывырешиливыделитьэтоткодвотдельнуюсущность. Не торопитесь с рефакторингом этих мест. Достаточно того,

чтовынаучитесьвидеть, какименновыглядитдублирующийся код. Вместесэтимпридетиинтуитивноепонимание, когдакод стоитпростокопировать, акогдаондостоинтого, чтобыиметь свой собственный угол в проекте.

История из жизни

Как-торазмнепришлосьсоздатьфункциюдляблокакодадли- ной 10 строк, который дублировался на проекте 37 (sic!) раз.

Изобретение колеса

Деятельность разработчика часто заключается в том, что он пишет очень похожие решения для очень похожих задач. Это совсем не значит, что такую работу может делать робот, — ничего подобного (этим я успокаиваю не только вас, но и себя). Даже в похожих решениях найдутся требования, которые заставят вас искать новые подходы. Подходы, не позволяющие вам обрастать багажом уже написанного кода, который вы будете просто копировать в каждый новый проект.

Любая задача требует качественного решения, однако чаще всего на этапе декомпозиции вы увидите, что получившиеся мелкие части этой задачи представляют собой типовые проблемы, решения для которых вы писали уже много раз. Чем опытнее вы будете становиться, тем больше подобных типовых решений будете замечать и тем легче вам будет разделять задачу на составные части.

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