Шаблонная работа и шаблонное мышление

В этой серии статей об информационных технологиях я уже упоминал шаблоны разработки ПО не единожды. Для читателей, не работающих в отрасли, будет неочевидно, почему эта тема важна, поэтому начну с краткого экскурса в суть дела. Существует множество различных способов писать программный код и организовывать его в проекты и окончательные приложения. Не все даже ветераны отрасли это понимают, но единого критерия правильности или неправильности не существует: одной и той же цели можно добиться разными способами и подходами. Всё же есть очевидно успешные и провальные подходы, которые даже при правильно заработавшем приложении по введении его в эксплуатацию могут облегчить или усложнить последующее развитие или поддержку проекта.

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

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

Чтобы облегчить работникам индустрии информационных технологий задачу создания работоспособных приложений, самоназначенные лидеры индустрии придумали концепцию шаблонов, которым принялись обучать кадры. Широко известны и применяются такие, как например, модель-вид-контроллёр и им подобные. Эти шаблоны имеют статус т.н. официальных, хотя официальных органов в индустрии не существует. Просто для создания налёта легитимности кто-то решил так назвать их, потому что они применяются достаточно широко, чтобы считать их массовыми и устоявшимися. Ладно, они действительно неплохи, им желательно следовать, потому что под них заточены готовые, стандартные и широко известные библиотеки и инструментарий. Но кроме них постоянно, как грибы после дождя, плодятся, размножаются и растут мириады других шаблонов. Я неоднократно упоминал в цикле, что разработчики стремятся выпендриться любой ценой и постоянно придумывают всякий мусор, только чтобы засветиться в профильных соцсетях и подпрыгнуть выше толпы, в надежде, что их заметят и им заплатят. Так рождаются мусорные шаблоны.

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

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

Также важно понимать, что для владельцев и руководства организаций, использующих ПО и разрабатывающих его для себя или для своих потребителей, абсолютно не важно, следуют ли их разработчики какому-либо шаблону. Важно лишь одно: чтобы это ПО правильно обрабатывало данные об основной деятельности и укладывалось в бюджет. Это включает в себя ввод, сохранение, обработку, трансформацию и выдачу данных. Пока это соблюдается, сотрудникам, ответственным за основную деятельность, начхать с высокой колокольни, что там творят разработчики. Проблемы возникают только в двух случаях: когда ПО не справляется с поставленной задачей, или когда это стоит слишком дорого. С чего же эти самые разработчики вдруг так бесятся, спросит читатель. Да вот с чего!

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

Желательно, чтобы шаблон не поддерживался существующими  средствами разработки. Обычно это воплощается в затруднении ознакомления с функционированием его исходного кода для тех, кто не стояли у истоков проекта. Достичь этого можно, разорвав иерархию вызовов функций в одной или нескольких точках и переложив их стыковку на библиотеки, функции которых выполняются неявно. Тогда тем, кто не участвовали в проекте с самого начала, трудно разобраться в том, как он работает. Казалось бы, тут должно помочь знание шаблона, но это только с виду. На самом деле, как всё в индустрии ИТ, достаточно лишь чуть-чуть модифицировать воплощение шаблона в фактический код, и он лишь с виду остаётся самим собой. Ещё было бы идеально, если бы для проекта вообще не было бы средств разработки, или если бы их основные функции не работали бы.

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

Двумя единственно важными требованиями к разработке ПО являются полнота покрытия им потребностей основной деятельности и производительность. Больше ничего не имеет особого значения. Чтобы гарантировать первое, код должен быть организован так, чтобы его можно было покрыть автоматизированными тестами. Для второго требуется опыт и добросовестность разработчиков. А какие там они применяют или не применяют шаблоны, практически не важно. И тем не менее, разработчики пытаются самих себя и окружающих убедить в обратном.

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

Почему-то практически все популярные шаблоны из кожи вон лезут, чтобы уменьшить размер каждой функции до минимума: одной-двух строк кода. По идее, чем функция больше, тем труднее её читать. Если она превышает по высоте один компьютерный экран, то лучше бы её разбить на несколько такого размера. Но зачем до абсурда-то доводить? Мне встречались проекты, в которых разработчики потратили всё время не на необходимый труд, а на разбиение каждой функции на такие однострочники. Термин этот я применил намеренно, по аналогии с современным общением в соцсетях: у обоих ноги растут из одного и того же места. Их функции не делали практически ничего, кроме вызовов других функций.

Спросите, чего в этом плохого? Да то, что, во-первых, при возникновении проблем таскаться по такому коду при помощи отладчика просто пытка, а во-вторых, выполнение такой программы стоит гораздо больших машинных ресурсов в силу того, что процессор должен сначала сформировать, а затем освободить т.н. стек параметров и возвращаемых значений, а это не бесплатно с точки зрения времени и затрат энергии. Об этом я уже многократно писал: у нас что, бездонные карманы, больше 24х часов в сутках и нет других проблем, что мы допускаем расточительность в области ИТ?

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

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

Это безграничное доверие «официальным» шаблонам доходит до абсурда. Работал я на одном проекте, где молодому сотруднику поручили добавить некую функцию. Он обратился ко мне с просьбой ознакомить его с одной моей разработкой и предоставить её код. Сказано, сделано, и он забрал его и добавил его в проект. Проверяя его изменение, я тут же обратил внимание на то, что он применил асинхронное ожидание без фиксированного лимита на время исполнения, и пошёл я с ним поговорить. Разговор протекал в общих чертах так:

- Ты использовал асинхронный метод класса и ожидаешь его окончания. Зачем?

- Потому что мы переводим весь проект на ожидание асинхронных вызовов.

- Но ты же знаешь, что задача этого класса решается на процессоре?

- Что ты имеешь в в виду?

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

Тут сотрудник одарил меня стеклянным, непонимающим взглядом. Этот недавний выпускник одного из самых престижных ВУЗов представления не имеет о том, как работает платформа ПК с ОС Windows. Его убедили, что об этом даже задумываться не нужно, раз всё стало многоплатформенным и облачным. Объясняю дальше:

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

Опять ответом был взгляд стеклянных глаз. Товарищ не в теме, не сечёт, а самое печальное, не желает даже на мгновение задуматься и признать, что в подходе, навязанном ему «старшими» товарищами, может быть изъян. В общем, проще было оставить его в покое, плюнуть и забыть. Ну ожидает он асинхронного окончания обработки массива, и шут с ним. И таких по кабинетам и залам сидит тьма тьмущая. Для них следование догме шаблона главное, а думать при этом необязательно. А потом мы изумляемся, чего это они беснуются на улицах толпами, протестуя против какого-нибудь очередного решения: им так сказали, и они купились, потому что верят в шаблоны, а не в мышление.

Назвать эти правила организации кода шаблонами и провозгласить их верховенство мог только очень недалёкий человек. Этим самым он и ему подобные убедили целые поколения сотрудников ИТ, что бездумно полагаясь на шаблонное мышление и шаблонный подход, они двигают прогресс и следуют ему. Всё как раз наоборот: они не упражняют свой мозг и потихоньку движутся к стагнации и загниванию отрасли, что мы все и наблюдаем последние лет 10-15. Вместо напряжённого поиска наилучших подходов к проблемам и методов их решений, они полностью полагаются на отыскание какого-нибудь популярного шаблона и его применение, в надежде, что он окажется панацеей от всех бед. Хуже всего то, что ведут они себя, как в популярной притче об исследовании поведения обезьян: бросаются без причины бить любого, кто не следует стадному поведению.

Был мне как-то поручен проект, который нужно было сделать срочно и на ограниченном бюджете. Хуже всего было то, что он подразумевал взаимодействие с мягко говоря неквалифицированной смежной организацией, поставлявшей низкокачественные данные. Управился я в срок, но тут на меня насели бонзы подразделения с вопросом, почему я не стал применять популярные шаблоны. Тогда пришлось задать неудобный вопрос:

- А ничего, что мне пришлось клещами вытягивать из партнёра объяснения по поводу структуры их данных и по ходу дела находить изъяны и обучать их, как это делается правильно, в результате чего  они не раз передумали и начали менять эту структуру и смысловое наполнение?

- И что? — спросил меня очередной выпускник престижного ВУЗа, глядя стеклянными глазами.

- Да то, что, начиная проект, я не был уверен в том, как он должен будет в итоге работать, и пришлось проектировать его так, чтобы можно было многое менять по ходу.

- Всё равно, нужно было применить шаблоны, которые применяет вся организация.

- Я мог бы, но тогда бы никогда не уложился в сроки.

Поворчав, от меня отстали, потому что крыть было нечем. Больших семь шапок из овцы не выкроишь никак.

Или был случай, когда сотрудник внезапно разбил таблицу с несколькими полями в ней на несколько таблиц с одним полем в каждой. Что это было, господа, спрашиваю я. А он применяет такой-то шаблон, отвечают мне. То, что этот шаблон индивидуум только что выдумал сам, никого не беспокоит. Ему это сошло с рук, несмотря на то, что создало массу неудобств для остальных сотрудников. Шаблон — царь и бог. Следует ли уточнять, что как только проект приняли в эксплуатацию, товарищ, считавшийся в нём одним из ведущих спецов был тю-тю?

Чем так дороги разработчикам эти проклятые шаблоны? Да тем, что, демонстрируя опыт их применения, они также демонстрируют свой конформизм и зависимость. Без этого на работу не возьмут. Никому не нужны независимо мыслящие сотрудники, абы чего не вышло. В одиночку следовать шаблонам невозможно, потому что тогда их никто не поймёт, поэтому они так агрессивно заставляют и окружающих им следовать. На секундочку, это обычно те же самые личности, вопящие о важности разнообразия и инклюзивности, которые почему-то в их сознании ассоциируются лишь с цветом краски для волос и кольцами в носу. А как же инклюзивность и разнообразие в мышлении? Нет, это не позволено.

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