Будьте проще (и к вам потянутся люди)

Разработка программного обеспечения — такая штука, в которой есть много, очень много принципов, методологий, проверенных путей и всего такого. Среди них лично мне больше всего нравятся те, которые облегчают жизнь рядовому программисту. Как, например, YAGNI и KISS. Это два таких родственных принципа, они меня сегодня волнуют (тем, что их почти все знают, но далеко не все придерживаются), и я хочу об этом поговорить.

© MariannaBolognesi

KISS — это keep it short & simple. Делай короче и проще. Думаю, многие с эим принципом знакомы; помню, даже телепередача была с таким названием. Смысл понятен — делайте ваши системы как можно более простыми и легковесными. Смысл понятен, а вот с практикой напряженка.

Действительно, если ты 23-летний сениор, то чем-то ведь твой код должен отличаться от кода 20-летнего джуниора? И вот тут на помощь приходит сложность. Осилил наконец-то книгу про паттерны? Отлично. Абстрактная фабрика тут, стратегия там, трансформация DTO пять раз здесь — и сразу видно, что писал настоящий взрослый разработчик. Опять-таки, можно насовать пару фреймворков. И какой-то скриптовый язык присунуть, ну чисто генерить всякое.

Тут самое время вспомнить, что самый лучший дизайн — простой и понятный. Что рефакторинг придумали не для втискивания всех известных программисту паттернов проектирования, а чтобы код читался легче. И что идеальное улучшение кода — это когда вы берете и выкидываете половину классов (процедур, функций, не важно), а оставшиеся сокращаете в два раза.

Ну, понятно, что делать все проще и короче должны не только разработчики. Аналитикам хорошо бы писать короткие и четкие требования. Менеджерам — не усложнять задачи, стоящие перед командами. И так далее, до самого верха. Короче, полный KISS.

Принцип YAGNI немного менее известен. И, кстати, зря. YAGNI означает you ain’t gonna need it. Это вам не понадобится. Ну, то есть — не делайте лишнюю работу.

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

Опять-таки, это не касается только разработчиков. Очень многим людям свойственно загадывать наперед. И если каждый раз, когда хочется сделать что-то, что, может быть, когда-нибудь будет нужно, говорить себе «мне это не понадобится», жить будет намного проще. А простота, как мы помним, признак мастерства.

Конечно, эти два принципа — не серебрянная пуля (её, как известно, не существует). И кому-то просто нравится потратить пару человеколет на создание универсального фреймворка, который с помощью своих фабрик фабрик фабрик будет способен делать вообще все. А кому-то другому приятно за всё это заплатить. Но лично мне намного приятнее видеть простой и понятный проект, который развивается инкрементально, чем универсального монстра, про которого до дня сдачи в эксплуатацию даже нельзя сказать, работает он или нет. Да и после сдачи, если честно, тоже не очень.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU