Ожидание и реальность: что приходит вместе с упрощением

Когда мы хотим приложить усилия, чтобы упростить какое-то запутанное дело, в итоге иногда оказывается, что этим только усилили энтропию (что есть мера хаотичности). Часто ли у вас было, что после генеральной уборки в доме вы еще неделю подряд пытаетесь разыскать то одну вещь, то другую, а потом, когда эти вещи вновь составят "беспорядок" - часто используемые оказываются под рукой, редко используемые - в тёмном углу, и вы опять диагностируете беспорядок?

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

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

Пару лет назад мне было поручено подключить сервисы доставки, один из них (не помню, то ли СДЭК, то ли Боксберри) уже имел готовое открытое расширение под нашу CMS и на техническом совещании мы решили, что проще всего взять это решение. Рассматривался ли аспект, что работник нашей организации обладает большей экспертизой для подключения? Нет. Рассматривалось ли то, что сделано было хорошо, а не для галочки "Мы поддерживаем CMS такую-то"? Тоже нет. В конце концов отслеживали ли они новые версии нашей программы и вносили соответствующие изменения? Абсолютно нет. После того совещания чувствовался какой-то подвох, но точно сформулировать его не смог.

Первым делом я установил это расширение и стал его изучать. Чем дальше продвигалось дело, тем больше мне не хотелось совмещать такой сумбурный код с нашим более-менее причёсанным и стандартизированным. По сообщениям в заголовках файлов, где указывалось, кто и когда вносил изменения, стало понятно, что они кочевали из рук в руки и мало кто из программистов понимал, что должно получится в итоге. При этом оно закрывало только часть требований, а зная дотошность нашего продакт-менеджера с просьбами "сюда надо добавить, а это убрать", такое "упрощение" показалось мне сомнительным в перспективе, о чём и доложил начальству на следующий день. Оно оказалось понимающим и мне выделили время подключить сервис по их хорошо задокументированному API (на создание которого разработчики этой службы доставки потратили больше человекочасов). Как ни странно, это и оказалось более простым.

Еще пример из практики. В одной из компаний, в которых имел честь работать, нерушимо следовали правилу, что если можно найти на github подходящую библиотеку для задачи, то нужно подключать её. Это требование, конечно же, исходило из стремления к простоте, зачем программисту писать код, если его можно найти в открытом доступе? Такие вещи очень хорошо выглядят в общих формулировках, но на практике важны детали. При этом задача не казалась мне особо сложной и, по моим подсчетам, можно было бы сделать её за полдня с нуля плюс пол рабочего дня на отладку. А вот подгонка и выбор из незнакомого найденного кода мне казались делами не так просто измеримыми. Современная тенденция из любой более-менее известной библиотеки делать фреймворк подразумевала, что или мне нужно будет в добрых традициях open source изучать код и отправлять туда изменения, ожидая, когда модератор их одобрит (этого могло и не произойти) или клонировать в наш репозиторий и дорабатывать там. Обе последние перспективы опять оказались трудозатратными. Поэтому в итоге написал библиотеку самостоятельно, выложил в своем аккаунте github и отрапортовал, что вот, скачал, как положено, из указанного сервиса. Примечательно, что после этого библиотека стала самой посещаемой у меня в репозитории и мне прислали предложение к доработке, то есть она была полезной (несмотря на то, что уместил всё в один небольшой класс).

Эти два примера похожи, но это не всё. Есть множество других, самый распространённый привёл в начале, это когда пытаются упростить, при этом добавляя. Если бы IT-шники спроектировали космическую ракету для полёта на Луну, как они обычно делают веб-приложения, то там определённо находились бы места для них самих, чтобы дорабатывать на лету и похожа она в конце полёта была бы на орбитальный "Город тысячи планет" из фильма.

Есть еще одна разновидность так называемого "упрощения" - хроническая. Это когда в команде/проекте работают солидные, знающие люди и, примерно раз в месяц-два собираются и изменяют все рабочие процессы и правила игры в сторону, несомненно, улучшений и простоты. Каждое "последнее" такое изменение, конечно же, необходимо и продумано до мелочей. Кроме одного нюанса - работать при такой чехарде практически невозможно.

Можно подумать, что все программисты стремятся к упрощению, чтобы облегчить себе и другим жизнь, но это не так. Это работники интеллектуального труда и часто понятие качество для них бывает синонимом слова "сложность". Так ли это? Авторы популярных книг о программировании, в том числе уважаемой книги "Совершенный код”, советуют писать код так, чтобы он был понятен коллегам и поправлять код, если он вызвал разночтения. И делать это не с помощью комментариев в коде. Но если вы спросите вышеупомянутого программиста, что делает его скрипт, то он ответит, если вспомнит, но поправлять не будет, напишет комментарий или сделает его ещё более непонятным.

В глобальном плане в мире программирования всё катится к постоянному усложнению, и те, кто пытается упростить жизнь другим участникам, при этом усиливают общую энтропию. Это неконтролируемый процесс, хоть он и идёт под лозунгом упрощения. Ведь нововведения в языки программирования вносятся с той целью, чтобы было проще решать сложные задачи. Или экономить мощности серверов. Или сделать как где-то ещё сделано. Последнее также можно сказать про open source фреймворки. Это ведь признак маркетинговой конкурентной борьбы. И призыв "выбери фреймворк под свои задачи" уже не так актуален, ведь их кураторы стремятся сделать их однообразными и не упростить разработку продолжая свои идеи, а более исхитриться, чтобы захватить внимание аудитории.

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