KISS — принцип проектирования, содержащий все остальные принципы проектирования
Если проект прост, его легко понять… Разработать простой проект не так легко. Для этого нужно время. Для всякой сколько-нибудь сложной программы окончательное решение получается в результате анализа огромного объема информации. Когда код хорошо спроектирован, кажется, что он и не мог быть иным, однако возможно, что его простота достигнута в результате напряженного умственного труда (и большого объема рефакторинга). Сделать простую вещь сложно. Если структура кода кажется очевидной, не надо думать, что это далось без труда.
Итак, принцип проектирования KISS (keep it simple and straightforward) провозглашает, что простота кода – превыше всего, потому что простой код – наиболее понятный.
Практически все принципы проектирования направлены на достижение понятности кода. Нарушая какой-либо принцип проектирования, вы уменьшаете понятность кода. Непонятный код автоматически вызывает у человека ощущение того, что код сложный, так как его сложно понимать и модифицировать. При нарушении любого из этих принципов также нарушается и принцип KISS. Поэтому можно говорить, что KISS включает почти все остальные принципы проектирования.
Патерны проектирования описывают наиболее удачные, простые и понятные решения некоторых проблем. Если вы используете паттерн проектирования там, где нет проблемы, которую решает данный паттерн – то вы нарушаете KISS, внося ненужные усложнения в код. Если вы НЕ используете паттерн проектирования там, где есть проблема, соответствующая паттерну – то вы опять-таки нарушаете KISS, делая код сложнее, чем он мог бы быть.
На мой взгляд, принцип KISS может быть полезен лишь для начинающих проектировщиков, которые не знают или не понимают основных принципов проектирования. KISS защищает от неверного использования принципов проектирования и паттернов. Поскольку принципы и паттерны предназначены для увеличения понятности кода, то их правильное использование не может привести к уменьшению понятности кода. Однако если вы неверно понимаете принцип проектирования (например, истолковываете «не плодите лишних сущностей» как «плодите как можно меньше сущностей»), или соблюдая один принцип нарушаете десяток других, то KISS может стать для вас надёжной подушкой безопасности. В остальных случаях от KISS-а мало толку, т.к. он слишком общий и абстрактный. Остальные же принципы более конкретны и содержат более явные пути к достижению понятности и простоты кода.
Всвязи с тем, что представления разных людей о таком понятии как «простота» могут различаться, приобрели широкое распространение следующая заблуждения относительно KISS-a:
Заблуждение 1. Если считать, что простой код – это такой код, который проще всего написать, то можно истолковать, что принцип KISS призывает писать первое что взбредёт в голову, вообще не задумываясь о проектировании.
Заблуждение 2. Если считать, что простой код – это такой код, для написания которого требуется как можно меньше знаний, то можно истолковать, что принцип KISS призывает не использовать паттерны проектирования.
Пример на C#
Задача: При пересечении фигур необходимо заштриховать область их пересечения.
Так как разработать универсальный алгоритм штриховки для разных сочетаний
фигур (прямоугольник-прямоугольник, прямоугольник-многоугольник,
многоугольник-многоугольник, эллипс-многоугольник, эллипс-эллипс) довольно
сложно и он скорей всего будет не очень эффективным, то реализуем для каждого
вариант свой алгоритм.
Как выглядит первое что приходит в голову:
Однако этот код противоречит двум пунктам из определения простоты: самый естественный и легко доступный для понимания. Код не естественный, потому что есть некий искусственный класс IntersectionFinder. Код не является легко доступным для понимания, потому что человеку, незнакомому с кодом, нужно будет просмотреть все места использования IShape, чтобы понять, реализован ли функционал вычисления пересечения фигур и как именно им воспользоваться. В проектах, насчитывающих несколько десятков (или даже сотен) тысяч строк кода это может оказаться не быстрым занятием. Есть ещё один неприятный момент, добавляющий трудностей к работе с классом IntersectionFinder: количество функций с именем FindIntersection возрастает в виде арифметической прогрессии от количества фигур, в результате чего класс IntersectionFinder очень быстро «раздувается» и при большом количестве фигур поиск нужной функции в нём становится затратным по времени занятием. Поэтому перенесём FindIntersection в IShape.
Отлично, теперь незнакомому с кодом программисту не придётся искать по всему проекту способ сделать пересечение двух фигур. Исчезла лишняя сущность «Вычислитель Пересечений». Код стал более естественным и легко доступным для понимания, а значит — более простым. Теперь при создании нового типа фигуры не нужно вносить изменения в ранее созданные классы, а значит добавление новых типов фигур также упростилось. Проще найти конкретный алгоритм поиска пересечения, так как теперь не нужно искать его в гигантском классе среди множества методов с одинаковыми именами.
Но теперь замечаем, что способ принятия решения, какую конкретно функцию вычисления пересечения нужно вызывать, не лишён искусственности. Более естественный подход звучал бы так: вызвать функцию с именем FindIntersection, тип аргумента которой совпадает с типом второй фигуры.
Как видно, из каждого конкретного класса фигуры исчезли методы public IShape FindIntersection(IShape shape), общее количество строк кода сократилось. Теперь добавлять новые типы фигур стало ещё проще. Метод FindIntersection(Shape shape) теперь находится в базовом классе и выглядит более просто и естественно (декларативно). Добавился новый класс MethodFinder, однако программисту не нужно знать его внутреннее устройство, т.к. он имеет понятный интерфейс и не реализует понятия из предметной области (а значит причины для его изменений будут редки), поэтому сложность кода практически не возросла при его добавлении.
Тут может возникнуть мысль, что рефлексия — медленная штука, и для ускорения можно, например, кэшировать делегаты, динамически сформированные посредством ExpressionTree, однако KISS призывает писать как можно более простой код, поэтому стоит воздержаться от этой мысли до тех пор, пока быстродействие метода FindIntersection(Shape shape) действительно не станет узким местом программы, создающим проблемы для пользователя. Но вот что не следует откладывать, так это создание юнит-теста, который через рефлексию узнаёт всех наследников класса Shape и проверяет, что программист не забыл реализовать алгоритмы поиска пересечения для всех пар фигур.
Сравнив взглядом первый и третий пример, может показаться не очевидным, что третий пример проще. Однако давайте, представим, что типов фигур не 3, а 30. Тогда количество функций сравнения фигур — 465 (сумма арифметической прогрессии (1+30)*30\2). В первом случае механизм выбора нужной функции будет скрыт за 465 if-ами (или, как вариант, за контейнером с 465-ю указателями на методы, что не сильно лучше), и среди этого нагромождения if-ов незнакомому с кодом программисту нужно будет усмотреть некую систему. Тогда как в 3-м случае подход декларативен и не зависит от количества типов фигур. Этот пример хорош тем, что значительной части программистов может показаться, что третий пример является плохим решением, так как в нём используется рефлексия для доступа к приватным переменным (что является своеобразным табу в среде программистов), потому что они слышали из авторитетных источников, что использовать рефлексию для таких целей плохо, но не могут объяснить, почему это плохо. Этот психологический феномен называется фиксированностью ценностей.
Этот пример наглядно демонстрирует, как, используя KISS и стремясь сделать код более простым, можно придти к лучшему решению проблемы, даже если ваше неверное понимание тех или иных принципов или табу приказывает вам использовать «костыль» вместо декларативного кода, полностью отражающего намерение разработчика.
Немного истории.
Принцип KISS зародился в авиастроении и исторически переводится как «Keep it simple stupid» и расшифровывается как «сделайте это до идиотизма простым». В истории авиастроения известны случаи, когда слишком усердные рабочие прибивали на самолёт лишние пластины брони, чтобы сделать самолёт более живучим в бою, в результате чего масса самолёта становилась больше расчётной и самолёт попросту не мог взлететь. Кроме того, квалификация многих рабочих была низкой. В таких условиях конструкции самолётов, которые пьяный неквалифицированный рабочий не смог бы собрать неправильно, даже если бы захотел, обладали особенной ценностью. Один из отголосков конструкторских решений того времени — невозможность перепутать и воткнуть неверный штекер в гнездо внутри компьютера. Однако, если результатом труда авиа-инженера является чертёж, по которому будет создан продукт, то в случае с программистом продуктом является сам чертёж (образно выражаясь). В случае программиста он должен написать код так, чтобы пьяный неквалифицированный программист смог внести в него изменения в соответствии с изменившимися бизнес-требованиями (то есть изменить чертёж, а не собрать самолёт). В силу различий в специфике авиастроения и программирования, расшифровка «Keep it simple stupid», подходящая в авиастроении, уже не так хорошо отражает суть принципа для программиста. Многие ленивые программисты расшифровывают «сделайте это до идиотизма простым» как «не утруждайте себя проектированием» (сравните, например, описание принципа KISS в этой статье с вот этим описанием). К счастью, у KISS есть ещё и некоторые другие расшифровки, одна из которых, на мой взгляд, лучше всего отражает суть KISS в программировании — «keep it simple and straightforward». Straightforward переводится как простой, честный, прямолинейный, откровенный. «Keep it simple and straightforward», таким образом, можно вольно перевести как «Сделайте это простым и декларативным», а для достижения декларативности требуется проектирование.
За пример следует благодарить Hokum, который подал первоначальную идею для примера, которую я немного изменил.
Принцип 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:
Что в итоге
А если коротко и по-простому, то нужно запомнить и начать применять на практике три основные вещи:
Что такое принцип KISS и как использовать его в повседневной жизни?
Наверное, каждому из нас хоть раз в жизни приходилось слышать в свой адрес расхожее: «Будь проще, и люди к тебе потянутся!»
Но что на практике может означать «быть проще» — не грузиться, не сомневаться, не задирать нос?
Чтобы получить работающее руководство к упрощению собственного отношения к жизни, предлагаю применить известный в конструкторских кругах принцип KISS.
KISS — это акроним фразы «Keep It Simple, Stupid» (в вольном переводе это звучит как «Будь проще, идиот»). Другие версии расшифровки не столь обидны. Например: «Keep It Sweet & Simple» (Пусть будет просто и сладко), «Keep It Short & Simple» (Коротко и ясно), «Keep it Simple, Sweetheart» (Короче, дорогуша!), и даже «Keep it Simple, Sherlock» (на русский адекватнее всего было бы перевести эту фразу как «Элементарно, Ватсон!»).
Автор этого универсального совета доподлинно не известен, соответственно, которая из расшифровок акронима KISS является оригинальной, неясно.
По одной из легенд, столь интересную интерпретацию философского принципа «бритвы Оккама» дал Томас Эдисон (изобретатель, обладатель около четырех тысяч патентов). Бытует такая история: Эдисон принимал на работу молодого инженера и в качестве тестового задания попросил определить объем сосуда замысловатой формы. После нескольких часов напряженных раздумий претендент представил формулы расчетов, на что Эдисон посоветовал просто наполнить сосуд водой, а затем вылить ее в емкость, объем которой известен (скажем, в литровую банку). Якобы тогда же Эдисон посоветовал инженеру-новичку «быть проще».
Итак, делая выбор (чем мы, собственно, и занимаемся каждое мгновение нашей жизни), необходимо убедиться, действительно ли найденное решение — наиболее простое из возможных, действительно ли оно решает проблему, а не усложняет ситуацию. Здесь пригодятся некоторые правила KISS:
1. Предпринятое действие должно решать самую главную проблему самым простым способом. Если вас беспокоит стена отчужденности, возникшая между вами и другом (друзьями), начните «выяснение отношений» прямо с этого вопроса, а не с обходных маневров вроде: кто из вас дольше занят на работе и кто последний раз не вымыл ванную.
2. Не надо делать решение сложнее, чем исходная проблема. Друзья захотели собраться на вечеринку у вас дома? Прекрасно. Но не надо делать из этого мероприятия костюмированный бал с тремя переменами блюд и фейс-контролем на входе.
3. Не меняйте правила игры. Не требуйте от людей освоить новый вид деятельности (выучить язык, научиться водить автомобиль, кататься на лыжах) для того, чтобы они имели честь общаться с вами.
4. Решение должно быть гибким. Если встретиться (поболтать) с вами можно только при соблюдении многих ограничений — во времени, пространстве, ресурсах — с вами действительно непросто иметь дело.
5. Придерживайтесь правила 90/90. Нельзя нравиться всем. Максимум, что возможно, — устраивать 90% своих знакомых и друзей на 90%. Оставьте за собой право на недостатки!
Что нужно знать о КИС «АРТ» таксопаркам и водителям такси
Рассказываем подробно, что такое КИС «АРТ», как в ней зарегистрироваться таксопаркам и водителям, выполняющим заказы в Москве и Московской области.
КИС «АРТ» — система контроля за деятельностью такси, в неё включены все участники рынка таксомоторных перевозок. Заказчик системы — Департамент транспорта г. Москвы.
Система будет следить за тем, чтобы водители не перерабатывали, вовремя проходили медосмотр, а на линии были только технически исправные машины. Как предполагается разработчиками, это повысит безопасность поездок. Все, кто не будет соблюдать правила и не зарегистрируется в системе, не смогут получать и выполнять заказы такси.
Когда и где начнет действовать
Запуск системы намечен на 14 августа 2021 года в Москве и Московской области.
Для чего будет использоваться система
Кто будет пользоваться системой
Что нужно знать водителям
Чтобы продолжать получать заказы после 14 августа 2021 года, водителю необходимо получить КИС «АРТ» ID. Процедура не должна занимать много времени, и мы рекомендуем пройти её заранее. Это можно сделать двумя способами.
Первый способ: полностью самостоятельная регистрация
Второй способ: регистрация с помощью Яндекс.Про
Так у водителя будет месяц, чтобы без спешки зарегистрироваться на портале Госуслуг и подтвердить там аккаунт, а потом пройти регистрацию в КИС «АРТ». Параллельно он сможет выполнять заказы.
Если водитель в течение 30 дней не пройдет регистрацию в КИС «АРТ», временный ID перестанет действовать, а доступ к заказам будет автоматически ограничен.
Цифровой профиль (идентификатор) водителя легкового такси
Что такое идентификатор водителя легкового такси?
В 2020 году по решению Антитеррористической комиссии города Москвы организации и предприниматели, осуществляющие таксомоторную деятельность, а также диспетчерские службы заказа легковых такси (агрегаторы) стали обязаны передавать данные о водителях легковых такси в региональную навигационную информационную систему города Москвы.
Чтобы это стало возможным, Правительство Москвы создало Комплексную информационную систему «Аналитика работы такси» (КИС «АРТ»), в которой участникам процесса таксомоторных перевозок необходимо зарегистрироваться и передавать необходимый набор данных.
Нормативно-правовая база
Регистрация в качестве водителя
Регистрация в качестве таксопарка
Регистрация в качестве тех.центра
Регистрация в качестве мед.центра
Чтобы получить идентификатор водителя легкового такси необходимо:
Водителю (физическое лицо), у которого нет разрешения на осуществление деятельности по перевозке пассажиров и багажа легковым такси на территории города Москвы (Московской области)
Для упрощения получения идентификатора, рекомендуем максимально полно заполнить профиль на госуслугах. Часть данных, необходимо будет заполнить непосредственно в КИС «АРТ».
Индивидуальному предпринимателю, у которого имеется разрешение на осуществление деятельно по перевозке пассажиров и багажа легковым такси на территории города Москвы (Московской области) и который сам являетесь водителем такси.
