Базовые принципы

(в основном, программирования)

Собеседования. Все мы, так или иначе, рано или поздно их проходим. Сегодня я хочу поговорить о часто задаваемых вопросах на собеседованиях. И технических мы коснёмся только в самом конце нашей беседы. Я убеждён, что все принципы, описанные для использования в сфере информационных технологиях подходят и для обычной, повседневной, жизни. Я буду называть принципы и примеры, а додумать применимость в жизни я оставлю читателю.

DRY

Don't repeat yourself. Акроним dry (англ. сухой, чистый). Не повторяйся. Любой код, который программист вынужден повторять можно убрать в цикл, метод, класс, подпрограмму, модуль, сервис. Если в Вашей программе есть повторяющийся (скопипастченный) код - это не очень хорошая программа, потому что если и когда Вам нужно будет её исправлять - Вы потратите вагон времени только на поиск всех мест, содержащих нужную копипасту. Программы и компьютеры, их же придумали как раз для того, чтобы не нужно было самому выполнять повторяющиеся действия. Поэтому, не повторяй себя. Двигайтесь вперёд. Антагонист этого принципа - WET. Write everything twice. Акроним wet (англ. влажный). Пиши всё дважды. Экономьте собственное время, не пишите по два раза.

KISS

Keep it simple, stupid. Сохрани это простым, до глупости. Это не призыв быть глупым, как могло показаться на первый взгляд. Это призыв оставаться понятным и простым в рассуждениях, объяснениях и описании кода. Никто не любит тех, кто умничает по поводу и без него. Если есть возможность решить задачу просто и быстро - нужно воспользоваться ей. Если же совсем никак не получается без сложного и неочевидного решения: обильно прокомментируйте его. Известно, что если вы не можете объяснить своё занятие или свои действия пятилетнему - вы слишком мудрите. Или занимаетесь ерундой, выбирайте сами. Всегда думайте, что ваш код будет читать живой человек, который не может залезть к вам в голову и магически понять "что имел ввиду автор". Да и старую поговорку "будь проще и люди к тебе потянутся" тоже никто пока что не отменил.

YAGNI

You ain't gonna need it. Вам это не понадобится. Здесь возможны две трактовки, но обе сводятся к одному: не делай лишнего. Да, всегда нужно думать немного наперёд, бесспорно. Но всегда эта мысль должна опираться на здравый смысл: настанет ли момент когда это может пригодиться. И да, всегда нужно стараться сделать чуть больше и чуть лучше, чем требуется, но нужно думать: не затрачу ли я на это вообще все свои ресурсы без остатка? Поэтому: делайте лучше, делайте больше, делайте наперёд, но только если это для вас ничего не стоит. Иначе, поберегите силы.

SOLID

Ну и немного действительно полезной информации, такое любят спрашивать на джуниорских собеседованиях. Это акроним, solid - надёжный, цельный. Состоит этот акроним из целых пяти понятий, каждое из которых так или иначе делает ваш код лучше, надёжнее, понятнее.

Single responsibility principle - принцип единственной ответственности, атомарности. Любой объект, будь то класс, экземпляр или функция должны выполнять одно дело, но делать это полностью и хорошо. Если Ваш объект занимается больше, чем одним делом - это плохой объект. Этот принцип можно перефразировать пословицей "за двумя зайцами погонишься - ни одного не поймаешь".

Open/close principle - принцип открытости/закрытости, описываемые Вами объекты (да, тут про объектно-ориентированное программирование) должны быть открыты для расширения и закрыты для модификации. То есть поведение объекта должно быть максимально инкапсулировано, но чем больше у объекта потенциал к расширению (применению наследования и полиморфизма) тем лучше. Это позволяет, помимо прочего, следовать принципу DRY.

Liskov substitution principle - Принцип подстановки Барбары Лисков. Используемые и описываемые вами объекты должны быть заменяемы на свои подтипы без изменения правильности работы. Этот принцип тесно связан с предыдущим и согласно ему котики и пёсики должны уметь делать всё, что умеет делать животное, но не обязательно котик должен уметь делать то, что умеет пёсик. Наследование и полиморфизм.

Interface segregation - Принцип разделения интерфейсов. Много разных интерфейсов всегда лучше одного общего. Звучит знакомо? Да, конечно, это же Single responsibility, естественно, это касается и интерфейсов и сложного ООП. В конце концов, Вам жалко что ли насоздавать интерфейсов на каждый чих? Это гораздо более гибко, чем иметь один God-Interface через который будут работать вообще все объекты в программе.

Dependency inversion - Инверсия зависимостей. Все зависимости должны быть абстрактны. Не стоит вписывать в свою программу зависимость от какого-то конкретного класса, если есть возможность зависеть от интерфейса. Ваш код таким образом становится гораздо более расширяем и его можно гораздо проще переиспользовать в других проектах, поскольку у Вас не будет зависимостей от конкретных классов, и вы не будете связаны наследованием.

Описанные принципы, несмотря на свою кажущуюся технологичность, подходят и для жизни:

S - не пытайтесь делать несколько дел одновременно;
O - постарайтесь сделать так, чтобы не пришлось переделывать;
L - используйте заменяемые объекты (чтобы сидеть, используйте стул, а не шкаф);
I - лучше использовать несколько простых инструментов, чем сто-в-одном;
D - делайте так, чтобы результатом вашего труда мог воспользоваться кто угодно, а вы не зависели от специфичных решений, больше абстрагируйте.

И напоследок

Принцип, который чаще всего помогает в работе лично мне, потому я дал себе труд его сформулировать: При работе всегда надо стараться пользоваться не новыми технологиями, а головой.(с) Иван Овчинников, 2018г.