spaghetti code что это
О достоинствах спагетти-методологии
Недавно к нам в компанию пришёл специалист из дружественной сервисной компании с презентацией классического спагетти-подхода к программированию. Ниже приведён пересказ его лекции. Презентация вызвала живой интерес и обсуждение (среди менеджеров).
В ходе лекции мы узнали, что существует методология проектирования, которая работает в большинстве простых и среднесложных проектов, и только для крупных и растущих рекомендуется её сменить, начав переписывать функции заново на некотором этапе.
Руководство вдохновилось результатами презентации, поскольку было наглядно показаны преимущества подхода на этапе внедрения новых функций в проект:
1) минимальный порог вхождения для новых разработчиков;
2) отличная интеграция со Scrum и Agile-методологиями;
3) устойчивость проекта по отношению к внешнему рефакторингу;
4) простая интеграция новых языков программирования и современных технологий в проект;
5) пониженная стоимость разработки элемента проекта;
6) высочайшая скорость создания презентаций, патчей и дополнений работающего проекта.
До сих пор наша команда старалась придерживаться более традиционных структурированного, ООП и MVC-подходов. Но под влиянием рынка приходится опробовать и новые методы. Ведь время на разработку и рефакторинг архитектуры нам и раньше практически не выделялось, а то, что удавалось сделать, было неоднократно критикуемо менеджерами за сложность и повышение порога вхождения новичков, а также за то, что наши фреймворки легко ломались самими менеджерами, когда они брались деплоить проект, но забывали о правилах методологии, которая нами не была описана, потому что (см. выше) время на неё не выделялось.
Тогда же, во время той презентации, появилась возможность устранить ряд досадных недостатков. Конечно, придётся уволить нескольких ключевых разработчиков, которые не будут согласны с новым подходом, но ведь станет возможно писать простой код, без классов и лямбда-функций, понятный основной массе разработчиков с опытом работы от 1 года и недавно пришедших в компанию.
И ведь в самом деле, наши менеджеры имеют ряд начинающихся проектов. Зачем тратить силы на ненужные на данном этапе архитектурные элементы и тем более, классы или модули? Предлагаемый докладчиком подход показывал, что при необходимости в будущем в спагетти-проект легко внедряется любая архитектура. Если разработчик-архитектор не может этого сделать, он просто не соответствует своему званию. Спагетти сохраняет гибкость, причём, намного большую, чем Agile, что докладчик продемонстрировал, за 2 минуты внедрив в новый для него проект команды alert(); и shutdown. Уже не нужно тратить неделю на итерацию, чтобы изменить проект — в некоторых случаях достаточно пары часов.
Рассмотрим подробнее основы спагетти-методологии
В то время как другие высокоуровневые подходы стараются навязать проекту определённую структуру, спагетти изначально свободна от этого недостатка. Она не противоречит ни одной новой структуре проекта, не запрещает изменять структуру во время развития проекта и содержать группу несвязанных и даже противоречащих друг другу техник. Последнее проявляется уже на сложных проектах, но опыт многочисленных компаний показывает, что и в этих случаях спагетти-подход, благодаря своей уникальной гибкости, одерживает верх над рядом других, более жёстких методологий.
Идея спагетти лежит в истоках машинного кода и фундаментального принципа передачи управления нитью исполнения программы. Мы знаем, что есть другие подходы в отличие от Фон-Неймановской архитектуры, но ни один не доминирует на рынке компьютеров, не говоря уж о программных системах.
Что нового дали полвека отхода от спагетти?
Нужно признать, что многие эксперименты старались от неё избавиться. Например, структурированный подход к программированию выделяет тот факт, что управление программой чаще всего нужно не только передавать, но и брать обратно. От GoTo избавились, как от деструктирующего оператора, но почему же в последние годы мы снова слышим, что jQuery тоже создаёт спагетти-код? В таком языке, в котором все операции структурированы? Оказалось, что спагетти можно писать и структурно.
Почему начинающий программист почти всегда опробует спагетти-подход, лишь наслоение методологий смещает его взгляды? Почему существуют костыльные программисты, которые легко переваривают такой код, написанный ими самими, могут поправить любую систему без исходников, отыскать источник почти любого бага?
Интересен вариант, смешанный со структурированным программированием: новую функцию, класс или блок можно писать в любом участке проекта, применяя вложенные вызовы и структуры данных, но проект, несмотря на структурные вызовы, будет иметь формат спагетти. Природа спагетти лежит глубоко в природе вещей и деятельности человека. Поэтому подходу и его особенностям необходимо уделять должное внимание, особенно, на этапах становления и развития проекта.
Не обязательно делать сложно, что изначально делается просто — это знает любой продвинутый стартапер, тот же костыльный программист и бизнесмен, умеющий считать деньги и видящий реальное положение вещей при реализации проектов. Не следует сразу привлекать специалистов по созданию сложных систем, если система у вас простая. Это подтверждают многочисленные факты как работы спагетти-систем, так и миграции от них в более сложные, когда в будущем они понадобятся.
Существуют специальные техники связывания кода, чтобы проект из структурного превратился в безоговорочный спагетти-проект, чтобы усложнить распутывание структурных петель. Ведь если мы оставим структурные вызовы без связывания, последователи при рефакторинге смогут легко исказить замысел архитектуры и распутать клубок спагетти. Это недопустимо на некоторых проектах, поэтому созданы и развиваются техники связывания:
Спагетти-методология — это не изобретение в программировании, как принято думать
Подобный подход давно и успешно применяется в авиации:
(видна интеграция с модульным подходом),
в градостроительстве и логистике:
в сельском хозяйстве:
В системном администрировании:
То есть, в достаточно ответственных и важных областях деятельности. Поэтому не всегда обоснована критика сложных спагетти-программных систем, сочетающих в себе как устойчивость к изменениям, так и восприимчивость к кадрам различной квалификации.
Методы работы со спагетти-кодом
Докладчик показал некоторые методы решений сложных проблем, возникающих как следствие гибкости методологии.
Например, хорошие результаты даёт графовое представление взаимосвязей, где проще проследить нити управления специалисту и часто эффективнее для презентаций, чем XML и JSON-файлы, даже если они тоже представлены структурами.
При большом количестве связей помогают цветовые маркеры нитей. Посмотрите, насколько проста и понятна идея, заложенная в их основе: 
И насколько проще становится разобраться в изначально сложной схеме: 
Она позволяет увидеть взаимосвязи в даже слабо связанных явлениях, как на примере.
Если требуется классификация узлов — аналогично: 
Обычно на этом этапе, сказал докладчик, менеджеры и основная масса разработчиков уже приветствует подход, и лишь малая часть задумывается о своём опыте и старается не смотреть на диаграммы.
Встречались доводы, что подобные схемы обычно не используются в программных средах, а больше относятся к данным и к презентациям. Но несомненно, что если методология позволяет представить всё, то в остальном — дело только за разработчиком и его способностями, чтобы суметь ею воспользоваться.
Поэтому опытным разработчикам легко работать со спагетти-кодом, именно потому, что они знают много техник работы, много приёмов в различных IDE и имеют собственные наработки типа макросов в редакторах или даже в системах поддержки и сборки кода. Поэтому вопрос простоты и сложности представления исходного кода в той или иной методологии — вопрос совсем неочевидный. Если ваши разработчики, говорит лектор, избегают работы с неструктурированным кодом, это может говорить об их недостаточной квалификации, чтобы освоить спагетти-методологию.
Далее лекция немного уклонилась от основной темы, заказчик показал менеджерам mind maps: ,
а затем увлёк их в закрытую комнату, где они 2 часа занимались рисованием и вышли оттуда очень довольные результатами, прямо один в один, как по кальке с прошлого года, когда они ушли пробовать planning poker, а затем внедрили Scrum. Похоже, и в этот раз вопрос о внедрении макаронной методологии в нашей организации — вопрос решённый.
Если ваша организация ещё не обросла массой наследуемого кода или вы постоянно начинаете новые проекты, у вас нет лишних денег на следование мировым тенденциям огромных компаний, идеологи спагетти-программирования всегда будут готовы вам помочь оптимизировать процесс, чтобы написать функцию не за 2 дня, а за 10 минут, отладить расширение не за неделю, а за несколько часов. Гибкие, как спагетти, аджайл-программисты ищут возможности, традиционные программисты ищут фундамент. Гибкие программисты пишут код, традиционные — его переписывают. Гибкие — слушают менеджера и тут же исполняют его слова, традиционные — ищут причины заняться платформой.
* Мнение лектора не всегда совпадает с точкой зрения редактора.
Что такое «спагетти код»?
Код «Спагетти» (от английского словосочетания spaghetti code) — простыми словами, это уничижительное жаргонное описание некачественного программного продукта, который в силу различных факторов приходит ко всё менее оптимизированному виду. Иногда неправильно называют «лапша код» (относится к штрих-коду).
В качестве примера «спагетти» кода можно привести ситуацию, когда несколько разработчиков добавляют или изменяют код в течение многих лет, пытаясь оптимизировать существующую инфраструктуру программирования. В результате возникает запутанная структура кодирования с многочисленными операторами — проект со временем становится всё сложнее (и дороже) поддерживать.
Почему спагетти код — это ругательство?
Предприниматель может обвинить разработчика в создании кода спагетти и выставить неустойку. Организация в этой ситуации здорово рискует. После долгих лет работы и инвестиций в проект, ИТ-менеджеров и другие ресурсы, поддержка становится всё более дорогостоящей. В конце концов, спагетти код сделает её нерентабельной.
Как избежать спагетти кода?
Попытки привлечь других программистов приводят к значительным потерям по времени и не гарантируют результат. Новым исполнителям приходится исследовать и перекодировать инфраструктуру проекта только для того, чтобы что-то перестало «ломаться». Затем им приходится изучать годы выполненной работы, часто управляемой разными разработчиками, чтобы определить источник проблемы, если её вообще возможно решить.
По этой причине спагетти-код считается серьёзной неприятностью для разработчиков и ИТ-менеджеров. Корпоративным предприятиям, которым приходится управлять своими ресурсами, такой ситуации следует избегать как огня. Сделать это можно следующими способами.
Усердие и внимание к деталям
По нашей в ZEL-Услугах оценке, многие компании в погоне за результатами не уделяет внимание архитектуре разработки. Фундаментальный подход к деталям зачастую на корню пресекает все возможные путаницы с кодом в будущем даже при смене разработчика — все работают с унифицированным и интуитивным строением кода.
Тестирование модулями
Регулярные тесты должны выполняться модульно. Комплексный подход хорош на прохождении определённых этапов развития проекта. Однако внимание деталям уделяется больше всего на промежуточных модульных тестированиях.
Проверяйте программистов
Дополнительная пара глаз не помешает. Если вы столкнетесь с признаками кода спагетти, обратитесь к другому программисту или другой команде разработчиков (например, на аутсорсинге), чтобы убедиться в опасениях и внести изменения пока ещё не поздно.
Фреймворки полегче
В 2021-м году чем легче и проще фреймворки, тем лучше. Оптимизация структуры по этому принципу настраивает всю компанию на работу с простыми решениями впредь. Отличный пример профилактики кода спагетти.
Принцип «слоёного теста»
В крупных проектах «Spaghetti Code» — неизбежность. Реализуйте в таком случае архитектуру «слоёной» разработки. Так легче локально корректировать запутанный код и сохранять функциональность других слоёв.
В англоязычном сообществе софт ещё обзывают:
PS: приятного аппетита, наши дорогие айтишники и предприниматели!
Обратитесь в компанию ИТ-аутсорсинга для дальнейшей экспертной поддержки и консультации по этой теме и любым другим техническим вопросам.
Убираем спагетти-код
Два подхода к упорядочиванию хаоса.
Когда мы делали свой Трелло-планировщик из Бутстрапа и нашего списка задач, у нас появился спагетти-код. Это значит, что для простоты и скорости решения мы скопировали одинаковые куски кода, которые делают почти одно и то же. У них внутри одинаковая логика, но разные входные данные, и мы их просто скопировали-вставили.
У такого подхода к программированию есть несколько проблем:
Единственное, когда можно использовать такой подход — если нужно что-то быстро протестировать и понять, работает оно или нет. Если не работает — значит, мы сэкономили время и не стали тратить его на неудачное решение. А если всё работает как нужно, значит, настало время переписать код в нормальном виде. Для этого нам понадобится некоторое подобие объекта, но не на основе класса, а созданное вручную.
Мы хотели ООП, но не смогли
Изначально мы хотели на этом примере показать силу классов и объектов в объектно-ориентированном программировании. Но, разобравшись, поняли, что классы только всё усложнят, не принеся нам существенной пользы.
Поэтому мы будем использовать объекты, но без классов. А силу классов мы показали в игре на Питоне — посмотрите, вам понравится.
Новый тип переменной: объект
У переменной типа «объект» есть одна отличительная особенность: она состоит как бы из двух частей — свойства и значения. Мы про это говорили в статье про объекты в ООП, и здесь всё то же самое — у объекта меняются только значения свойств. Поясним на примере языка JavaScript.
Сделаем переменную-объект, у которой будет два свойства — имя и возраст:
Чтобы поменять имя, нужно написать название переменной и через точку указать название свойства, которое хотим изменить:
Свойств у объекта может быть сколько угодно:
Но если у объекта получается много однотипных свойств, можно сделать их массивом и обращаться к ним по номерам. А если элементы массива тоже сделать объектами с одинаковыми названиями свойств, получится вот такая магия:
Смотрите, так как у каждого элемента массива одинаковое название свойств, то, меняя просто номер элемента, мы можем запоминать разные свойства у одинаковых по сути элементов. Это нам пригодится на следующем шаге.
Собираем дубли
Пройдёмся по нашему старому коду из прошлой статьи и соберём все одинаковые переменные, которые отличаются только цифрами:
Первые две переменные задают ссылку на объект и маску для сравнения элементов, а вторые две отвечают за количество задач в колонках.
Свернём эти 16 переменных в один большой объект:
Теперь, зная только номер колонки, мы можем обратиться к объекту, маске и количеству задач в колонке. Сначала это может показаться громоздким, но на самом деле сокращает наш финальный объём программы в 4 раза.
Чтобы избавиться от дублей в коде, используют циклы или выносят повторяющийся код в отдельную функцию. На самом деле вариантов больше, но основные — эти.
Используем цикл
Циклы применяют в тех случаях, когда спагетти-код по очереди используется несколько раз, где отличаются только порядковые номера элементов. В нашем случае это функция showTasks(). Она берёт по очереди все элементы из локального хранилища и по очереди же сравнивает их с шаблоном — для первой, второй, третьей или чётвёртой колонки. Единственное, чем отличаются фрагменты — маской и колонкой, куда их отправлять:
Сделаем то же самое в цикле, используя нашу большую переменную-объект. Для этого мы организуем цикл от 0 до 3 (потому что нумерация элементов массива начинается с нуля) и по очереди проверяем все значения:
Код сократился в 4 раза, читать стало проще, и всё меняется в одном месте. Красота.
Делаем отдельную функцию
У нас есть вот такой огромный кусок кода, который делает одно и то же, только с разными элементами.
Здесь 4 раза задаётся обработчик нажатия клавиш в поле ввода у каждой колонки. Очевидно, что проще вынести повторяющийся код в отдельную функцию и вызывать её по мере необходимости:
Что дальше
Мы только что убрали почти весь спагетти-код из нашего проекта. Почти — потому что у нас осталось два неопрятных фрагмента:
Оба фрагмента можно оптимизировать, например, с помощью jQuery.
Попробуйте сделать это сами, пока это не сделали мы 🙂
ТОП-10 признаков плохого кода: хардкод и спагетти-код в примерах на JavaScript
Многие программисты не знают, что пишут плохой код.
Скорее всего, конкретно вы уже заходили на GitHub, сохранить свой код, посмотреть на чужой. А теперь посмотрите на собственные старые проекты, написанные годом ранее — вы удивитесь, насколько лучше стали ваши навыки с того момента.
Большинство младших программистов (и даже некоторые более опытные) не знают, как отличить хороший код от плохого. Когда программа заработает — они сразу идут дальше. К тому же, если они работают в одиночку, то никогда даже не узнают, что пишут плохой код.
Хорошо, что дост у пны возможности сознательно стать лучше, приложив немного усилий. Но сначала нужно правильно оценить и понять уровень качества собственного кода.
В руководстве пойдет речь о некоторых признаках, выдающих плохие практики в разработке программного обеспечения. Давайте же разберемся!
1. Повсюду скопированный код
Подобное случается с каждым программистом, стоит только перестать стараться писать чистый код.
Предположим, внутри класса или функции вы написали десять строк кода. Все в порядке. Теперь, в другом классе или функции того же проекта, вам нужно заново выполнить похожую задачу. Какова мгновенная реакция? Вместо написания отдельной функции для выполнения схожей задачи, вы скопируете десять строк кода и вставите их в новое место, словно заплатку.
Конечно, ведь всегда проще скопировать-вставить, чем написать функцию. Но вопрос состоит в том, когда подобный метод применим, а когда — только навредит кодовой базе?
Каждый раз, когда блок кода пригодился вам дважды — пишите с ним функцию. Подобный подход характеризуется рядом существенных преимуществ:
2. Одинаковые функции, но разный интерфейс
Постоянство — качество хорошего программиста: старайтесь следовать шаблону, ведь вам придется написать еще очень много функций.
Например, если в одном и том же проекте хранятся две одинаковые функции с разным поведением, то следующим программистам будет очень трудно читать ваш код. Предположим, что вы написали функции проверки некоторых данных профиля. Первая функция проверяет дату рождения пользователя, а вторая — его фотографию.
Приведенный пример достаточно прост, но то же самое относится ко всем функциям и методам вашего проекта. Если вы пишите непоследовательный код, то знайте, что это не профессионально. Пожалуйста, убедитесь, что коллегам-разработчикам легко прочесть ваш код!
3. Хардкод
Все ненавидят жесткий кодинг, “хардкод”. Хорошо, что его появление легко заметить и предотвратить. Проанализируйте следующий фрагмент кода:
Действительная необходимость в жестком кодинге случается крайне редко, так как все изменчиво, каждый аспект программы при желании можно изменить. В любой момент просто инициализируйте новую переменную, присвойте ей значение. Например:
Динамические приложения всегда лучше статических. Когда нужно менять какую-либо часть статического решения, то приходится каждый раз обновлять приложение.
Большинство проектов подключаются к облачным сервисам. Если ваши проекты синхронизированы с какими-либо из них, то лучше сразу получать данные из облака согласно его стандарту.
Некоторые программисты оставляют в кодовой базе хардкод на этапе тестирования, а потом ленятся исправить его на этапе производства из-за сроков и некоторых других причин. Но, пожалуйста, не поступайте так! В дальнейшем каждый экземпляр хардкода в проекте добавит вам еще больше давления и задач.
4. Слишком длинные и сложные условия
Определение достаточно абстрактное, так что же имеется в виду?
Во-первых, не стоит писать “ спагетти-код” — слишком конкретные и длинные условия со множеством проверок и категорий.
Тем не менее, второй совет — противоположность первого:
НЕ пишите сложные условия ради экономии в пару строк. Если вам придется написать две лишние строки, но код станет понятнее, то пишите эти строки с уверенностью. Проанализируйте следующие два примера:
Вложенные условия легко читаются (не всегда, но чаще всего). Применяемый с умом, такой подход поможет избежать неожиданного поведения функций и, следовательно, множества ошибок.
5. Велосипед вместо встроенной функции
Непонятно, почему до сих пор далеко не каждый разработчик на земле применяет встроенные инструменты и функции.
Если вам действительно нужно тратить свое время лишь на то, чтобы работодатель нанял побольше сотрудников для переработки вашего кода, то займитесь чем-нибудь другим. Пожалуйста, не наказывайте проект и разработчиков, в дальнейшем читающих ваш код.
В 99 из 100 случаев ваши функции с течением времени станут менее эффективными в плане времени выполнения и требуемой памяти. Не смотря на это, многие программисты даже не знают, что есть хорошая встроенная функция, но уже пишут свои.
Вот почему большинство старших программистов советуют начинающим и младшим специалистам поискать в Интернете лишние пять минут, прежде чем написать собственную функцию.
Самое приятное, что даже если вы не найдете встроенных функций, то узнаете, как решили задачу другие разработчики. Всегда помните, что написание кода — лишь одна часть работы программиста, нельзя забывать про важность чтения публично доступных наработок.
6. Игра в загадочные имена
Об опыте программиста можно судить по тому, как он называет функции и классы в своих проектах.
Вы догадались, что делает метод? Никто не догадался. Следовательно, следующий программист, прочитавший код, наверняка проклянет вас. Потому что ему, вероятно, придется вчитываться в каждую строчку функции, долго и постепенно понимая, что она делает.
Один из преподавателей курса снизил оценку за неправильное написание названия функции в лабораторной работе по Java.
Он поступил так, чтобы студенты в будущем запомнили важность именования.
7. Сплошь глобальные переменные
Локальная переменная существует не просто так, верно? Пожалуйста, избегайте глобальных переменных всякий раз, когда задача решается через локальные переменные.
Почему? Много причин для превалирования локальных переменных над глобальными. Поговорим о некоторых основных:
Если везде только глобальные переменные, значит, вы плохой программист. Извините за обидное, но правдивое высказывание.
8. Запутанный код
Иногда программистам нравится писать код сложным способом. Поверьте, подобное не сделает вас лучшим программистом на свете, несмотря на то, что многие старшие разработчики занимаются каким-либо хобби в области компьютерных наук, где они нестандартным образом все усложняют.
Однажды программист ответил, что запутанный код делает компанию зависимой от него — работа ему обеспечена.
Но это очень неправильная концепция, крайне вредная идея. Гораздо лучше руководствоваться следующим:
“Загадочность” — плохо. “Легкость” — хорошо.
Пожалуйста, не заставляйте коллег и сослуживцев страдать из-за вашего хобби или попыток выделиться за счет сложности понимания вашего кода другими людьми. Вы сэкономите другим разработчикам часы, если просто напишите элементарный, читабельный код.
Кроме того, игнорирование комментариев или отсутствие документации затрудняет понимание вашего кода сильнее, чем что-либо еще. Переусложненный код, как и последствия интеллектуального хобби, куда легче понять, если они детально задокументированы.
9. Взаимозависимые функции
Код весьма плох, когда функции выполняются исключительно в строгом порядке. Рассмотрим пример:
Функции работают независимо друг от друга.
Решением “на каждый раз” послужит специальный метод-шаблон. Рассмотрим пример на языке программирования JavaScript:
10. Нет понимания сложности алгоритма
Начинающие программисты часто пишут лишние вложенные циклы. Тем более, когда менталитет “ достаточно выполнить работу и запустить код” превращает программиста в неэффективного лентяя. Правда, производительность приложения — скорее дело привычки:
Когда команда не ценит хороший код и не заботится о качестве, то программисты не заботятся о временной сложности алгоритма и сложности алгоритма по памяти
Если вы разбираетесь в оценке сложности алгоритмов и пишете эффективный код — он даст вам силы, а если не обращаете внимание на детали реализации, то не сможете изменить шаблоны, остановившись в развитии профессиональных навыков.
Многие программисты даже не знают про “ сложность алгоритма по памяти” или “memory complexity”. Если вы не знаете, пожалуйста, узнайте, ведь это поможет на собеседованиях.
Выводы
Потребуется время, чтобы стать хорошим программистом, но чем дольше вы следите за качеством собственных проектов, тем чище и лучше становится ваш код. Не говорите себе, что со временем все само по себе изучится, но и ученым-ракетостроителем быть не требуется, чтобы написать хороший код.