Советы Junior-разработчикам

AppTractor

2 года назад

В этой статье упоминаются и даются ссылки на множество ценных концепций, которые вы можете исследовать дальше по своему усмотрению. Она состоит из трех разделов:

Общие советы — важный контекст и мотивация для технической части.
Технические советы — основной курс
Рекомендуемая литература — ссылки на качественные книги и блоги, которые отлично подходят для начала работы

Общие советы для Junior-разработчиков

1. Код не главное

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

Приложите разумные усилия, чтобы убедиться, что вы решаете правильную проблему. Цитируя Питера Друкера:

Нет ничего более бесполезного, чем эффективно делать то, что вообще делать не следует.

Собирайте отзывы заранее, лучше путем непрерывной доставки реальным пользователям. Будьте Agile.

Разработка программного обеспечения стоит дорого, и подавляющее большинство усилий в реальных проектах обычно уходит на обслуживание. Объедините это с получением результатов для пользователей/бизнеса, лучший код — это часто отсутствие кода. Цитируя Билла Гейтса: «Измерение прогресса программирования по количеству строк кода похоже на измерение прогресса в самолетостроении по весу».

Смотрите также: YAGNI, KISS, Последний ответственный момент.

2. Дизайн программного обеспечения имеет значение

В течение первых 5 лет моей карьеры разработчика я думал, что дизайн программного обеспечения предназначен для архитекторов программного обеспечения или других людей с особыми ролями. Я был сосредоточен на том, чтобы «делать дело», и рассматривал дизайн программного обеспечения и такие практики, как написание тестов, в лучшем случае как отвлечение. Мой код работал, и я делал много вещей. Или я думал, что их делал.

Затем я прочитал «Чистый код» Роберта С. Мартина. Эта книга мотивирует заботиться о дизайне программного обеспечения и содержит примеры и множество технических эвристик. Самый концептуальный вывод — это высказывание о том, что «единственный способ двигаться быстро — это двигаться правильно». Другими словами, если вы устроите беспорядок, это замедлит вас.

См. также: Tradable Quality Hypothesis, Design Stamina Hypothesis

Обучение тому, как писать хорошо спроектированный чистый код, конечно, требует времени и усилий. И когда вы начнете, вы будете медленнее и будете делать ошибки. Проще не значит легче.

3. Используйте ЛУЧШИЕ практики

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

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

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

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

Технические советы для Junior-разработчиков

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

4. Пишите тесты

Пишите автоматические тесты. Возможно, напишите тесты перед кодом, например, с помощью Test Driven Development (TDD). Это упрощает повторную проверку правильности кода, тем самым избавляя вас от многократных ручных проверок и сеансов отладки.

Вы думаете, что test-first — это сложно? Попробуйте debug-after.

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

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

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

5. Не используйте наследование для повторного использования кода

Это одна из тех лучших практик, которые напоминают раздел «Использование лучших практик». Мой совет: вообще не используйте наследование для повторного использования кода, когда вы только начинаете. Это редко бывает правильным решением и может принести много вреда. Предпочтите композицию наследованию.

6. Пишите объектно-ориентированный код

Пишите SOLID код, который не является STUPID. Понимание этих принципов и антишаблонов очень ценно.

На самом деле создавайте объекты. Классы только со статическими методами не являются объектно-ориентированными. Старайтесь вообще избегать использования статического кода.

7. Пишите функциональный код

Функциональное программирование не следует путать с императивным структурным программированием.

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

8. Используйте информированное дублирование

Копировать и вставлять большие куски кода в несколько мест почти всегда неразумно. Любой уважающий себя разработчик вскоре узнает об этом и начинает следовать той или иной форме Don’t Repeat Yourself (DRY). К сожалению, стремление к DRY с благими намерениями часто приводит к излишней инженерии и случайной сложности. Вот тут-то и появляется аналог DRY: пиши все дважды (WET). Идея WET заключается в дедупликации только при третьем дублировании.

Более подробно о затратах и преимуществах дедупликации см. в статье «Заблуждение DRY».

9. Типы, имена и комментарии

Старайтесь писать самодокументируемый код и избегайте комментариев.

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

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

Чтобы написать самодокументирующийся код:

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

В «Чистом коде» Роберта К. Мартина есть несколько хороших практических правил именования и комментариев.