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

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


© MariannaBolognesi

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

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

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

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

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

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

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

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

73 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

слабинькая статья....

KISS my shiny metal YAGNI! =)

Я думал всю заметку так назвать, но постеснялся.

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

Имея простые и понятные требования на входе и толковую команду вполне можно написать простой, не избыточный, и рабочий проект вполне быстро и недорого. Как аналогия электронные часы или калькулятор: внутри 1-2 микросхемы и все работает. Но! Приложение получится таким-же «одноразовым». Что будет если потом это вдруг надо будет починить или поменять?

YAGNI и KISS — простые и, в теории, правильные принципы. Но применять их на проекте можно только вместе с грамотным Risk Management ! Что бы на каждое простое решение был оценен риск что будет, если оно не прокатит. Ведь все «сложности» и «закладки на будущее» по-сути нужны именно для минимизации последствий риска.

Вы усложняете. Надо будет починить или поменять — почините или поменяете, когда прийдет время. Благо, простые решения легко менять.

а потом начнется веселье, когда продукт начнут использовать больше, чем планировалось изначально, поэтому это конечно правильный принцип, но он не всегда хорош.

ВНЕЗАПНО начинается, да? Ну, это, исключительная ситуация.

обычно без предупреждения.....

Ну. это однозначно просчет менеджемнта, а не инженеров, правда?

только в результате нагибают последних, а это не самое радостное чувство в жизни....

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

KISS+YAGNI рулят, НО только если при этом обеспечивается ДОСТАТОЧНАЯ (в каждой задаче определяется по своеиму) гибкость решения.

Благо, простые решения легко менять.
Возможно у нас разное понимание «простоты». В моем понимании в ООП простое решение — это как раз не гибкое (YAGNI = никакой закладки на будущее расширение). А гибкое — это как раз не простое (много классов, интерфейсов, везде шаблоны, инверсия зависимостей, фабрики и т.д.).
В итоге если слабая связанность и гибкость не были заложены в архитектуру изначально «на вырост», то серьезно поменять реализацию не проще, чем переписать все заново.

Инверсия зависимостей — это как раз простое и понятное решение. А остальное — это рефакторинг. Простой код рефакторить легко и просто.

це нонсенс. DRY таки дещо суперечить KISS. як і взагалі абстракції та архітектурі.
застосовувати завжди треба разом. і архітектуру ставити кутовою.
згоден з опонентом по гілці: зміни приходять раптово. і це не є прорахунок.
архітектура — це те що міняється рідко і відповідно має бути продумана не agile, і навіть не lean.
lean у цёму випадку обходиться обтікаючими фразами, що це просто не зовсім точна територія, чи це приносить явний прибуток продукту, чи ні.
але з мого боку це виглядає як непослідовність.
узагальнюючи по порад:
KISS, YAGNI але якщо пишемо код не аби забути,
то кожну задачу треба вирішити на ледь помітну ёту більш загально ніж мінімум.
і відповідно не забути узагальнити із уже написаним кодом
(і якщо це не випадкова загальність).
YAGNI прекрасно підходить опісля, аби рубати старовини.
KISS теж, аби спростити ті гори тупого коду в лаконічний і простий для розуміння.
програмування — ремесло, розробка програм — мистецтво.

Это опасное заблудение, что чем решение проще, тем легче его поменять.
Как правило индусы пишут офигительно простой код, который совершенно анмейнтейнабл

Они пишут сложный и запутанный код. Копипаст как раз к такому коду ведет.

Я в 100% случаев могу понять индийский код без дополнительных комментариев, значит он простой. Ну, да, там до ужаса много копипасты, но он простой как 5 копеек, повторенные 100 раз.

А вот качественный, элегантный, расширяемый код, который легко тестировать, обычно для понимания, и особенно для понимания его гениальности, практичности и удобства, требует хорошей подготовки.

Это вас кто-то обманул. Хороший код всегда легко читается.

Я сказал, что он требует определенный уровень. Про легкость чтения *кем угодно* я не писал.

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

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

Т.е. опять таки. Легкость чтения, она зависит от читателя, не только от писателя. Кто читать не умеет, то хороший код, что бисер свиньям.

Ибо все кажется простым, проще некуда.

В этом-то и вся проблема. Когда кажется, креститься нужно, а не считать свой код гениальным, просто требующим минимум пяти лет опыта для понимания.

Т.е. «сантехник дядя Вася» поймет код, который по Вашему мнению является простым и понятным, на том основании что

Это вас кто-то обманул. Хороший код всегда легко читается.

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

Т.е. с парой месяце поймет, а с неделей не поймет? Ай, ай, ай. А я ведь говорил, что зависит от уровня. А вы — всегда да всегда....

Вам обязательно в любом споре победить, да? Ну, ок. Вы — победили!1

Спасибо. Есть у меня такая слабость — люблю придираться к категорическим суждениям.

И еще, что делать со специализированным кодом. Как, я надеюсь, в шутку сказал Рихтер, люди либо понимают многопоточное программирование, либо нет.

А как с функциональным программированием? Комбинаторы, замыкания и прочие вкусности позволяют писать лаконичный и понятный код. Но всем ли понятный? Двух месяцев изучения императивного программирования для этого хватит? А ведь с императивных языков начинают почти все.

Да. Хороший код на любом языке будет понятен любому, кто знает синтаксис этого языка и как его применять.

Впрочем, мне нарвится ваша уверенность. Продолжайте в том же духе. Чем больше программистов, уверенных в том, что хороший код должно быть нелегко читать, тем больше зарплаты у тех, кто пишет по-настоящему простой и понятный код.

Хороший код на любом языке будет понятен любому, кто знает синтаксис этого языка и как его применять.

О, ну наконец-то! Вот он, наш общий знаменатель, так сказать.

Ну вот видите, вы обвиняете меня в неумении понимать,а сами тем временем перескакиваете с темы на тему. То мы обсуждаем простой код, то, внезапно, гениальный, который при этом простой, но требует подготовки. Я такие разговоры поддерживать не умею, извините.

спасибо, ничего нового но очень полезно)

Думаю зависит от случая. Если клиент пожирней и есть вероятность срубить побольше денег, на доделках/переделках и поддержке системы — то лучше абстрагировать абстракции, ну и в ином случае действительно экономить силы.

мне больше нравиться расшифровка KISS как keep it simple stupid :)

YAGNI рулит! только не знал что он таким акронимом представляется. спасибо

Поздравляю с открытием экстремального программирования!

www.extremeprogramming.org/rules.html (конкретно, секция Designing)

Да я вообще в своих колонках чаще всего банальные истины пишу. С надеждой, что одному или нескольким (нескольким. Лучше нескольким) юным падаванам это поможет перейти на правильную сторону Силы.

Просто HtDP почитайте, друзья.

Детальнее об этих и других принципах можно найти здесь: www.artima.com/...p?thread=331531

DRY противоречит KISS
А почему противоречит? Поясните.

Потому что отсутсвие повторения [кода] ведет совсем не к simple&stupid решениям, а к сложным абстракциям с кучей слоев и т.д. Не, конечно лучше быть богатым и здоровым чем бедным и больным, но в реальности в лучшем случае можно выбрать что-то одно.

Потому что отсутсвие повторения [кода] ведет совсем не к simple&stupid решениям, а к сложным абстракциям с кучей слоев и т.д.

С чего бы это? (Предполагается, что руки достаточно прямые)

Хотя да если забыть про существование всего и оставить одно наследование, то так и получитсо. Но тут снова же проблема в кривизне рук, а не в противоречие.

Какое-то оочень сильное предположение, которое с реальностью не вяжется. Руки у всех разные, с разной кривизной. Если взять «в среднем», то они будут отнюдь не идеальной прямоты, и следование DRY все-таки приведет к более сложному с точки зрения организации коду, нежели KISS.

Какое-то оочень сильное предположение, которое с реальностью не вяжется.

У кого какая реальность :)

хочется заметить, что восприятие simple нередко есть субъективным. то, что для одного кажется простым в силу привычки, опыта и прочих факторов, для другого может оказаться именно нагромождением фабрик фабрик. для себя стараюсь руководствоваться следующим принципом: чем быстрее объяснить человеку, который не в теме, тем удачнее выбранное решение.

Да, согласен.

Как говорится — «спасибо, кэп».

досить складно написано, спробуй простіше

23-летним сениорам, и всем, всем, всем посвещается — gettingreal.37signals.com/GR_rus.php

Эти принципы противоречат тому факту, что поменяется всё и полностью. В конце-концов, маниакальное желание написать фреймфорк и настроить фабрик не на пустом месте возникли, а как реакция живого, ранимого, остро чувствующего, организма программиста на постоянные изменения требований.

Принципы хорошие и идеально подходят для соответствующих задач. Осталось только найти человека который будет гарантом того, что задачи такими и останутся. Иначе придётся не городить фреймворки, а просто сделать ещё одно приложение по принципам YAGNI и KISS. А потом ещё и ещё и ещё. И это будет всё тот же маленький финансовый планировщик который вначале казался таким

short & simple.

Фреймворки пусть пишут большие опытные команды (см. Спринг, например). А обычная небольшая команда напишет, скорее всего, велосипед. А большая — велосипед со встроенной кофеваркой.

Фреймворк слишком широкое понятие чтобы оставлять его только для больших команд. Тем более многие из них пишут таки маленькие команды от 1 до нескольких человек.

Есть фреймворки разработки, типа MVC или Hibernate. Их на каждом проекте писать не нужно — могут забрать в психушку. А фреймворк приложения, как набор интерфейсов, библиотек и правил — навеное, имеет право на жизнь очень часто.

Тут не будет разницыв между фреймворком и собственно вашим продуктом.

Если не перносит успешную практику фреймворка приложения на другое приложение то не будет. А если ты помнишь, что в прошлый раз пять слоёв архитектуры тебя здорово выручили то и в следующем приложении начнёшь именно с них. Формально у каждого приложения будет свой фреймворк, но только потому, что создать такой общий BestPracticFramework навеное не реально.

Сомневаюсь, что все каждый раз пишут аутентификацию по новой.

Аутентификация есть готовая, в виде фреймворков, созданых как я написал. Ну то есть все основные фреймворки нам умные люди уже написали, не нужно писать велосипед.

Есть ещё кодогенерация. Такой псевдо фреймворк приложения.

KISS — Keep it simple, stupid. Так оно как-то ближе к теме звучит, short к делу отношения мало имеет. Лучше просто, чем коротко.

Да, это классическая расшифровка. Но она грубовата, можно и без этого.

Ок, я согласен на «keep it simple stupid», слишком много людей вокруг меня в разное время думало, что коротко — это очень хорошо. %)

Это если считать, что stupid — обращение, в чем я лично глубоко сомневаюсь. На мой скромный взгляд это значит «Делай просто, тупо».

И так, и так можно перевести. А «коротко» — очень часто синоним «хорошо и понятно».

Подобн. аналог. спосбн. привест. к недоразум.

main(int c,char**v){return!m(v[1],v[2]);}m(char*s,char*t){return *t-42?*s?63==*t|*s==*t&&m(s+1,t+1):!*t:m(s,t+1)||*s&&m(s+1,t);}

© en.wikipedia.org/...e-liner_program

Это не коротко. Много символов. И тут уже вступают другие принципы — про количество действий на строчку, например.

розшифровка не єдина.
мені ближче “keep it stupid simple”.
звернення ’stupid’ ўже може викликати образу, а не нагадати Дейкстрівське
“The competent programmer is fully aware of the limited size of his own skull.
He therefore approaches his task with full humility, and avoids clever tricks like the plague.”
www.brainyquote.com/...dijk204340.html

в цёму відношенні британський варіант ’sir’ більш політ-коректний :)

:)

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

Brian Kernighan, “The Elements of Programming Style”, 2nd edition, chapter 2

Если предположить что википедии верить можно, то en.wikipedia.org/.../KISS_principle

KISS is an acronym for the design principle articulated by Kelly Johnson, Keep it simple, Stupid!.

Поскольку мы видим, что Stupid с большой буквы, то это именно обращение к некоторому человеку. Наверное не очень умному. Каковыми все мы являемся порой.

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

Подписаться на комментарии