Содержание
Любой может написать код. Но хороший код? Вот где это становится жестким.
Мы все слышали ужасные истории о спагетти-коде, массивных цепочках if-else, целых программах, которые могут сломаться только при изменении одной переменной, функциях, которые выглядят как запутанные, и так далее. Вот что происходит, когда вы пытаетесь создать продукт, который можно отправлять, имея только семестр опыта программирования.
Не соглашайтесь на написание кода, который работает. Старайтесь писать код, который можно поддерживать — не только самим собой, но и кем-либо еще, кто может в конечном итоге работать над программным обеспечением в будущем. Для этого, вот несколько принципов, которые помогут вам очистить ваш поступок.
1. ПОЦЕЛУЙ
Принцип «будь проще, глупый» относится практически ко всей жизни, но особенно это необходимо для средних и крупных программных проектов.
Это начинается с самого начала, когда вы определяете объем того, что вы хотите создать. То, что вы увлечены разработкой игр, не означает, что вы можете создать следующий World of Warcraft или Grand Theft Auto. Когда вы думаете, что достаточно упростили, упростите его еще на один уровень — ползучесть функций неизбежна, поэтому начните с малого.
Но даже после того, как кодирование началось, сохраняйте его простым. Сложный код занимает больше времени на разработку и написание, более подвержен ошибкам и ошибкам, и его труднее изменить позже в будущем. По мудрым словам Антуана де Сент-Экзюпери: «Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать».
2. СУХОЙ
Принцип «не повторяйся» имеет решающее значение для чистого и простого для изменения кода. При написании кода вы хотите избежать дублирования данных и дублирования логики. Если вы замечаете, что один и тот же кусок кода пишется снова и снова, вы нарушаете этот принцип.
Противоположностью DRY-кода является WET-код: «напиши все дважды» (или «напрасно трать время»). Один из лучших способов диагностики кода WET — это спросить себя: чтобы каким-либо образом изменить поведение программы, сколько областей кода вам нужно изменить?
Предположим, вы пишете приложение каталога подкастов. На странице поиска у вас есть код для получения сведений о подкасте. На странице подкаста у вас есть код для извлечения деталей этого подкаста. На странице избранного тот же код извлечения. Попробуйте абстрагировать все это в функцию, чтобы, если вам нужно отредактировать ее позже, вы могли сделать все это в одном месте.
3. Открыто / Закрыто
Пишете ли вы объекты
в Java или модули в Python, вы должны стремиться сделать свой код открыт для расширения, но закрыт для модификации. Это относится ко всем видам проектов, но особенно важно при выпуске библиотеки или среды, предназначенной для использования другими.
Например, предположим, что вы поддерживаете графический интерфейс. Вы можете выпустить его как есть, ожидая, что конечные пользователи будут напрямую модифицировать и интегрировать ваш выпущенный код. Но что происходит, когда вы выпускаете серьезное обновление четыре месяца спустя? Как они реализуют все ваши дополнения, не отбрасывая всю работу, которую они сделали?
Вместо этого выпустите код, который предотвращает прямое изменение и поощряет расширение. Это отделяет поведение ядра от измененного поведения. Выгоды? Большая стабильность (пользователи не могут случайно нарушить поведение ядра) и лучшая поддержка (пользователи беспокоятся только о расширенном коде). Принцип открытия / закрытия является ключом к созданию хорошего API
,
4. Состав> Наследование
Принцип «композиция над наследством» утверждает, что объекты со сложным поведением должны делать это путем удержания экземпляров объектов с индивидуальным поведением, а не наследования класса и добавления новых поведений.
Чрезмерная зависимость от наследования может привести к двум основным проблемам. Во-первых, иерархия наследования может стать грязной в мгновение ока. Во-вторых, у вас меньше гибкости для определения поведения в особом случае, особенно когда вы хотите реализовать поведение из одной ветви наследования в другой ветви наследования:
Композиция гораздо чище для написания, ее проще поддерживать и обеспечивает почти бесконечную гибкость в зависимости от того, какие типы поведения вы можете определить. Каждое отдельное поведение — это свой собственный класс, и вы создаете сложное поведение, комбинируя индивидуальное поведение.
5. Единая ответственность
принцип единой ответственности говорит, что каждый класс или модуль в программе должен заботиться только о предоставлении одного бита определенной функциональности. Как говорит Роберт С. Мартин: «У класса должна быть только одна причина для изменения».
Классы и модули часто начинаются таким образом, но по мере того, как вы добавляете функции и новое поведение, им легко превращаться в классы Бога и модули Бога, которые занимают сотни или даже тысячи строк кода. На этом этапе вы должны разбить их на более мелкие классы и модули.
6. Разделение проблем
принцип разделения интересов это как принцип единой ответственности, но на более абстрактном уровне. По сути, программа должна быть спроектирована так, чтобы в ней было много разных непересекающихся инкапсуляций, и эти инкапсуляции не должны знать друг о друге.
Хорошо известным примером этого является парадигма модель-представление-контроллер (MVC), которая разделяет программу на три отдельные области: данные («модель»), логика («контроллер») и то, что видит конечный пользователь. («Посмотреть»). Вариации MVC распространены в самых популярных сегодня веб-фреймворках.
Изображение предоставлено: Викимедиа
Например, код, который обрабатывает загрузку и сохранение данных в базе данных, не должен знать, как отображать эти данные в Интернете. Код рендеринга может принимать ввод от конечного пользователя, но затем передавать этот ввод в логический код для обработки. Каждая часть обрабатывает себя.
В результате получается модульный код, который значительно упрощает обслуживание. И в будущем, если вам когда-нибудь понадобится переписать весь код рендеринга, вы можете сделать это, не беспокоясь о том, как данные сохраняются или обрабатывается логика.
7. ЯГНИ
Принцип «тебе это не понадобится» Это идея, что вы никогда не должны кодировать функциональность, которая может вам понадобиться в будущем. Скорее всего, вам это не понадобится, и это будет пустой тратой времени — и не только это, но и излишне увеличит сложность вашего кода.
Вы можете рассматривать это как конкретное применение принципа KISS и как ответ тем, кто слишком серьезно относится к принципу DRY. Часто неопытные программисты пытаются написать наиболее абстрактный и общий код, который только можно избежать, чтобы избежать кода WET, но слишком много абстракции заканчивается в раздутом коде, который невозможно поддерживать.
Хитрость заключается в том, чтобы применять принцип СУХОЙ только тогда, когда это необходимо. Если вы замечаете, что куски кода пишутся снова и снова, то абстрагируйте их — но никогда, когда вы думаете, что фрагмент кода будет записываться снова и снова. Больше раз, чем не будет.
8. Избегайте преждевременной оптимизации
нет принципа преждевременной оптимизации похож на принцип ЯГНИ. Разница в том, что YAGNI учитывает тенденцию к внедрению поведения до того, как он необходим, в то время как этот принцип учитывает тенденцию ускорять алгоритмы до того, как это необходимо.
Проблема с преждевременной оптимизацией заключается в том, что вы никогда не узнаете, где будут узкие места в программе, до тех пор, пока это не произойдет. Вы можете догадаться, конечно, а иногда вы даже можете быть правы. Но чаще всего вы тратите драгоценное время, пытаясь ускорить функцию, которая не так медленна, как вы думаете, или не вызывается так часто, как вы ожидаете.
Достигните вехи как можно проще, затем профилируйте код, чтобы выявить истинные узкие места.
9. Refactor, Refactor, Refactor
Одна из самых трудных истин для неопытного программиста заключается в том, что код редко выходит прямо с первого раза. Это может показаться правильным, когда вы реализуете эту блестящую новую функцию, но по мере усложнения вашей программы будущие функции могут быть затруднены тем, как вы написали эту раннюю.
Кодовые базы постоянно развиваются. Пересматривать, переписывать или даже перепроектировать целые куски кода совершенно нормально — и не просто нормально, а полезно для этого. Вы знаете больше о потребностях вашего проекта сейчас, чем когда вы это делали в начале, и вам следует регулярно использовать эти новые знания для рефакторинга старого кода.
Обратите внимание, что это не всегда должен быть большой процесс. Возьмите страницу с Бойскаутами Америки, которые живут под этими словами: «Оставьте лагерь чистым, чем вы его нашли». Если вам когда-нибудь понадобится проверить или изменить старый код, всегда очищайте его и оставляйте в лучшем состоянии.
10. Чистый код> Умный код
Говоря о чистом коде, оставь свое эго у двери и забудьте о написании умного кода. Вы знаете, о чем я говорю: код, который больше напоминает загадку, чем решение и существует исключительно для того, чтобы показать, насколько вы умны. По правде говоря, никому нет до этого дела.
Одним из примеров умного кода является упаковка как можно большего количества логики в одну строку. Другой пример — использование тонкостей языка для написания странных, но функциональных утверждений. Все, что может заставить кого-то сказать «Подожди, что?» При наведении на ваш код.
Хорошие программисты и читаемый код идут рука об руку. Оставляйте комментарии, когда это необходимо. Придерживайтесь руководств по стилю, будь то продиктовано языком (например, Python) или компанией (например, Google). Соблюдайте языковые идиомы и прекратите писать код Java на Python или наоборот. Смотрите нашу статью о советах по написанию чистого кода
,
Что делает хорошего программиста?
Спросите пять человек, и вы получите 10 разных ответов. Для меня хороший программист — это тот, кто понимает, что кодирование должно в конечном итоге служить конечному пользователю, с которым легко работать в команде, и который заканчивает свои проекты в соответствии со спецификацией и в срок.
Если вы только начинаете, пока не слишком переживайте по этому поводу. Сосредоточьтесь на том, чтобы научиться писать без стресса. Если вы застряли, посмотрите нашу статью о преодолении блока программиста. И если вам просто не нравится писать код, прочитайте нашу статью о том, что вы не должны быть программистом
,
Как бы вы определили хорошего программиста? Есть какие-нибудь советы для неопытных программистов, которые хотят совершенствоваться? Поделитесь с нами в комментариях ниже!
