что такое kiss list
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:
Что в итоге
А если коротко и по-простому, то нужно запомнить и начать применять на практике три основные вещи:
Попробуйте — всё получится!
Где учиться программированию?
У Skillbox — более 50 крутых курсов по программированию. Разработка на Java, PHP, C#, Python и других языках, Data Science, разработка игр на Unity, кибербезопасность, разработка мобильных приложений…
Начать учиться можно сразу, а платить за учёбу — позже. Обучение онлайн, в удобном для вас режиме. А ещё мы помогаем с трудоустройством.
KISS LIST.
Я уже говорил, что ты странный?
@only1way2escape, народ требует продолжения истории про Леночку! А часики тикают.
P.S. мне телефон уже сам предлагает слово Леночка. Даже он желает продолжения.
Прост игрушка
Автор: Автор: daivijohn
Высокая Планка
Будем откровенны, я никогда не вычеркну ни одной страны.
Порой кажется…
Очень сильное колдунство
Признался наконец
Просто поцелуйтесь уже!
Никаких поцелуев, человечишка!
Принцесса фурри
Омела
Давай посчитаем
Когда слишком много дел
Всё записал
Слишком легко.
Западные комиксы в жанре киберпанк
Не буду особо углубляться в то, какие произведения стоит относить к киберпанку, посткиберпанку, технонуару, просто к мрачной фантастике и так далее — это дело долгое и неблагодарное. Так что в качестве руководящего принципа в составлении этой подборки комиксов я выбрал даже не знаменитое «high tech, low life», а похожесть на ряд произведений: Blade Runner, Neuromancer, Matrix, Deus Ex.
Как понятно из названия, в расчёт не брались японские комиксы: у мангак такая стилистика куда более популярна. Да и благодаря аниме лучшие японские комиксы жанра сумели добиться куда большей известности, чем у западных собратьев по стилю.
The Long Tomorrow (1975)
Начнём с комикса Дэна О’Бэннона и Мёбиуса 1975 года. Эта нуарная детективная история коротка (всего 15 страниц), но всё же смогла значительно повлиять на фантастику: Ридли Скотт взял отсюда картину огромного мегаполиса будущего, Гибсон вдохновился эстетикой фантастического нуара, художники «Звёздных войн» полностью скопировали из этой новеллы дизайн для дрона из начала «Империя наносит ответный удар». Думаю, даже авторы хентая кое что могли оттуда взять (если вы понимаете, о чём я).
Абсолютно обезбашенная итальянская серия комиксов. В мегаполисе будущего, где все помешаны на похоти и жестокости, несовершеннолетняя дочка миллионера собрала из запчастей от ксерокса для своих плотских утех Ранксерокса, похожего на Стивена Кинга, выпившего сыворотку Халка. И девочка с роботом влюбились друг в друга.
Judge Dredd (1977-до сих пор)
Мега-сити — по сути классический киберпанковский город: громадный мрачный многоуровневый муравейник из железа, стекла и бетона, тонущий в грязи и беззаконии. Вот только герой — полная противоположность классическому архетипу жанра: Джозеф Дредд — мускулистый человек-скала, живущий только ради защиты закона и существующей системы любой ценой, чаще всего — ультранасилием.
Квинтэссенция французских комиксов восьмидесятых. Великолепная стильная рисовка и сюрреалистичный сюжет, в котором чего только нет: от древнеегипетских богов-инопланетян до турниров по смеси бокса и шахмат.
Экранизация сюжетно и стилистически свернула совершенно не туда.
Графическая новелла Фрэнка Миллера о ронине, попавшем из-за демона в мрачный антиутопичный техногенный мир будущего — да, этот комикс сильно повлиял на «Самурая Джека». При этом комикс был мрачней и навороченней: аугментированные аутисты, банды нацистов, бомжи-людоеды, бесчеловечные опыты корпораций. Не лучшая работа автора с не самым проработанным окружением, но всё же довольно любопытная.
Один из первых комиксов, вдохновлявшихся «Бегущим по лезвию». Но если бы это был его единственный плюс, то Shatter уже давно затерялся бы в истории. В нём скорее примечательно то, что это первый в истории коммерческий комикс, полностью отрисованный на компьютере. Пиксельные иллюстрации, сделанные вручную мышкой на «Макинтоше» из восьмидесятых, передают дух киберпанка тех времён гораздо лучше, чем история, рассказанная с их помощью.
Hard Boiled (1990-1992)
Главному герою, живущему счастливой обыденной семейной жизнью, вдруг начинают сниться сны, где он — киборг-убийца, беспрекословно выполняющий всевозможные заказы от своих хозяев в безумном футуристичном городе. И тут он…
Да к чёрту — тут главное не сюжет. Фрэнк Миллер в сотрудничестве с Джэфом Дэрроу сумел на страницах Hard Boiled воплотить сверхдетализированное полотно из убийств и разрушений.
Сожжённая инквизицией ведьма из XV века прокляла своих убийц. В XXI веке эти демоны (да, оказалось, что они не люди) тайком захватили контроль над всем обществом и устроили ему киберпанковкую антиутопию. Но их планам мешает проклятье ведьмы, внезапно начавшее убивать.
Сюжет здесь не сказать, чтобы последователен, но визуал от Оливьера Ледруа заставляет на это обращать внимания поменьше.
2020 visions (1997-1998)
Четыре истории, четыре персонажа, четыре географических района. Четыре жанра: хоррор, криминал, вестерн, романс. И один большой киберпанк-мир, полный людей, стремящихся к изоляции из-за свирепствующей эпидемии, сделавшей большинство мужчин бесплодными.
Комикс о приключениях и быте журналиста Спайдера Иерусалима — аналога Хантера Томпсона из громадного мегаполиса будущего. Несмотря на торжество генной инженерии, рекламые вирусы в сновидениях, фабрикаторы материи, закусочные с поджаренными младенцами и прочие безумные дары прогресса люди остались прежними. Как и политики, которые, как и всегда, продолжают всячески портить жизнь.
The Matrix Comics (1999-2004)
Буду краток: «Аниматрица» от мира комиксов.
Frank Miller’s RoboCop (2003-2006)
А вы знали, что Фрэнк Миллер чуть не стал автором сценария и даже режиссёром «Робокопа 2»? К сожалению, его задумки оказались настолько масштабными и дерзкими, что продюсеры быстро отказались от его идей и решили сделать нечто попроще да подешевле, тем самым погубив серию.
Так вот, этот комикс — переложение того, какой должна была стать вторая часть «Робокопа».
100% (2002-2003) и Heavy Liquid (1999-2000)
В Heavy Liquid от того же автора разворачивается нуарная история вокруг Тяжёлой Жидкости — наркотика, дарящего гиперчувствительность.
Singularity 7 (2004)
Постапокалипсис. Нанороботы заражают Бобби Хеннигана, который после этого стремится улучшить весь мир с их помощью, загоняя человечество в глубочайшее подполье. По поверхности остаются бродить различные дубликаты людей, сделанные из наномашин.
The Surrogates (2005-2006)
Типичная детективная история с одним большим «но»: действие разворачивается в мире, где люди предпочитают взаимодействовать с социумом через «суррогатов» — роботов, напрямую управляемых удалёнными пользователями. Есть не очень хорошая экранизация с Брюсом Уиллисом.
Взгляд на мрачное будущее со стороны модифицированных африканских животных, превращённых в гуманоидные орудия убийства безумным учёным. После поражения корпорации, создавшей их, разумные звери вынуждены пытаться интегрироваться в социум, боящийся этих существ.
Batman: Year 100 (2006)
Внезапно, комикс про Бэтмена, живущего в 2039 году. И, в отличие от классической формулы, здесь есть место только Бэтмену, без Брюса Уэйна. Это автоматически противопоставляет его Готэму, в котором власти не желают оставлять своим гражданам и толики конфиденциальности.
Классический коктейль: футуристический город, импланты, нейрошнуры, хакер, стиль, навеянный «Бегущим по лезвию». Даже нечего добавить.
The Private Eye (2013-2015)
В отличие от Year 100, общество этого комикса помешано на анонимности, что им всячески дозволяется. Просто за 60 лет до событий комикса в том мире произошёл массовый слив конфиденциальной информации о каждом жителе планеты. Так что теперь всемирная паутина уничтожена, а люди ревностно сохраняют завесу тайны даже над своей внешностью.
Главный герой — частный детектив, представитель самой ненавистной профессии на Земле.
Old City Blues (2014)
2048 год. Новые Афины, построенные на руинах Греции — город, катящийся прямиком в тартарары: высочайший уровень преступности, коррупция, торговцы наркотиками на каждом углу, контрабандисты поставляют враждующим бандам новейшее вооружение. Главный герой вместе с другими полицейскими пытается не допустить окончательного падения мегаполиса.
Тот случай, когда упор в жанре «киберпанк» делается именно на «панк». Шон Мёрфи сумел сделать путешествие по урбанистическим пейзажам с убитой к чертям экологией к Токийскому Саду по-настоящему стильным, резким и драйвовым.
Empty Zone (2015-2016)
Процитирую автора: «Смесь «Нейроманта» и «Города грехов». Выражается это в том, что здесь киберпанк принимает самые крайние формы: вечная ночь, улицы — сплошной неон, а мир настолько мрачен, что не отпускает даже мёртвых, ведь местные нейроманты одновременно чуть ли не некроманты.