Общие принципы разработки хорошего кода, а именно про DRY, KIS | Про єнотів та IT

Общие принципы разработки хорошего кода, а именно про DRY, KISS, YAGNI и почему нельзя возвращать NULL. По-сути, первые 3 говорят говорят про очевидные вещи, но иногда разработчики про них забывают.

DRY
— don't repeat yourself
— нарушения принципа DRY называют WET — "Write Everything Twice" или "We enjoy typing"
— не допускай повторяющихся участков кода, на уровне функций, также не допускай классов с повторяющимся функционалом

KISS
— keep it simple, stupid или keep it short and simple
— нет смысла реализовать дополнительный функционал, который возможно когда-нибудь пригодится
— бессмысленно делать реализацию сложной бизнес-логики, которая учитывает в себе все возможные варианты
— нет смысла подключать огромную библиотеку, если вам от нее нужна только пара функций
— нужно держать компоненты своей системы (классы, методы) в максимально простом, не осложнённом, не перегруженном состоянии
— перекликается с Single responsibility, Interface Segregation принципами из SOLID

YAGNI
— you aren't gonna need it
— прежде чем писать новый компонент/функцию подумай: а нужен/на ли она тебе вообще? Может это можно не делать вообще? Или по крайней мере сделать это изящнее, проще, умнее, в рамках уже существующего/ей компонента/функции, не добавляя лишнего
— заказчик не должен оплачивать то, что он не заказывал
— бесплатных функций в продуктах не бывает
— ненужные новые функции могут впоследствии помешать добавить новые нужные
— новые функции должны быть отлажены, документированы и сопровождаться
— добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту "снежного кома"

почему нельзя возвращать NULL
— накладывается неявное ограничение на код, который должен проверять значение на NULL
— обработка ошибок вручную

Мне нравится описание Filip Hanik всех этих принципов:
— Разбивайте задачи на подзадачи которые не должны по вашему мнению длиться более 4-12 часов написания кода
— Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов
— Сохраняйте ваши методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нём. Вы полюбите улучшать код.
— Придумайте решение задачи сначала, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше обозначенного правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код ещё и ещё и ещё… В счёт не идёт число строк, до тех пор пока вы считаете что можно ещё меньше/ещё лучше.
— Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения два очень важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое более изящное решение решающее и старые и новые задачи.