Знаете ли вы разницу между словами "простой" и "лёгкий"? А какое из этих слов является антонимом слова "сложный"?
Чтобы ответить на этот вопрос, обратимся к определению слова "сложность".
Сложность описывает поведение системы или модели, чьи компоненты взаимодействуют различными способами.
Получается, что "сложный" — это состоящий из большого числа элементов, взаимодействующих друг с другом. Причем, чем больше этого взаимодействия и чем более оно разнообразно, тем более сложная на выходе система.
Отсюда можно сделать вывод, что на обратной стороне находится понятие "простой". То есть состоящий из одного элемента. В общем случае, конечно, "простой-сложный" — это шкала. Какие-то вещи получаются проще, какие-то сложнее.
Самое главное, что нужно вынести из этих определений: пара простой-сложный — это объективная оценка системы или модели.
С другой стороны, в своей жизни мы часто оперируем другой парой: "лёгкий-тяжелый". И вот эта пара уже представляет собой субъективную оценку. Для нас "лёгкий", почти всегда означает "привычный".
Небезызвестный человек Rich Hickey, по совместительству создатель языка Clojure, сделал доклад с названием Simple Made Easy (Видео с русскими субтитрами), в котором подробно рассмотрел эти понятия и то, как ошибаются люди, в частности инженеры, принимая решения.
Так уж устроен мозг, что чаще мы фиксируемся на лёгкости вместо простоты. Потому что простоту увидеть гораздо труднее, ведь это непривычно.
Что дает нам лёгкость:
- Простой старт
Чем мы за это платим:
- Резкое торможение после предела
- Отсутствие нового опыта, а значит роста
- Сложные решения и подходы
И некоторые примеры из жизни программистов:
Simple | Complex
------------------|---------------
Constant | Variable
Data | Object (Hard)
Recursion (Hard) | Loop
Константы (значение) — это просто, переменные — сложно (значение, время). Данные (значения) — это просто, объекты — сложно (значение, поведение, идентификация).
Рекурсия, по сравнению с циклом, требует гораздо меньше компонентов и понятий — кроме самой функции не нужно больше ничего. При этом понять рекурсию не так легко. Справедливости ради отметим, что это касается больше тех людей, чей опыт до момента знакомства с рекурсией был сугубо императивный.
Из сказанного можно сделать вывод, что всегда есть простая альтернатива, которой можно пользоваться. Но это не так, бывают сложные задачи, требующие непростых решений. И если упрощение идёт в одном месте, то в другом, скорее всего, нужно будет усложнить.
No Silver Bullet — Essence and Accidents of Software Engineering (Fred Brooks)
Фредерик Брукс, создатель IBM/360 и автор книги "Мифический человеко-месяц", в своем эссе "No Silver Bullet" сформулировал два типа сложности, знание которых поможет вам лучше понимать свои системы.
Необходимая сложность
Определяется сложностью решаемой проблемы/предметной области.
Если перед вами стоит задача реализовать программу, которая выполняет 20 действий, то вы не можете (с точки зрения программирования, а не бизнеса) реализовать меньше и при этом выполнить задачу. Если у вас есть 5 бизнес-правил, касающихся оформления заказа (например, у вас должно быть достаточно денег на счету), то вам нужно будет их все реализовать.
Очень важно уметь выделять главное и видеть, где у вас та самая, необходимая, сложность.
Случайная сложность
Определяется проблемами, которые создают сами программисты. Например, используют неправильные инструменты для данной задачи.
Именно этот тип сложности является опасным и ведущим к краху. Неправильные процессы, подходы, библиотеки, языки — всё это, как минимум, вас сильно замедляет, удорожает разработку. И, в конце концов, может стать причиной неудачи проекта.
От этой сложности нужно избавляться всеми способами. Главное, что я хотел бы донести до вас в этом уроке: понимание того, где у вас случайная сложность, приходит только с обогащением вас как профессионала. Многие разработчики смотрят на это так: я выучу ещё 10 новых библиотек и пару новых языков и стану круче. Да, вы станете чуть лучше, но это будет совсем чуть-чуть. Потому что эти библиотеки и языки будут использовать подходы, к которым вы привыкли, и вам будет легко, а значит роста почти не будет. Единственный способ расти по-настоящему быстро и качественно — это изучать то, что даётся тяжело: языки с новыми парадигмами, другие области программирования, такие как мобильные приложения, фронтенд вместо бэкенда и наоборот.
Автоматное программирование, как раз, относится к одному из таких пунктов. Эта парадигма изменит вас (если вы позволите этому случиться) невероятно сильно и даст возможность лучше определять и искоренять случайную сложность в вашем коде.
P.S. Основные языки для роста: haskell, clojure, prolog, erlang, kotlin, c.
Остались вопросы? Задайте их в разделе «Обсуждение»
Вам ответят команда поддержки Хекслета или другие студенты
