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

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

Руководство вдохновилось результатами презентации, поскольку было наглядно показаны преимущества подхода на этапе внедрения новых функций в проект:
  1) минимальный порог вхождения для новых разработчиков;
  2) отличная интеграция со Scrum и Agile-методологиями;
  3) устойчивость проекта по отношению к внешнему рефакторингу;
  4) простая интеграция новых языков программирования и современных технологий в проект;
  5) пониженная стоимость разработки элемента проекта;
  6) высочайшая скорость создания презентаций, патчей и дополнений работающего проекта.

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

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

И ведь в самом деле, наши менеджеры имеют ряд начинающихся проектов. Зачем тратить силы на ненужные на данном этапе архитектурные элементы и тем более, классы или модули? Предлагаемый докладчиком подход показывал, что при необходимости в будущем в спагетти-проект легко внедряется любая архитектура. Если разработчик-архитектор не может этого сделать, он просто не соответствует своему званию. Спагетти сохраняет гибкость, причём, намного большую, чем Agile, что докладчик продемонстрировал, за 2 минуты внедрив в новый для него проект команды alert(); и shutdown. Уже не нужно тратить неделю на итерацию, чтобы изменить проект — в некоторых случаях достаточно пары часов.

Рассмотрим подробнее основы спагетти-методологии

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

Идея спагетти лежит в истоках машинного кода и фундаментального принципа передачи управления нитью исполнения программы. Мы знаем, что есть другие подходы в отличие от Фон-Неймановской архитектуры, но ни один не доминирует на рынке компьютеров, не говоря уж о программных системах.

Что нового дали полвека отхода от спагетти?

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

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

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

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

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

1. добавить функции-миксины (ещё лучше — методы), вызываемые из блока, в который данный участок кода поместили. Имеет смысл, если остальные вызовы идут преимущественно из других блоков;
2. переименовывать похожие функции, методы и делать достаточно различий в аргументах и содержании, чтобы задача обратного восстановления представлялась нецелесообразной. Начинающие разработчики часто вместо этого подхода используют более примитивную технологию «копипейст», который проще подвергается рефакторингу, лишая авторов проекта стратегического преимущества;
3. использовать аналоги существующих в проекте методов, что более трудоёмко, но гарантирует лучшую связанность проекта.

Спагетти-методология — это не изобретение в программировании, как принято думать

Подобный подход давно и успешно применяется в авиации:

(видна интеграция с модульным подходом),

в градостроительстве и логистике:

в сельском хозяйстве:

В системном администрировании:

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

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

1. Высокий уровень иерархической организованности для принятия решений.
2. Гибкость в постановке и модификации целей.
3. Экстремальные условия финансирования.
4. Подходящий уровень персонала, вызванный низкой текучестью кадров.
5. Долгосрочное планирование в сочетании с п.2

Не отстаёт от государства и частный бизнес. Вспомним, что первые ЭВМ и системы были построены как раз на этом подходе, и лишь развитие технологий и компьютерных наук нашёл новые формы занятости программистов и менеджеров. Сейчас же предлагается вернуться к истокам и почерпнуть всё лучшее, что наработало человечество с 50-х годов 20-го века.

Методы работы со спагетти-кодом

Докладчик показал некоторые методы решений сложных проблем, возникающих как следствие гибкости методологии.

Например, хорошие результаты даёт графовое представление взаимосвязей, где проще проследить нити управления специалисту и часто эффективнее для презентаций, чем XML и JSON-файлы, даже если они тоже представлены структурами.

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

И насколько проще становится разобраться в изначально сложной схеме:

Она позволяет увидеть взаимосвязи в даже слабо связанных явлениях, как на примере.
Если требуется классификация узлов — аналогично:

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

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

Существующие IDE для любого языка программирования, как и мультиязычные, ориентированы на использование спагетти-кода. По той простой причине, что иначе они не могли бы работать с наиболее сложными случаями кодирования, и также помогают разработчику искать вхождения имён в проекте, участков кода, подсвечивать ключевые слова и перенаправлять фокус просмотра от использования к определениям функций, методов и классов. На самом деле, все десятки приёмов в IDE — это работа с просто спагетти кодом, и только некоторые из них — работа с другими методологиями (ООП, TDD, репозитории, скрам, ….).

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

Далее лекция немного уклонилась от основной темы, заказчик показал менеджерам mind maps:
,
а затем увлёк их в закрытую комнату, где они 2 часа занимались рисованием и вышли оттуда очень довольные результатами, прямо один в один, как по кальке с прошлого года, когда они ушли пробовать planning poker, а затем внедрили Scrum. Похоже, и в этот раз вопрос о внедрении макаронной методологии в нашей организации — вопрос решённый.

Перечислим плюсы и минусы спагетти-подхода в проектировании.

• + написание любой функции в любой точке проекта;
• — адаптирование нового кода — с пересмотром всех использований его по всему проекту (впрочем, как и в любом проекте, но если код организован, его легче читать).
• + низкий порог вхождения, чтобы начать писать спагетти-код;
• — высокий порог понимания чужого спагетти-кода (но есть масса техник в IDE);
• + невероятная гибкость и «пантеичность» спагетти-подхода;
• — сложность в построении больших систем на основе этой методологии.

Выводы *)

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

* Мнение лектора не всегда совпадает с точкой зрения редактора.

Автор: spmbt

Источник