О достоинствах спагетти-методологии

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

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

    Руководство вдохновилось результатами презентации, поскольку было наглядно показаны преимущества подхода на этапе внедрения новых функций в проект:
      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 минут, отладить расширение не за неделю, а за несколько часов. Гибкие, как спагетти, аджайл-программисты ищут возможности, традиционные программисты ищут фундамент. Гибкие программисты пишут код, традиционные — его переписывают. Гибкие — слушают менеджера и тут же исполняют его слова, традиционные — ищут причины заняться платформой.

    * Мнение лектора не всегда совпадает с точкой зрения редактора.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 63

      +31
      На фоне тотального алкоголизма этих дней это больше похоже на юмор. Но, прошу заметить, действительно, часть проектов быстрее, легче сдавать спагетти. Иногда весь, иногда какую-то стадию.
        +10
        +1, сам ожидал увидеть тэг «юмор»
          +20
          Подождите, так это всё таки не шутка? о_О
            +5
            Впору ставить теги <not-irony/> или <not-sarcasm/>
        +11
        «Гибкий, как спагетти, программист» — надо будет запомнить…
          +57
          Честно говоря, я запутался. Не могу понять: или это стеб, или я ничего не смыслю в программировании.
            +4
            В каждой шутке, как известно… ;)
              +12
              Доля шутки, а все остальное — правда. Но в статье от 1 января может присутствовать доля салата оливье, алкогольных паров, приступов жажды и головные боли.
              +1
              Главное в любой другой день сомнений не возникло бы, но вот 1-го января начинаешь сомневаться и в своей адекватности и в авторе :)
              • UFO just landed and posted this here
                  +1
                  структура проекта – лишь инструмент. если вы разложите файлы проекта по директориям, это не значит что проект станет более структурированным. так же и с ООП :)
                  +8
                  Спагетти без соуса Болоньез?! Это издевательство, а не стёб…
                    +4
                    Не волнуйтесь, вы разбираетесь в программировании.
                    +8
                    В «спагетти» код очень легко вносить частные изменения, но тяжело общие. В ООП код ноборот легко общие, внедрением дополнительного слоя абстракции, но тяжело изменить чтото в частности. Поэтому все проэкты к своему окончанию таготеют к «спагетти», т.к. обобщеных изменений все меньше, в то время как количество небольших локальных ценджей становится очень много.
                    Возможно на этапе сапортинга написаного кода уже и нет смысла в поддержке красивого ООП, но начинать проект как «спагетти», по моему, не стоит.
                      +5
                      Когда читал про спагетти, вспоминал один из проектов и возникала мысль: какого черта? код пишут программисты, а не менеджеры, если им так нравятся спагетти, то пускай сами пишут. Но для начала пускай попробуют вникнуть в спагетти… ну потом я все же стал думать что все это стеб :)
                        0
                        А можно пример, как в ООП коде сложно «изменить что-то в частности»?
                        +2
                        О спагетти подходе к авиации, я не знаю какому самолету принадлежит эта кабина — но это точно старый самолет

                        habr.habrastorage.org/post_images/f8d/788/169/f8d788169ba95d9e2b5fe3d50662b150.png
                        Вот кабина Су-35 (у Т-50 примерно такая-же)

                        i027.radikal.ru/1105/d9/38c46a1ed241.jpg
                        Дело в том что в современном самолете много параметров и как каждому отдельный дисплей давать, так это пилот с ума сойдет — щас эргономика движется в сторону ситуативности, что тебе щас нада то приборы самуля и покажут.
                          +1
                          Вы уверены, что за последние 50 лет самолеты в своих параметрах продвинулись настолько сильно, что стоит доказывать наличие сводных экранов именно с этим?
                          На сколько мне известно, возможно я ошибаюсь, но самолеты летают все те же расстояния, с теми же временными интервалами и при тех же расходах топлива.
                          Ну и конечный вопрос: вы уверены, что экраны и рычажки истребителя сильно схожи с пассажирским ту 154?
                            0
                            >>>за последние 50 лет самолеты в своих параметрах продвинулись настолько сильно

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

                            >>>и при тех же расходах топлива

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

                            ПС: А вообще сравните хонду сивик конца 80х и версию 2009 года, вроде не самолет — а путь развития то какой.
                              0
                              Мне кажется, что вы имеете далекое отношение к авиации.

                              Для упрощения задачи сравните общедоступные ТТХ хотя бы Су 27 и Су 35. Посмотрите разницу между датами их выпуска и принятия на вооружение.

                              Самолеты перевозящие 500 и более человек уже давно есть, я, относительно регулярно, на них летаю.

                              Сравнил, вышел во двор и сравнил, хонду 5 поколения и вот, свеженькую, но она седан, наверное это не скажется на сравнении? Ну так их характеристики ничем выдающимся не отличаются. Если для вас наличие ЖК дисплея стало доступнее, это не значит, что изменения глобальны: о) Более того, это не значит, что данные на нем более понятны. Я вот очень привык к аналогу: о)
                          +4
                          Ухаха — мне понравилось, что в архитектуре тоже спагетти подход используется. Сразу захотелось свой вход в метро на 27 этаже. И аэродром в подвале.
                            +6
                            Вот любят сравнивать архитектуру, строительство и программирование… Блин.

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

                            Как часта ситуация «дом построили, через пол года снесли и построили новый, через пол года перестроили изнутри дом на 60%»? А в программном продукте она нередка, и более того, возможна. И я не могу сказать, что это плохо — код гибче бетона. А то, что каждый раз нужно напрягать извилины, что бы перестроить изнутри программу, что бы та при этом не рухнула… не знаю, грешно на это жаловаться, как по мне.
                              0
                              В основном там каждый раз делают все заного с нуля (но ограниченны технологиями строительства, можно сравнить с фреймворками).
                              И точно также в процессе строительства возникает необходимость все переделывать (например после того как построенно уже этажей 5, требуется увеличить этажность на 6 этажей к изначальному проекту и изменить функциональное назначение уже запроектированных), но там это все сложнее в том плане, что кроме переделывания требуется, еще пересогласовать в инстанциях.
                              Наверное в 18 веке было по другому и сначала проектировалось а потом строилось, а вот сейчас тк все хотят по больше денег заработать в минимальные сроки зачастую строить начинают еще до того как проектировать.

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

                              Т.е на самом деле сравнение со строительством весьма корректно, не случайно патеррны проектированния архитекторы придумали.
                                0
                                аналоги легаси кода там тоже есть — это может быть реконструкция существуещего строения, да и на индивидуальном уровне вам могут просто придти файлы из другой организации в таком виде, что с ними будет не возможно работать
                            +17
                            Конечно, придётся уволить нескольких ключевых разработчиков, которые не будут согласны с новым подходом, но ведь станет возможно писать простой код
                            Можно сделать ещё лучше: уволить всю команду сразу, а на сэкономленные деньги нанять настоящих гуру спагетти-методологии, которые всосали её с молоком матери и дадут сто очков вперёд любому традиционному кодеру. Эти люди родом из Индии и Пакистана, и среди их преимуществ — не только виртуозное владение методологией, но ещё и уникально экономные часовые рейты порядка $6. Какой ещё специалист экстра-класса обойдётся вам так дёшево? Воистину, скромность — черта, присущая лишь настоящим гениям.
                              +9
                              У нас есть один старый спагетти-проект. Он глючит, зависает, ломается, исправляется с болью, криками и унынием. Там очень много хаков, многие из них «задокументированы» на словах. В логах полно ошибок, которые на самом деле не ошибки. Боевой код не всегда лежит в vcs. Я не знаю, что будет, если уйдёт человек, который его поддерживает. Когда он в отпуске, поддержка этого проекта достаётся мне: это какой-то кошмар, с каждым вопросом приходится разбираться дня по два.
                              Советую дважды подумать, прежде чем начинать придерживаться этой методологии. Засрать спагетти-проект на порядок проще, чем проект с продуманной архитектурой.
                                +2
                                Пусть этот человек напишет обёртку aka интерфейс, через который вы и будете работать.
                                  +3
                                  Обёрткой делу не поможешь. Весь код — одна огромнейшая функция, в которой внутри что-то сожет сломаться…
                                    +1
                                    Вот оно, функциональное программирование!
                                    0
                                    Если ошибка в коде, никакие обертки не помогут.
                                  +5
                                  По-моему вы поспешили с этой статьей. Январь на дворе, а не апрель.
                                    –5
                                    «без комментариев»
                                      +5
                                      «с комментариями» что ли?!
                                      +4
                                      Мой опыт говорит, что система должна быть грамотно разбита на кусочки, а в каждом кусочке может быть сколько угодно спагетти-кода.
                                        +4
                                        Ни одного упоминания равиоли и лазаньи. Это возмутительно!
                                        +14
                                        При использовании спагетти-методологии важно правильно выбрать инструмент разработки.
                                        Хороший, добротный спагетти-код, можно, к примеру, запросто наваять на LabVIEW:

                                          +1
                                          Спасибо за LabVIEW, выглядит интересной темой!
                                            +2
                                            LabView, ИМХО, как раз пример, как сделать плохо.
                                            Из самого раздражающего: когда пишешь на LabView блок, дополнительно еще держишь в голове, а вместится ли этот код в тот маленький прямоугольничек оставшегося свободного пространства, или придется думать, как бы раздвинуть всё нераздвигаемое вокруг еще немного.
                                            Или когда надо править код на ноутбуке без мышки

                                            Как мне показалось LabView — это маркетинговая попытка показать, что программировать легко могут и не программисты, с помощью прямоугольничков и проводков
                                              +5
                                              Почему вы ошибки проектирования приписываете к недостаткам LabView? Там точно так же можно объединять части кода в целое и представляться они будут единым блоком. А если у вас в LabView не хватает места на одном экране, чтобы увидеть всю композицию, то представьте себе код без вызовов функций в несколько тысяч строк и сравните с ним. Хорошая схема ничем не отличается от хорошего кода пока и то и то мы воспринимаем зрительно.
                                                0
                                                Немного некорректное сравнение. Возьмите любую более-менее сложную программу на LabView — в один экран не уместится. Но я говорил не об этом. Допустим, есть какой-то фрагмент, когда, в который надо немного добавить кода в соответствии с корректировкой задачи. И первое, о чем придется задуматься: хватит ли места внутри прямоугольника под этот код, а если не хватит, то где его брать, учитывая, что вокруг всё пространство занято
                                                  +1
                                                  Так ведь и я о том же.
                                                  Вот у нас есть метод и там 20 строчек кода, нам нужно добавить еще 5. Тут же возникает вопрос — не пора ли нам создать новый метод (прямоугольник) и сократить текущий метод на 10 строчек или все таки впихнуть эти 5 строчек (станет 25) в ущерб читабельности.

                                                  Возьмите любую более-менее сложную программу на LabView — в один экран не уместится.

                                                  Все строчки кода сложного проекта тоже на экране не уместятся.
                                                    0
                                                    Если размер функции определяется разработчиком в соответствии с архитектурой — это одно, а если ограничивается размерами прямоугольника в который надо эту функцию вписать — это совсем другое. И, увы, хорошей архитектурой решить проблемы трудно читаемого и трудно модифицируемого (имею ввиду размещение компонентов) кода, не всегда получится. Порой приходится делать единственно возможным, некрасивым способом
                                                    +1
                                                    Вы как-то очень уж серьёзно к вопросу подошли… Спагетти-образный код можно где угодно сделать, просто любой LabVIEW программист практически неминуемо пройдёт через эту стадию, так как графическая среда очень к этому располагает. С опытом обычно приходит понимание того, как вести разработку на LabVIEW, чтобы добавление кода осуществлялось легко и не приводило к спагетти, при этом большинство диаграмм не превышала бы размеров одного экрана (в большом проекте могут быть тысячи таких диаграмм). Тут как бы параллельно с разработкой в голове идёт непрерывный процесс функциональной декомпозиции и диаграммы не разрастаются с увеличением сложности. Ну и частый рефакторинг, конечно необходим (диаграмму выше это не спасёт — там заново переделать проще).
                                                      0
                                                      Красивая теория. В LabView она заканчивается, когда начинается практика, и получается «код» как на картинке выше
                                                        +1
                                                        Не, это не теория, это практика. Я просто в LabVIEW больше десяти лет работаю, у нас в отделе трое LabVIEW — программистов и мы разрабатываем проекты весьма приличных размеров (при этом разработка идёт «по учебнику» — ну то есть спецификации, контроль кода и всё такое). И нет такого спагетти — кода, как на картинке выше. В LabVIEW уровень вхождения относительно невысок, но простота LabVIEW иллюзорная — чтобы стать профессионалом, требуется года этак три-четыре активного программирования — тогда теория выше постепенно станет практикой.
                                                          0
                                                          Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.

                                                          На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?
                                                            +2
                                                            Ну вот как-то так, что-ли, если «в лоб» (мне, правда, пришлось в пять минут уложиться, ибо бесплатный Jing, что под рукой оказался, только пятиминутные ролики даёт делать):

                                                            Для тока и напряжения я синус с косинусом от суммы времени с индексом взял, а индикаторы по рандому моргают.
                                                              +2
                                                              Спасибо! Был неправ. Последний раз в LabView работал в 2005 году, тогда так сделать было нельзя, похоже, язык сильно продвинулся с тех пор
                                              +7
                                              Что-то в вашей компании не так, если методологию написания кода выбирают менеджеры, а не программисты.
                                                +3
                                                Кстати, а еще спагетти можно варить и есть на обед! Тоже неплохая экономия бюджета.
                                                  +3
                                                  Пойду перепишу пару проектов пока не поздно.
                                                    +1
                                                    Я требую пояснения профита от спагетти-методологии в системном администрировании(см. картинку в статье), или «юмор»+«опасно для людей с эпилепсией и неустойчиво психикой» в теги.
                                                      +1
                                                      Для приведённой картинки, где изображён двухсекционный гамак по мотивам сверхурочных работ в крупном датацентре, спагетти-подход позволил сделать цельную конструкцию без диспропорциональных дыр и дифференцировать жёсткость по её поверхности, что положительно скажется на качестве ночного отдыха персонала.
                                                      (Тег "impromptu" стоял изначально.)
                                                      +1
                                                      В статье описан злой анти-подход. Давайте все начнем индусить, писать спагетти код и потом умрем от количества багов. Автор пишет, что типа добавление одной функции очень быстро делается. Только стоит их добавить 20 — и крен кто потом найдет, где эти функции запрятаны. Метод для компаний, нанимающих низкоквалифицированных индусов и пытающихся с помощью них делать неподъемные проекты. Лучше как раз наоборот как можно раньше прививать культуру написания хорошо структурированного и поддерживаемого кода, рассказывать про такие вещи как SOLID, антипаттерны, дать почитать книгу Code complete, итд Но главное — это практика.
                                                        0
                                                        С каких пор любое отклонение от того, что написано в книге, методологии, справочнике великого программиста стало индусским кодом или кодом написанным низкоквалифицированными специалистами?
                                                          0
                                                          Не любое, а изложенное в статье.
                                                          0
                                                          Вы серьезно? :)
                                                          +9
                                                          Из моего детектора сарказма полетели искры, а потом потух экран, и теперь ничего не показывает.
                                                            –3
                                                            Мне вот интересно, спагетти-методология имеет какое-то отношение к летающему макаронному монстру? xDDD
                                                              +1
                                                              Дочитал, полный негодованием.
                                                              Зато лишний раз задумался о том, что такое хорошо, а что такое — плохо.
                                                                +1
                                                                А аббревиатура SDD теперь будет обозначать также Spaghetti Driven Development.
                                                                  –2
                                                                  В статье подробное и развернутое описание давно известной методологии.

                                                                  Only users with full accounts can post comments. Log in, please.