Руководство по написанию чистого кода
Начиная что-то новое, всегда есть желание преуспеть. Это служит мотивацией продолжать заниматься тем, что вы начали. Я начал свой путь к тому, чтобы стать инженером-программистом чуть меньше месяца назад. Мне нравится аспект решения проблем и идея, что я изучаю технический навык, который имеет ценность во все более цифровом мире. Код составляет все, с чем мы сталкиваемся ежедневно. Большинство из нас в течение дня полагается на множество строк кода. Это то, что делает жизнь в 2019 году такой удобной. Я могу заказать автосервис, заказать еду на вынос и оплатить счета одним касанием пальца. Какое время быть живым.
Итак, с тех пор, как я начал учиться программировать, я хотел знать, как писать хороший код. Слова «программная инженерия» меня немного вводят в заблуждение. Имея ограниченный опыт, я считаю, что разработка программного обеспечения - это больше искусство, чем наука. В кодировании есть основы, которые делают его технической практикой, но то, как мы их используем и объединяем, показывает мне, что написание хорошего кода требует творчества. Есть так много способов сделать что-то одно, и ни один из них не является окончательным. Однако с помощью принципов проектирования и передового опыта написание чистого кода не является такой уж невыполнимой задачей.
«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям ». - Мартин Фаулер
Эта диаграмма - это то, что Роберт Мартин описывает как единственно верное измерение качества кода. Количество WTF в минуту является индикатором того, считается ли ваш код хорошим или плохим. Это соответствует моему опыту написания кода. Будучи студентом Flatiron School, мы постоянно пишем код и должны объяснять код, который мы пишем другим людям. Хороший и плохой код могут функционировать, поэтому качество кода зависит от способности других его понять.
Простой способ начать писать чистый код - использовать понятные соглашения об именах для переменных и методов. Вы хотите, чтобы ваши коллеги могли угадывать, что должны представлять ваши переменные и что делают ваши методы, просто читая их имя. Это дает возможность иметь приблизительное представление о том, что может делать ваш код, не глядя на каждую строку. Имена переменных и методов должны описывать основную идею их создания. Это форма абстракции, которая делает код более чистым. Это первый шаг к написанию лучшего кода. Я также заметил, что выбор подходящих имен для моих переменных и методов делает навигацию по многим строкам кода в более крупных проектах гораздо более приятным занятием. Наличие такого соглашения очень помогает ознакомиться с кодом, прежде чем углубляться в него.
Бывают случаи, когда один и тот же набор кода пишется в разных частях вашего кода. Обычно протокол резервирует этот код для своего собственного метода. Поэтому вместо того, чтобы при необходимости переписывать один и тот же блок кода, вы можете просто вызвать метод, который сделает эту работу за вас. Это известно как инкапсуляция и основано на принципе DRY. «Не повторяйся» означает именно это, не повторяй один и тот же код снова и снова. Это может указывать на то, что все должно быть написано как метод. Проблема в том, что это делает ваш код слишком абстрактным. Слишком частая разбивка кода затруднит его понимание. Хорошее практическое правило - создавать метод для блока кода, если вы видите, что пишете его более дважды.
Последнее, что приходит в голову, - это быть последовательным. Есть разные способы написать определенную строку кода, и это вызовет некоторую путаницу, если код, который функционирует одинаково, будет написан по-другому. Это идет рука об руку с инкапсуляцией блоков кода, поскольку при необходимости будет использоваться один и тот же код. Согласованность кода достигается за счет отступов, именования, файловой структуры и шаблонов проектирования и соглашений.
Это некоторые из вещей, которые я подобрал, которые помогают мне писать код, которым я могу гордиться. Это не только помогает писать более чистый код, но и делает вас лучшим программистом, если вы пишете код так, чтобы он сам себя объяснял.
