Что отличает хорошего программиста? Жажда кодинга? Это волнение от решения проблем? Гениальные решения сложных проблем? По правде говоря, великий программист ценит людей больше, чем код. По словам Мартина Фаулера,
«Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям».
Программирование — это искусство, но не просто индивидуальное искусство. Это сотрудничество между людьми с разными навыками и уровнями понимания. Это не место для демонстрации того, насколько загадочный, короткий или умный код можно написать, а то, насколько код удобен в сопровождении, расширяем и прост для понимания. Независимо от того, являетесь ли вы новичком или экспертом в этой области, всегда есть возможности для совершенствования. В этой статье изложены десять принципов, которым должен следовать каждый программист, чтобы сделать свой код лучше.
ПОЦЕЛУЙ (будь проще, глупый)
KISS — это, вероятно, первое, что каждый разработчик должен понять и учитывать при написании кода. KISS заявляет, что большинство систем работают лучше всего, если их упрощают, а не усложняют. Чаще всего сложный дизайн и логика подвержены ошибкам и ошибкам. Требуется много усилий и времени, чтобы понять сложную логику кода и отладить ее. Никто не хочет застрять на отладке сложного фрагмента кода, который часто ломается. Начав с идеи, запишите ее, упростите и повторяйте до тех пор, пока ее нельзя будет упростить. Кодирование приходит после того, как вся логика упрощена и отшлифована. Всегда помни,
«Совершенство достигается не тогда, когда больше нечего добавить, а тогда, когда нечего убрать». — Антуан де Сент-Экзюпери
СУХОЙ (не повторяйтесь)
Одной из наиболее распространенных проблем в фрагменте кода является дублирование, будь то логика, данные или функция. Повторяющийся код делает программу более длинной, а также требует дополнительных усилий для отладки и поддержки. Представьте себе изменение одного имени переменной с ошибкой 40 раз в повторяющихся блоках кода в разных местах или изменение одной части логики во всех этих блоках. Принцип DRY гласит, что данный код должен быть реализован только в одном месте исходного кода. Противоположностью СУХОГО принципа является ВЛАЖНЫЙ («Писать все дважды» или «Тратить время всех»). Как следует из названия, WET тратит много времени как на первоначального разработчика, так и на других, которые вносят свой вклад в поддержку и расширение проекта.
Предположим, вы разрабатываете веб-сайт. На «домашней» странице у вас есть код для панели навигации. На странице «о нас» у вас есть код для панели навигации. На странице «Контакты» у вас есть код для панели навигации. Попробуйте абстрагировать код панели навигации в отдельное место (или в общий шаблон) и вызывать его по мере необходимости на разных страницах. После абстрагирования вы можете обновить или отредактировать код панели навигации в одном месте, не утруждая себя изменением его для всех страниц.
Единая ответственность
Принцип единой ответственности гласит, что каждый класс/модуль в программе должен заниматься предоставлением определенной функциональности. Большинство классов/модулей начинаются так, а затем в конечном итоге накапливают больше функций и превращаются в «божественные классы» или «божественные модули» с более чем тысячами строк кода. Лучше разбить эти «божественные классы/модули» на отдельные более мелкие части. Меньшие фрагменты делают логику более понятной, а код — более легким для отладки.
Разделение ответственности (SoC)
Принцип «разделения ответственности» похож на принцип «единой ответственности», но на более абстрактном уровне. В нем говорится, что каждая часть программного обеспечения должна быть разделена на разные непересекающиеся инкапсуляции, которые не должны знать друг о друге.
Отличным примером SoC является парадигма MVC (модель — представление — контроллер). Веб-приложения или интерфейсы GUI обычно следуют парадигме MVC. Парадигма делит всю программу на три части: Модель («данные для приложения/интерфейса»), Контроллер («логика программы») и Представление («что видит конечный пользователь»). Каждая часть выполняет свою функцию и связана с другими разделами, но также независима; это делает код модульным.
В будущем, если потребуется переписать код для логики («контроллера»), это можно будет сделать, не влияя на то, как приложение отображает данные для пользователя; это упрощает обновление и отладку кода.
YAGNI (Вам это не понадобится)
Принцип YAGNI гласит, что никогда не следует кодировать «функциональность», которая может понадобиться вам в будущем. Велика вероятность того, что вам это не понадобится! Раздутый код усложняет обслуживание.
В качестве конкретного примера я сделал этот генератор слов для игры в Pictionary с друзьями. У меня было предчувствие, что нам может понадобиться отслеживать слова, которые были произнесены, поэтому я включил функцию под названием предыдущие слова, которая представляла собой список слов, которые были сгенерированы ранее. В итоге мы его не использовали; вместо этого нам нужен был словарь для поиска значения некоторых из произведенных слов. Мне пришлось дважды пересмотреть свой код, чтобы удалить ненужную функциональность и добавить функцию словаря. Я понял, что сложно предсказать, какой функционал может пригодиться в будущем. Таким образом, код должен быть минималистичным с возможностью расширения в будущем.
Открыто закрыто
Принцип открытости/закрытости в основном используется в ООП (объектно-ориентированном программировании), но его можно экстраполировать на многие другие сценарии. В нем говорится, что код должен быть открыт для расширения, но закрыт для модификации. Необходимо сохранить основное поведение программы и предотвратить его изменение людьми. Однако программа также должна быть открыта для расширения, и пользователи/другие программисты должны иметь возможность добавлять дополнительные функции.
Он обеспечивает множество преимуществ; программное обеспечение более стабильно, так как пользователи не могут случайно сломать код, а также более удобно в сопровождении, поскольку пользователям нужно беспокоиться только о расширенных функциях, а не об основных функциях. .
Избегайте преждевременной оптимизации
Многие из моих друзей (в какой-то момент и я) склонны оптимизировать наш код по мере его написания. Такое поведение не только неправильно, но и отнимает много часов, которые можно потратить на завершение кода. Оптимизация помогает сделать приложение быстрее, новыявить узкие места в программе можно только после написания кода всей программы и выполнения тестов. Всегда можно догадаться, какие функции или классы работают медленно. Но чаще всего вы оптимизируете функции, которые работают не так медленно, как вы думаете, или вызываются не так часто, как вам кажется.
Не живите с разбитыми окнами
«Если окно разбито и не отремонтировано, люди, проходящие мимо, решат, что всем наплевать и никто не отвечает. Скоро будут разбиты еще окна…”
«Разбитое окно» здесь относится к плохому дизайну и плохому коду. Соответствующий код никогда не должен ржаветь и гнить. Неверный код необходимо исправлять сразу после его обнаружения. Это заставляет других сотрудников и пользователей понять, что разработчики активны и ценят написанный ими код.
Чистый код побеждает умный код
Мы все видели умный код; Код, который больше похож на загадку, чем на решение. Прекрасным примером этого является втиснуть большое количество логики в одну или две строки. Другим примером может быть запись странных, но функциональных операторов, использующих тонкости определенного языка. Умный код можно использовать, чтобы продемонстрировать, насколько хорошо вы знаете или насколько тщательно вы знаете язык, но использовать его везде — большая ошибка. При написании программного обеспечения с открытым исходным кодом или программы, над которой работает много людей, оставьте свое эго за дверью и забудьте о написании умного кода.
Хорошие программисты и читаемый код идут рука об руку. Комментируйте, когда это необходимо. Придерживайтесь рекомендаций, продиктованных конкретными языками (например, Python) или компаниями (например, Google), и убедитесь, что код прост и понятен. Нет большей радости, чем похвала за красоту и элегантность кода.
Рефакторинг
Возможно, наиболее важным моментом является частый рефакторинг вашего кода. Рефакторинг кода относится к реструктуризации существующего компьютерного кода — изменению факторинга — без изменения его внешнего поведения. Неопытному программисту сложнее всего принять тот факт, что код редко получается правильным с первой попытки. Это может казаться прекрасным и правильным при успешной реализации новой функции с первой попытки, но по мере усложнения программы один и тот же код может препятствовать добавлению новых функций. Таким образом, часто приходится пересматривать уже написанный код и изменять его структуру, чтобы упростить его обслуживание в долгосрочной перспективе.
«Вещи меняются, требования дрейфуют, а ваши знания о проблеме расширяются. Код должен идти в ногу со временем».
Разработка программного обеспечения — это непрерывный цикл, так как ваш код развивается, вам необходимо переосмыслить то, как вы реализовали старые функции, и постоянно обновлять кодовую базу.
Вывод
Программирование — это искусство, и нужно выражать себя, следя за тем, чтобы окружающие понимали и ценили ваш код. Вышеупомянутые пункты подчеркивают, что код должен быть удобным для человека, расширяемым и удобным в сопровождении.
Перед тем, как ты уйдешь…
Свяжитесь со мной в Instagram и Facebook.
Если вам понравилась эта история, нажмите кнопку аплодисментов (одной кнопкой вы можете хлопнуть до 50 раз!) и подписывайтесь на меня, чтобы получать больше таких статей!
Делитесь, рекомендуйте и комментируйте! Вовлеченность помогает нам общаться и быть более человечными!
