Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 Знаете ли вы разницу между словами "простой" и "лёгкий"? А какое из этих слов является антонимом слова "сложный"?

2 Чтобы ответить на этот вопрос, обратимся к определению слова "сложность".

3 <blockquote>Сложность описывает поведение системы или модели, чьи компоненты взаимодействуют различными способами.

4 </blockquote>Получается, что "сложный" - это состоящий из большого числа элементов, взаимодействующих друг с другом. Причем, чем больше этого взаимодействия и чем более оно разнообразно, тем более сложная на выходе система.

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

6 Самое главное, что нужно вынести из этих определений: пара простой-сложный - это объективная оценка системы или модели.

7 С другой стороны, в своей жизни мы часто оперируем другой парой: "лёгкий-тяжелый". И вот эта пара уже представляет собой субъективную оценку. Для нас "лёгкий", почти всегда означает "привычный".

8 Небезызвестный человек Rich Hickey, по совместительству создатель языка Clojure, сделал доклад с названием<a>Simple Made Easy</a>(<a>Видео с русскими субтитрами</a>), в котором подробно рассмотрел эти понятия и то, как ошибаются люди, в частности инженеры, принимая решения.

9 Так уж устроен мозг, что чаще мы фиксируемся на лёгкости вместо простоты. Потому что простоту увидеть гораздо труднее, ведь это непривычно.

10 Что дает намлёгкость:

11 <ul><li>Простой старт</li>

12 </ul>Чем мы за это платим:

13 <ul><li>Резкое торможение после предела</li>

14 <li>Отсутствие нового опыта, а значит роста</li>

15 <li>Сложные решения и подходы</li>

16 </ul>И некоторые примеры из жизни программистов:

17 Константы (значение) - это просто, переменные - сложно (значение, время). Данные (значения) - это просто, объекты - сложно (значение, поведение, идентификация).

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

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

20 No Silver Bullet - Essence and Accidents of Software Engineering (Fred Brooks)

21 Фредерик Брукс, создатель IBM/360 и автор книги "Мифический человеко-месяц", в своем эссе "No Silver Bullet" сформулировал два типа сложности, знание которых поможет вам лучше понимать свои системы.

22 <h2>Необходимая сложность</h2>

23 <blockquote>Определяется сложностью решаемой проблемы/предметной области.

24 </blockquote>Если перед вами стоит задача реализовать программу, которая выполняет 20 действий, то вы не можете (с точки зрения программирования, а не бизнеса) реализовать меньше и при этом выполнить задачу. Если у вас есть 5 бизнес-правил, касающихся оформления заказа (например, у вас должно быть достаточно денег на счету), то вам нужно будет их все реализовать.

25 Очень важно уметь выделять главное и видеть, где у вас та самая, необходимая, сложность.

26 <h2>Случайная сложность</h2>

27 <blockquote>Определяется проблемами, которые создают сами программисты. Например, используют неправильные инструменты для данной задачи.

28 </blockquote>Именно этот тип сложности является опасным и ведущим к краху. Неправильные процессы, подходы, библиотеки, языки - всё это, как минимум, вас сильно замедляет, удорожает разработку. И, в конце концов, может стать причиной неудачи проекта.

29 От этой сложности нужно избавляться всеми способами. Главное, что я хотел бы донести до вас в этом уроке: понимание того, где у вас случайная сложность, приходит только с обогащением вас как профессионала. Многие разработчики смотрят на это так: я выучу ещё 10 новых библиотек и пару новых языков и стану круче. Да, вы станете чуть лучше, но это будет совсем чуть-чуть. Потому что эти библиотеки и языки будут использовать подходы, к которым вы привыкли, и вам будет легко, а значит роста почти не будет. Единственный способ расти по-настоящему быстро и качественно - это изучать то, что даётся тяжело: языки с новыми парадигмами, другие области программирования, такие как мобильные приложения, фронтенд вместо бэкенда и наоборот.

30 Автоматное программирование, как раз, относится к одному из таких пунктов. Эта парадигма изменит вас (если вы позволите этому случиться) невероятно сильно и даст возможность лучше определять и искоренять случайную сложность в вашем коде.

31 P.S. Основные языки для роста: haskell, clojure, prolog, erlang, kotlin, c.