Перевод статьи «How to Write a Good Piece of Code».
Для начала нужно убедиться, что ваш код в принципе может быть хорошим. При этом первый и, вероятно, самый важный шаг – попробовать вообще обойтись без написания кода.
Ответьте себе на следующие вопросы:
- Вы проверили все свои предположения и допущения?
- Каковы границы вашего кода?
- Как ваш код повлияет на существующую кодовую базу?
- Может, кто-то уже написал этот код?
Если у вас есть ответы на эти вопросы, это хорошая основа для написания качественного кода.
Обсуждайте свои решения с коллегами
Лучший способ проверить свой выбор – привлечь к делу других людей. Стремитесь работать в такой рабочей обстановке, где люди не боятся обсуждать решения и идеи.
Даже в самой крепкой стене можно найти слабое место, если посмотреть под правильным углом.
Разбивайте ваш код
Теперь, когда вы уверены, что ваш код в принципе может быть хорошим, пришла пора разобраться, как же его таковым сделать.
Старайтесь разбить ваш код на как можно более мелкие части. Именно с пониманием того, как это сделать, возникают наибольшие трудности у джуниоров. Помните, что если вы разобьете свой код, с каждым отдельным его кусочком вам смогут помочь. А если оставите его в монолитном состоянии, это отделит вас от команды потенциальных помощников.
Первая фаза проектирования кода редко должна быть связана с реализацией. Вместо этого вам нужно разобраться с нуждами и ограничениями. Время, потраченное на реализацию на этом этапе, зачастую потрачено зря, потому что высокоуровневые изменения API могут пойти вразрез с допущениями в реализации. Исходя из своего опыта, могу сказать, что если API уже согласован, это делает обсуждение реализации намного более гладким.
Пишите тесты до написания кода
Вы уже знаете, что код нужно разбивать на отдельные модули. Для каждого определенного вами модуля следует писать тесты.
Написание тестов для каждого кусочка кода или каждой части функционала еще до написания самого кода является характерной чертой TDD (разработки через тестирование). На тему эффективности TDD существует множество исследований. И хотя результаты некоторых из них неоднозначны, почти все они отмечают позитивные улучшения в плане количества багов при применении TDD.
Я верю, что разработка через тестирование заставляет вас становиться на место пользователя, а это ведет к более практичному и естественному набору API.
Не беритесь за несколько задач сразу. Нужно сначала написать провальный тест для отдельного модуля вашего кода, а после этого написать код самого модуля. Это позволит вам эффективно проверять ваш дизайн и поддерживать покрытие тестами.
Следите за тем, чтобы ваш код был последовательным
Все разработчики имеют свои личные предпочтения в плане стилей написания кода. Но все они должны стремиться к согласованности кодовой базы.
У вас должны быть, например, соглашения об именах переменных, и все должны их придерживаться. То же касается и других вещей. Если вы используете табы для отступов, делайте это везде. А если используете пробелы, то везде должны быть пробелы.
Многие разработчики-джуниоры чрезмерно увлекаются подобными нюансами и никак не могут выбрать. Но на самом деле гораздо важнее то, насколько четко вы придерживаетесь своего выбора. Поначалу это может казаться легкой задачей, но последовательность в коде это далеко не только выбор между табами и пробелами.
Логика вашего кода также должна быть последовательной. Почему вы использовали map здесь и for each там? Почему кое-где вы использовали var, а в других местах – let и const? Предсказуемость это одна из черт, редко встречающихся у программистов (да и вообще у людей), но она также и одна из наиболее ценных.
Проверьте ваш код
Если код идет в ветку master, он должен пройти ревью. Чтобы это ревью принесло максимум пользы, автор должен искренне ценить этот процесс.
Хороший программист пишет отличный код и не отправляет его на ревью.
Отличный программист пишет достойный код, но при этом прогоняет его сквозь скрупулезный процесс ревью.
Нужно предполагать возможность провала в каждом аспекте вашей жизни, включая программирование. Ошибки все равно будут, но чаще всего, чтобы их выловить, нужна просто еще одна пара глаз.
Выпустите ваш код
Поздравляю, вы написали хороший код. Можно написать такой код и без описанного здесь процесса, но невозможно делать это постоянно.
После отправки вашего кода в продакшен не забудьте сообщить об этом своей команде: это может разблокировать чью-то работу.
Не принимайте все сказанное здесь слишком близко к сердцу
Каждое правило должно применяться с умом. Если ваш коммит – это две строчки, добавленные к внутреннему файлу README, то надо ли отправлять это на ревью?
Придерживайтесь лучших подходов, но при этом будьте практичны и рациональны. Самый важный инструмент в вашем арсенале это ваше чутье. Правила существуют не для того, чтобы преграждать вам путь, они нужны, чтобы обеспечить последовательность и надежность.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]