Изменение восприятия сложности

в 9:43, , рубрики: Анализ и проектирование систем, мнение, Программирование, разработка по, сложность, Совершенный код, философия

Изменение восприятия сложности - 1
Хочу поделиться очень субъективными мыслями об изменении отношения к сложности за последние лет 50. Возможно, мои наблюдения касаются всей инженерии, но я поостерегусь и буду писать только про разработку ПО.

В последние годы мне стало казаться, что я упускаю что-то в методах разработки ПО. Весь мир радостно и с песней ускоряется, создаёт софт всё быстрее и быстрее, а я торможу. Чтобы не отставать, приходится преодолевать внутренний барьер неясной природы, действовать за границей которого выгодно но неприятно (мне). Не понятно почему выгодно. И не понятно почему неприятно.

Сегодня понял. В былые времена со сложностью боролись, теперь её игнорируют принимают. Переход между этими воззрениями был долгим и плавным, но уже можно видеть разительные отличия.

Я же учился в основном по материалам, созданным в прошлом веке, «древним манускриптам», да ещё и научную фантастику читал классическую, поэтому невольно стал приверженцем «старой школы». В чем же разница?

Когда компьютеры были большими, а софт маленьким, мы только столкнулись со сложностью и испугались её. Не разобравшись начали бороться с источником страха. Отсюда пошло стремление всё формализовать, стандартизировать, классифицировать.

Некоторые оговорки

Описанное далее не относится ко всей отрасли (всегда есть анклавы, обусловленные особыми требованиями), но, думаю, к большинству всё-таки относится.

Также я не ставлю целью статьи всестороннее исследование вопроса, поэтому не буду пытаться приводить большие исчерпывающие примеры. Если у вас есть хороший пример (или контрпример) напишите, пожалуйста, про него в комментариях.

Поначалу мы выигрывали борьбу, поскольку только вступили в новую для нас область и брались за наиболее «простые» задачи. Успех породил ещё больше формализмов и стандартов: последовательные модели разработки ПО (водопад), ООП (в том виде, в котором оно стало популярным), «жёсткие» протоколы и форматы (XML), реляционные базы данных, соответствующие идиомы (RAII), etc.

Со временем задачи усложнялись и противостоять сложности становилось всё труднее. Эта проблема имела два эффекта:

  1. порождала переусложнённых «уродцев» — короткоживущие технологии, пытающиеся отвоевать ещё один островок у сложности;
  2. изменяла восприятия мира самими разработчикам.

В итоге сформировалось новое отношение к сложности. Её просто приняли как одно из свойств нашей вселенной. Вроде гравитации. Огораживаться от гравитации бессмысленно и дорого. Так же и со сложностью.

По мере распространения этого взгляда начали развиваться и соответствующие технологии: гибкие методологии, NoSQL базы данных, языки с динамической типизацией, простые протоколы и форматы (JSON), гибкие идиомы вроде Fail Fast.

Ещё одна оговорка

Важно не путать появление идеи (почти все современные идеи появились очень давно) и её распространение.

Новый взгляд на сложность оказался существенно выгоднее во многих случаях (но не во всех). Вместо траты огромного количества ресурсов на создание полностью изолированной формализмами от внешнего мира системы, мы можем адаптировать наши решения к уже существующему ландшафту, умело используя его неровности к своей выгоде, оперативно исправляя те проблемы, с которыми непосредственно сталкиваемся.

Но чтобы пользоваться этими преимуществами необходимо перестать бояться сложности, что не так-то просто.

Автор: Елецкий Алексей

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js