Принципы разработки ПО — это набор определенных правил и рекомендаций, которым нужно следовать при написании исходного кода программы, если хочешь написать красивый, понятный и легко редактируемый код. То есть, не существует волшебной палочки, с помощью которой можно было бы превратить мешанину из переменных, классов и методов в идеальный листинг, но существуют некоторые подсказки, которые помогают программисту определить, все ли правильно он делает. Давайте рассмотрим эти основные рекомендации.
Don’t Repeat Yourself (DRY) — Не повторяйся!
Достаточно простой, но при этом очень полезный принцип, который говорит, что повторение одного и того же кода в нескольких местах — очень плохая идея. Это связано в первую очередь с необходимостью дальнейшего поддержания и изменения кода. Если какой-то определенный кусок листинга повторяется в нескольких местах программы, то велика вероятность возникновения двух плачевных ситуаций:
- При необходимости внести даже малейшие исправления в исходный код, вам придется заглянуть во все места где он используется, что потребует дополнительных затрат времени и сил
- Из первого пункта вытекает второй, вы или другой разработчик может случайно пропустить одно из исправлений и столкнуться с последующими ошибками в работе приложения.
В связи с этим есть рекомендация, если какой-либо код встречается в листинге более двух раз, то его нужно выносить в отдельный метод. Это общая рекомендация, на самом деле нужно задуматься о выделении метода даже если вы встречаете повторение второй раз.
Occam’s Razor (OR) — Бритва Оккама
Очень распространенная идея, которая пришла в программирование из философии. Принцип получил свое имя в честь английского монаха Уильяма из Оккама. Данный принцип гласит следующее: «Не следует множить сущее без необходимости». В сфере программирования, это правило трактуется следующим образом — не нужно создавать лишние сущности без необходимости в них. То есть, всегда задумывайтесь над тем, получите ли вы выгоду выделив дополнительный класс или метод. Ведь если вы будете выделять в отдельный метод одну строчку, которая при этом еще и нигде больше не повторяется, то только запутаете и усложните свой код.
Keep It Simple Stupid (KISS) — Делай это проще
Схожий с предыдущим пунктом принцип, но имеющий немного другую смысловую нагрузку. Данная рекомендация говорит, что код нужно писать простым, без сложных конструкций, так как в противном случае это может значительно усложнить поддержание и отладку. Кроме того, другому программисту будет намного сложнее разобраться в хитросплетениях и сложных ветвлениях листинга, что тоже потребует дополнительных затрат сил и времени. Поэтому всегда старайтесь использовать простые и логичные конструкции без глубокой вложенности, так вы упростите жизнь и себе, и коллегам.
You Aren’t Gonna Need IT (YAGNI) — Вам это не понадобится
Проблема которой страдают многие программисты. Стремление разработать сразу весь потенциально необходимый (а иногда даже ненужный) функционал с самого начала процесса разработки. То есть, когда разработчик с самого начала добавляет все возможные методы в класс и реализует их, при этом в дальнейшем может даже ни разу ими и не воспользоваться. Поэтому согласно этой рекомендации, разрабатывайте только то, что вам необходимо в первую очередь, а в дальнейшем при необходимости наращивайте функциональные возможности. Так вы сэкономите многоженство сил, времени и нервов на отладку кода, который на самом деле не нужен.
Источник: CODE BLOG
Также рекомендую ознакомиться со статьей Платформа .NET и язык программирования C#
Подписывайтесь, ставьте лайки. Это действительно помогает в развитии канала.
