что такое kiss принцип
Принципы для разработки: KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама
Хорошему программисту необходимо уметь совмещать свои навыки со здравым смыслом. Все дело в прагматизме и навыке выбора лучшего решения для вашей проблемы. Когда вы сталкиваетесь с проблемой при разработке ПО, вы можете воспользоваться базовыми принципами, которые помогут в выборе самого правильного подхода.
Последовательное применение этих принципов упростит ваш переход от миддла к сеньору. Вы можете обнаружить, что некоторые (вероятно) вы применяете интуитивно.
Принципов много. Мы остановимся на семи самых важных. Их использование поможет вам в развитии и позволит стать лучшим программистом.
1. YAGNI
You Aren’t Gonna Need It / Вам это не понадобится
Этот принцип прост и очевиден, но ему далеко не все следуют. Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже.
Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.
Может наступить день, когда они снова понадобятся – тогда вы сможете воспользоваться git-репозиторием, чтобы воскресить их из мертвых.
2. DRY
Don’t Repeat Yourself / Не повторяйтесь
Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру».
Идея вращается вокруг единого источника правды (single source of truth — SSOT). Что это вообще такое?
В проектировании и теории информационных систем единый источник истины (SSOT) – это практика структурирования информационных моделей и схемы данных, которая подразумевает, что все фрагменты данных обрабатываются (или редактируются) только в одном месте… SSOT предоставляют достоверные, актуальные и пригодные к использованию данные.
Использование SSOT позволит создать более прочную и понятную кодовую базу.
Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом.
В большинстве случаев дублирование кода происходит из-за незнания системы. Прежде чем что-либо писать, проявите прагматизм: осмотритесь. Возможно, эта функция где-то реализована. Возможно, эта бизнес-логика существует в другом месте. Повторное использование кода – всегда разумное решение.
3. KISS
Keep It Simple, Stupid / Будь проще
Этот принцип был разработан ВМС США в 1960 году. Этот принцип гласит, что простые системы будут работать лучше и надежнее.
У этого принципа много общего с переизобретением колеса, которым занимались в 1970-х. Тогда он звучал как деловая и рекламная метафора.
Применительно к разработке ПО он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.
Иногда самое разумное решение оказывается и самым простым. Написание производительного, эффективного и простого кода – это прекрасно.
Одна из самых распространенных ошибок нашего времени – использование новых инструментов исключительно из-за того, что они блестят. Разработчиков следует мотивировать использовать новейшие технологии не потому, что они новые, а потому что они подходят для работы.
4. Big Design Up Front
Глобальное проектирование прежде всего
Этот подход к разработке программного обеспечения очень важен, и его часто игнорируют. Прежде чем переходить к реализации, убедитесь, что все хорошо продумано.
Зачастую продумывание решений избавляло нас от проблем при разработке… Внесение изменений в спецификации занимало час или два. Если бы мы вносили эти изменения в код, на это уходили бы недели. Я даже не могу выразить, насколько сильно я верю в важность проектирования перед реализацией, хотя адепты экстремального программирования предали эту практику анафеме. Я экономил время и делал свои продукты лучше, используя BDUF, и я горжусь этим фактом, чтобы там ни говорили фанатики экстремального программирования. Они просто ошибаются, иначе сказать не могу.
Многие разработчики считают, что если они не пишут код, то они не добиваются прогресса. Это неверный подход. Составив план, вы избавите себя от необходимости раз за разом начинать с нуля.
Иногда в недостатках и процессах разработки архитектуры должны быть замешаны и другие люди. Чем раньше вы все это обсудите, тем лучше будет для всех.
Очень распространенный контраргумент заключается в том, что стоимость решения проблем зачастую ниже стоимости времени планирования. Чем с меньшим количеством ошибок столкнется пользователь, тем лучше будет его опыт. У вас может не быть другого шанса справиться с этими ошибками.
5. SOLID
Это наиболее известный принцип разработки ПО. Solid — это аббревиатура от:
S) Single-responsibility principle /Принцип единственной ответственности
Его важность невозможно переоценить. Каждый объект, класс и метод должны отвечать только за что-то одно. Если ваш объект/класс/метод делает слишком много, вы получите спагетти-код. Вот пример:
Этот метод кажется безобидным, но на самом деле он делает слишком много:
O) Open–closed principle / Принцип открытости-закрытости
Программные объекты должны быть открыты для расширения, но закрыты для модификации. Речь о том, что нельзя переопределять методы или классы, просто добавляя дополнительные функции по мере необходимости.
Хороший способ решения этой проблемы – использование наследования. В JavaScript эта проблема решается с помощью композиции.
Простое правило: если вы изменяете сущность, чтобы сделать ее расширяемой, вы впервые нарушили этот принцип.
L) Liskov substitution principle / Принцип подстановки Лисков
Этот принцип гласит, что объекты старших классов должны быть заменимы объектами подклассов, и приложение при такой замене должно работать так, как ожидается.
I) Interface segregation principle / Принцип разделения интерфейсов
Этот принцип был сформулирован Робертом Мартином, когда он консультировал Xerox, и он очевиден.
Объекты не должны зависеть от интерфейсов, которые они не используют
ПО должно разделяться на независимые части. Побочные эффекты необходимо сводить к минимуму, чтобы обеспечивать независимость.
Убедитесь, что вы не заставляете объекты реализовывать методы, которые им никогда не понадобятся. Вот пример:
Не все животные могут fly, walk или swim, поэтому эти методы не должны быть частью интерфейса или должны быть необязательными.
D) Dependency inversion principle / Принцип инверсии зависимостей
Этот принцип невозможно переоценить. Мы должны полагаться на абстракции, а не на конкретные реализации. Компоненты ПО должны иметь низкую связность и высокую согласованность.
Заботиться нужно не о том, как что-то устроено, а о том, как оно работает. Простой пример – использование дат в JavaScript. Вы можете написать для них свой слой абстракции. Тогда если у вас сменится источник получения дат, вам нужно будет внести изменения в одном месте, а не в тысяче.
Иногда добавление этого уровня абстракции требует усилий, но в конечном итоге они окупаются.
В качестве примера взгляните на date-io, в этой библиотеке создан тот уровень абстракции, который позволяет вам использовать её с разными источниками дат.
6. Avoid Premature Optimization
Избегайте преждевременной оптимизации
Эта практика побуждает разработчиков оптимизировать код до того, как необходимость этой оптимизации будет доказана. Думаю, что если вы следуете KISS или YAGNI, вы не попадетесь на этот крючок.
Поймите правильно, предвидеть, что произойдет что-то плохое – это хорошо. Но прежде чем вы погрузитесь в детали реализации, убедитесь, что эти оптимизации действительно полезны.
Очень простой пример – масштабирование. Вы не станете покупать 40 серверов из предположения, что ваше новое приложение станет очень популярным. Вы будете добавлять серверы по мере необходимости.
Преждевременная оптимизация может привести к задержкам в коде и, следовательно, увеличит затраты времени на вывод функций на рынок.
Многие считают преждевременную оптимизацию корнем всех зол.
7. Бритва Оккама
Бри́тва О́ккама (иногда ле́звие О́ккама) — методологический принцип, в кратком виде гласящий: «Не следует множить сущее без необходимости» (либо «Не следует привлекать новые сущности без крайней на то необходимости»).
Что это значит в мире программирования? Не создавайте ненужных сущностей без необходимости. Будьте прагматичны — подумайте, нужны ли они, поскольку они могут в конечном итоге усложнить вашу кодовую базу.
Заключение
Эти принципы не очень сложны. На самом деле, именно простота делает их красивыми. Если вы сбиты с толку, не пытайтесь применять все их сразу. Просто постарайтесь работать осознанно и пробуйте постепенно включать эти принципы в свой рабочий процесс.
Использование базовых, но действенных принципов позволит вам стать лучшим программистом и иметь более четкое представление о том, почему вы что-то делаете.
Если вы применяете большую часть принципов интуитивно, стоит задумываться и осознавать почему вы делаете что-то определенным образом.
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.
У вас будет возможность разрабатывать софт разного уровня, тестировать, запускать в производство и видеть в действии готовые автомобильные изделия, к созданию которых вы приложили руку.
В компании организован специальный испытательный центр, дающий возможность проводить исследования в области управления ДВС, в том числе и в составе автомобиля. Испытательная лаборатория включает моторные боксы, барабанные стенды, температурную и климатическую установки, вибрационный стенд, камеру соляного тумана, рентгеновскую установку и другое специализированное оборудование.
Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.
Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.
У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.
Принцип KISS в программировании
Программисты не любят сложный код и придумывают правила, чтобы сделать его проще. Разбираемся, что это за правила и как их соблюдать.
Ситуация: разработчик не понял задачу, запутался в коде и сорвал дедлайн проекта. Такое может случиться по разным причинам, но часто проблемы возникают из-за нарушения принципа KISS. Разберёмся, что это значит.
Что такое KISS
Принцип KISS — это когда вы берёте задачу и решаете её простым способом:
Когда вы не делаете лишнего, появляются простой понятный код и надёжная программа, которая решает проблему заказчика.
Аббревиатура KISS расшифровывается «keep it short and simple» — «делай кратко и просто». Её придумал авиаконструктор Кларенс Джонсон незадолго до Второй мировой. Он требовал от своих инженеров простых чертежей и инструкций — было важно, чтобы по этим документам фронтовые авиамеханики смогли самостоятельно разобраться с большинством повреждений и починить самолёт.
Для этого инженерам пришлось отбросить сложную терминологию и писать настолько просто, насколько это было возможно. Позже принцип KISS перекочевал в проектную документацию ВМС США, распространился на разные сферы, а теперь стал неотъемлемой частью программирования.
Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.
Зачем нужно
Часто программисты измеряют свой успех не качеством готового приложения, а числом строк кода — смотрят на объём проделанной работы. Если программа получается короткой — автор чувствует неудовлетворённость и забывает о времени, которое потратил на изучение, алгоритмы и тестирование.
Если использовать принцип KISS, внимание переносится с рабочего процесса на результат. Когда программа работает и справляется с поставленной задачей, неважно, сколько в ней строчек.
Если ты принимаешь это для себя, то начинаешь пользоваться простыми решениями, которых раньше избегал. Так появляется качественный компактный код, который удобно обслуживать. Если не принимаешь — скорее всего, просто не хочешь делать работу, смысл которой тебе не очень понятен.
Каждый выбирает, что ему больше подходит. Например:
❌ Написать код, и все сразу увидят, какой я крутой разработчик и сколько знаю. Не зря же я оканчивал курсы по программированию и решал задачки.
❌ Я уже сеньор, и мой код должен чем-то отличаться от кода джуна. Не могу же я написать обычную программу, с которой справится каждый стажёр.
✅ Написать код, который решит поставленную задачу и будет понятен другим разработчикам. Вдруг я заболею — надо же, чтобы его кто-то обслуживал.
Как это использовать
Шаг 1. Выучите общепринятые стандарты своего языка программирования. Например, для Python это руководство по стилю PEP 8 — без базовых знаний вы не сможете создавать простой код, понятный всем участникам команды.
Шаг 2. Научитесь правильно разбираться в задаче: вы должны понимать, при каких условиях работа будет считаться выполненной.
Например, тема этой статьи — принцип KISS в программировании. Пишем её для новичков, поэтому важно ответить всего на три вопроса: что такое принцип KISS, зачем он нужен и как им пользоваться при написании кода. Если в тексте с этим всё понятно — работа считается выполненной и можно заканчивать.
С программами похожая ситуация: сначала определяем конечную цель, затем составляем список шагов для её достижения, выбираем инструменты и только после этого переходим к работе. Так мы будем знать, что и зачем делать и какую простейшую версию кода использовать для решения задачи.
Когда будете разбираться в задаче, не поступайте как многие новички: не замыкайтесь в себе и не донимайте коллег чрезмерно.
❌ Новичок не понимает задачу и не обращается к коллегам за помощью: пишет неправильный код, получает много замечаний и постоянно всё переделывает. Это тормозит разработку продукта.
❌ Новичок не пытается разобраться в задаче и сразу обращается за помощью к опытным коллегам — эксплуатирует soft skills и ставит других в положение, когда отказывать неудобно.
✅ Чтобы разобраться в задаче, нужен баланс между hard и soft skills: сначала попробовать справиться самому, отметить проблемные моменты, поискать ответы, составить компактный список непонятных вопросов и уже с ними идти за помощью к коллегам. Программисты — лояльный и дружелюбный народ без предвзятого отношения к джунам. Но человеческий фактор остаётся: никому не хочется быть нянькой, если человек даже не пробовал вникнуть в задачу.
Шаг 3. Проанализируйте готовый проект: нужно понимать, какую функцию выполняет каждый фрагмент кода и как он устроен. Оставьте простой код, а сложный перепишите или отправьте на рефакторинг.
Для анализа подойдёт метод визуального скрининга — когда вы скроллите проект и отмечаете каждый экран своим цветом:
В любом проекте нужно стремиться к тому, чтобы окрасить большинство экранов в зелёный цвет. Это значит, что код соответствует принципу KISS:
Возьмём три проекта, разделим каждый проект на девять экранов и составим цветовую карту — найдём проблемные зоны, где не соблюдается принцип KISS:
Что в итоге
А если коротко и по-простому, то нужно запомнить и начать применять на практике три основные вещи:
Попробуйте — всё получится!
Где учиться программированию?
У Skillbox — более 50 крутых курсов по программированию. Разработка на Java, PHP, C#, Python и других языках, Data Science, разработка игр на Unity, кибербезопасность, разработка мобильных приложений…
Начать учиться можно сразу, а платить за учёбу — позже. Обучение онлайн, в удобном для вас режиме. А ещё мы помогаем с трудоустройством.
Сколько функций нужно продукту: обзор знаменитых законов программирования
Ко дню IT-аналитика собрали знаменитые законы и принципы, которые говорят о функциональном содержании информационных систем. Что такое KISS, YAGNI, Feature Creep и Bloatware — читайте в материале.
Разработка программного обеспечения — достаточно зрелая индустрия, в которой коллективный опыт зафиксирован в виде эмпирических правил и законов, не раз проверенных на практике. Существуют принципы, связанные с написанием кода, управлением разработкой, контролем качества, многие из которых пришли из других сфер, но обрели вторую жизнь в IT.
24 сентября профессиональный праздник отмечают системные аналитики, по этому поводу собрали законы и принципы функционального наполнения ПО.
Применимо к разработке, закон Галла говорит, что не следует гнаться за количеством функций и делать ПО, которое сразу решает несколько задач. Вместо этого, сперва следует разработать продукт, который фокусируется на чем-то одном, что потенциально даст потребителям ценность.
Требования к новой системе не будут окончательно известны, пока ей не начнут пользоваться
Любое первоначальное представление о том, каким должно быть ПО, скорее всего, неверное. Здесь можно вспомнить историю о руководителе института, который велел дождаться, пока студенты сами протопчут тропинки там, где им удобнее ходить, и только потом их асфальтировать. В разработке первая версия продукта часто оказывается черновой, но она позволяет проверить ряд гипотез и учесть полученные знания при создании последующих версий.
ПО, которое имеет ограничения, но простое в использовании, более востребовано пользователем и рынком, чем не имеющее ограничений, но сложное для понимания
В текущей борьбе за внимание пользователь должен как можно быстрее дойти до момента, в котором он понимают всю пользу продукта. Чем сложнее разобраться в приложении, тем выше коэффициент оттока, а люди редко готовы давать второй шанс.
Пользователи проводят большую часть своего времени на других сайтах. Это означает, что пользователи предпочитают, чтобы ваш сайт работал так же, как и все другие сайты, которые им уже знакомы
Закон Нильсена говорит, что при разработке нужно опираться на понятные шаблоны взаимодействия, чтобы пользователь мог сосредоточиться на своей задаче, а не учиться использовать что-то новое. Чтобы влиять на пользовательские привычки, нужна очень лояльная аудитория.
О том, что надо быть проще не только в отношении функционального наполнения, но и в подходя к разработке, говорят два забавно-звучащих принципа YAGNI и KISS.
YAGNI (You aren’t gonna need it; с англ. — «Вам это не понадобится») — принцип проектирования ПО, направленный на отказ от избыточной функциональности.
Всегда реализуйте функции только тогда, когда они вам реально нужны, а не тогда, когда вам кажется, что они вам понадобятся в будущем
Здесь также речь о том, что разумно разобраться в одной проблеме, которую стремится решить ваш продукт. Чем сильнее вы распыляетесь, тем более неуправляемым и невостребованным станет проект. Прагматизм подхода в том, что он предлагает сосредоточиться на решении самой важной проблемы, а не всех проблем одновременно, сосредоточиться на текущем моменте, а не пытаться предсказывать будущее.
KISS (Keep it simple, stupid, с англ. «Делай проще, глупец») — подход, который предлагает реализовать решение самым простым способом, утверждая, что большинство систем работают лучше, если они остаются простыми, а не усложняются.
Автор подхода американский авиаконструктор Кларенс Джонсон призывал создавать самолеты так, чтобы в боевых условиях их мог починить средний механик с базовым набором инструментов.
KISS намекает на то, что решение всегда должно оставаться достаточно простым, чтобы любой член вашей команды мог легко понять его, не зная, как в настоящее время работает код. Конечно, некоторые сложные проблемы требуют комплексных решений, но часто случается так, что программисты увлекаются новыми инструментами и применяют их в работе, даже если они не соответствуют задаче.
Все вышеперечисленные принципы твердят, что ПО должно быть простым с наименьшим количеством функционала. Но откуда же тогда берутся сложные приложения, супераппы и экосистемы? По этому поводу в индустрии тоже сформулирован ряд законов. Далее рассмотрим их.
Знаменитый закон Паркинсона о том, что любая работа занимает все время, отведенное на ее выполнение, применительно к IT также говорит, что ПО расширяет функциональность до тех пор, пока не задействует все предоставленные ресурсы. Добавьте сюда закон Мура о том, что количество транзисторов на микросхемах удваивается каждые два года, и вы получите бесконечно расползающуюся функциональность (англ. feature creep) и раздуваемое ПО (англ. bloatware).
Два понятия неразрывно связаны друг с другом — первое обозначает процесс добавления в программный продукт все больше и больше возможностей, а второе — результат этого процесса — более медленное и менее эффективное ПО.
Каждая программа развивается до тех пор, пока не сможет читать почту. Программы, которые не способны так развиться, вытесняются теми, что смогут
Закон Завински указывает на тенденцию программ увеличивать функциональность с течением времени и, как следствие, усложняться. Для примера возьмем Instagram. Изначально это приложение для постинга фотографий с ретро фильтрами, доступное только на iPhone. Сейчас это интернет внутри интернета — функциональность приложения давно перешагнула фазу обмена сообщениями и теперь в нем можно вести видеотрансляции, применять AR-эффекты, слушать музыку и продавать товары. И все это также доступно на Android и частично в вебе.
Как показывают исследования, пользователи активно используют только 20% функций цифровых продуктов, а 45% возможностей не используют совсем. Как тогда объяснить раздувание? Вся проблема в том, что для разных групп пользователей эти 20% наиболее востребованного функционала разные, поэтому при отказе от функций сильно сужается круг пользователей.
Что касается простоты решения, то здесь в противовес принципу KISS можно привести закон сохранения сложности Теслера.
У любой системы есть порог сложности, опуститься ниже которого невозможно. Как только вы достигнете этой точки, вы сможете только переложить бремя
Создатель команды Ctrl+C/Ctrl+V указывает на то, что либо разработчику придется усложнять программный код, чтобы упростить взаимодействие для пользователя, или пользователь будет вынужден иметь дело со сложным интерфейсом, чтобы программный код мог оставаться простым.
Индустрия разработки долга шла к тому, чтобы разрабатывать продукт итеративно, мелкими шагами, чтобы постепенно представлять функционал и быстро собирать обратную связь от пользователей и вносить на ее основе изменения.
Многие из перечисленных правил нашли отражение во фреймворках и методологиях по управлению разработкой. Они субъективны как для человека, который их применяет, так и для ситуации, в которой они применяются, но если хотя бы принимать их во внимание, то гарантированно получится уменьшить количество неиспользуемого кода, а также усилий и ресурсов на функциональность, не приносящую пользы.
Спасибо, что дочитали до конца! Это блог IT-продакшна Work Solutions.
Мы занимаемся аутсорсингом и аутстаффингом: создаем веб-приложения на заказ и усиливаем штат наемных специалистов.