Комментарии 63
На фоне тотального алкоголизма этих дней это больше похоже на юмор. Но, прошу заметить, действительно, часть проектов быстрее, легче сдавать спагетти. Иногда весь, иногда какую-то стадию.
«Гибкий, как спагетти, программист» — надо будет запомнить…
Честно говоря, я запутался. Не могу понять: или это стеб, или я ничего не смыслю в программировании.
В каждой шутке, как известно… ;)
Главное в любой другой день сомнений не возникло бы, но вот 1-го января начинаешь сомневаться и в своей адекватности и в авторе :)
НЛО прилетело и опубликовало эту надпись здесь
Спагетти без соуса Болоньез?! Это издевательство, а не стёб…
Не волнуйтесь, вы разбираетесь в программировании.
В «спагетти» код очень легко вносить частные изменения, но тяжело общие. В ООП код ноборот легко общие, внедрением дополнительного слоя абстракции, но тяжело изменить чтото в частности. Поэтому все проэкты к своему окончанию таготеют к «спагетти», т.к. обобщеных изменений все меньше, в то время как количество небольших локальных ценджей становится очень много.
Возможно на этапе сапортинга написаного кода уже и нет смысла в поддержке красивого ООП, но начинать проект как «спагетти», по моему, не стоит.
Возможно на этапе сапортинга написаного кода уже и нет смысла в поддержке красивого ООП, но начинать проект как «спагетти», по моему, не стоит.
Когда читал про спагетти, вспоминал один из проектов и возникала мысль: какого черта? код пишут программисты, а не менеджеры, если им так нравятся спагетти, то пускай сами пишут. Но для начала пускай попробуют вникнуть в спагетти… ну потом я все же стал думать что все это стеб :)
А можно пример, как в ООП коде сложно «изменить что-то в частности»?
О спагетти подходе к авиации, я не знаю какому самолету принадлежит эта кабина — но это точно старый самолет
habr.habrastorage.org/post_images/f8d/788/169/f8d788169ba95d9e2b5fe3d50662b150.png
Вот кабина Су-35 (у Т-50 примерно такая-же)
i027.radikal.ru/1105/d9/38c46a1ed241.jpg
Дело в том что в современном самолете много параметров и как каждому отдельный дисплей давать, так это пилот с ума сойдет — щас эргономика движется в сторону ситуативности, что тебе щас нада то приборы самуля и покажут.
habr.habrastorage.org/post_images/f8d/788/169/f8d788169ba95d9e2b5fe3d50662b150.png
Вот кабина Су-35 (у Т-50 примерно такая-же)
i027.radikal.ru/1105/d9/38c46a1ed241.jpg
Дело в том что в современном самолете много параметров и как каждому отдельный дисплей давать, так это пилот с ума сойдет — щас эргономика движется в сторону ситуативности, что тебе щас нада то приборы самуля и покажут.
Вы уверены, что за последние 50 лет самолеты в своих параметрах продвинулись настолько сильно, что стоит доказывать наличие сводных экранов именно с этим?
На сколько мне известно, возможно я ошибаюсь, но самолеты летают все те же расстояния, с теми же временными интервалами и при тех же расходах топлива.
Ну и конечный вопрос: вы уверены, что экраны и рычажки истребителя сильно схожи с пассажирским ту 154?
На сколько мне известно, возможно я ошибаюсь, но самолеты летают все те же расстояния, с теми же временными интервалами и при тех же расходах топлива.
Ну и конечный вопрос: вы уверены, что экраны и рычажки истребителя сильно схожи с пассажирским ту 154?
>>>за последние 50 лет самолеты в своих параметрах продвинулись настолько сильно
Хе-хе, то что скорости полетов не сильно увеличелись еще не говорит о заторможенности, растет тяговооруженность и массоотдача, самолет обростает целой кучей новых систем и их состояниям тоже нужна индикация
>>>и при тех же расходах топлива
Это не правда, как раз за топливную эффективность и борятся поколения новых пассажирских лайнеров, я сам с болью переживал что свехзвуковая пассажирская авиация ушла — но увы кто-то решил что не нужно стремится к перелету через алантику за пару часов, а надо топлива меньше жечь и людей больше перевозить (уже инженеры думают как сделать самолет на 500 и более человек).
ПС: А вообще сравните хонду сивик конца 80х и версию 2009 года, вроде не самолет — а путь развития то какой.
Хе-хе, то что скорости полетов не сильно увеличелись еще не говорит о заторможенности, растет тяговооруженность и массоотдача, самолет обростает целой кучей новых систем и их состояниям тоже нужна индикация
>>>и при тех же расходах топлива
Это не правда, как раз за топливную эффективность и борятся поколения новых пассажирских лайнеров, я сам с болью переживал что свехзвуковая пассажирская авиация ушла — но увы кто-то решил что не нужно стремится к перелету через алантику за пару часов, а надо топлива меньше жечь и людей больше перевозить (уже инженеры думают как сделать самолет на 500 и более человек).
ПС: А вообще сравните хонду сивик конца 80х и версию 2009 года, вроде не самолет — а путь развития то какой.
Мне кажется, что вы имеете далекое отношение к авиации.
Для упрощения задачи сравните общедоступные ТТХ хотя бы Су 27 и Су 35. Посмотрите разницу между датами их выпуска и принятия на вооружение.
Самолеты перевозящие 500 и более человек уже давно есть, я, относительно регулярно, на них летаю.
Сравнил, вышел во двор и сравнил, хонду 5 поколения и вот, свеженькую, но она седан, наверное это не скажется на сравнении? Ну так их характеристики ничем выдающимся не отличаются. Если для вас наличие ЖК дисплея стало доступнее, это не значит, что изменения глобальны: о) Более того, это не значит, что данные на нем более понятны. Я вот очень привык к аналогу: о)
Для упрощения задачи сравните общедоступные ТТХ хотя бы Су 27 и Су 35. Посмотрите разницу между датами их выпуска и принятия на вооружение.
Самолеты перевозящие 500 и более человек уже давно есть, я, относительно регулярно, на них летаю.
Сравнил, вышел во двор и сравнил, хонду 5 поколения и вот, свеженькую, но она седан, наверное это не скажется на сравнении? Ну так их характеристики ничем выдающимся не отличаются. Если для вас наличие ЖК дисплея стало доступнее, это не значит, что изменения глобальны: о) Более того, это не значит, что данные на нем более понятны. Я вот очень привык к аналогу: о)
Ухаха — мне понравилось, что в архитектуре тоже спагетти подход используется. Сразу захотелось свой вход в метро на 27 этаже. И аэродром в подвале.
Вот любят сравнивать архитектуру, строительство и программирование… Блин.
Сколько в год строится новых зданий (не новых зданий по уже просчитанным проектам, я в теме не разбираюсь, извините), а новых зданий с расчетом всего до последнего болта? А сколько разрабатывается приложений? В мире, под все платформы, прошивок всякой электроники?
Как часта ситуация «дом построили, через пол года снесли и построили новый, через пол года перестроили изнутри дом на 60%»? А в программном продукте она нередка, и более того, возможна. И я не могу сказать, что это плохо — код гибче бетона. А то, что каждый раз нужно напрягать извилины, что бы перестроить изнутри программу, что бы та при этом не рухнула… не знаю, грешно на это жаловаться, как по мне.
Сколько в год строится новых зданий (не новых зданий по уже просчитанным проектам, я в теме не разбираюсь, извините), а новых зданий с расчетом всего до последнего болта? А сколько разрабатывается приложений? В мире, под все платформы, прошивок всякой электроники?
Как часта ситуация «дом построили, через пол года снесли и построили новый, через пол года перестроили изнутри дом на 60%»? А в программном продукте она нередка, и более того, возможна. И я не могу сказать, что это плохо — код гибче бетона. А то, что каждый раз нужно напрягать извилины, что бы перестроить изнутри программу, что бы та при этом не рухнула… не знаю, грешно на это жаловаться, как по мне.
В основном там каждый раз делают все заного с нуля (но ограниченны технологиями строительства, можно сравнить с фреймворками).
И точно также в процессе строительства возникает необходимость все переделывать (например после того как построенно уже этажей 5, требуется увеличить этажность на 6 этажей к изначальному проекту и изменить функциональное назначение уже запроектированных), но там это все сложнее в том плане, что кроме переделывания требуется, еще пересогласовать в инстанциях.
Наверное в 18 веке было по другому и сначала проектировалось а потом строилось, а вот сейчас тк все хотят по больше денег заработать в минимальные сроки зачастую строить начинают еще до того как проектировать.
Ситуации с тем, что-то построили и обвалилось встречаются относительно часто, и если есть возможность то делают заного. Иногда бывают просчеты и после постройки дом сносят по юридическим причинам (в циливизованных странах бывают случаи, что и по эстетическим)
Т.е на самом деле сравнение со строительством весьма корректно, не случайно патеррны проектированния архитекторы придумали.
И точно также в процессе строительства возникает необходимость все переделывать (например после того как построенно уже этажей 5, требуется увеличить этажность на 6 этажей к изначальному проекту и изменить функциональное назначение уже запроектированных), но там это все сложнее в том плане, что кроме переделывания требуется, еще пересогласовать в инстанциях.
Наверное в 18 веке было по другому и сначала проектировалось а потом строилось, а вот сейчас тк все хотят по больше денег заработать в минимальные сроки зачастую строить начинают еще до того как проектировать.
Ситуации с тем, что-то построили и обвалилось встречаются относительно часто, и если есть возможность то делают заного. Иногда бывают просчеты и после постройки дом сносят по юридическим причинам (в циливизованных странах бывают случаи, что и по эстетическим)
Т.е на самом деле сравнение со строительством весьма корректно, не случайно патеррны проектированния архитекторы придумали.
Конечно, придётся уволить нескольких ключевых разработчиков, которые не будут согласны с новым подходом, но ведь станет возможно писать простой кодМожно сделать ещё лучше: уволить всю команду сразу, а на сэкономленные деньги нанять настоящих гуру спагетти-методологии, которые всосали её с молоком матери и дадут сто очков вперёд любому традиционному кодеру. Эти люди родом из Индии и Пакистана, и среди их преимуществ — не только виртуозное владение методологией, но ещё и уникально экономные часовые рейты порядка $6. Какой ещё специалист экстра-класса обойдётся вам так дёшево? Воистину, скромность — черта, присущая лишь настоящим гениям.
НЛО прилетело и опубликовало эту надпись здесь
По-моему вы поспешили с этой статьей. Январь на дворе, а не апрель.
«без комментариев»
Мой опыт говорит, что система должна быть грамотно разбита на кусочки, а в каждом кусочке может быть сколько угодно спагетти-кода.
Вот вам лазанья: www.youtube.com/watch?v=H0Hex7JG2Ao :D
При использовании спагетти-методологии важно правильно выбрать инструмент разработки.
Хороший, добротный спагетти-код, можно, к примеру, запросто наваять на LabVIEW:
Хороший, добротный спагетти-код, можно, к примеру, запросто наваять на LabVIEW:
Спасибо за LabVIEW, выглядит интересной темой!
LabView, ИМХО, как раз пример, как сделать плохо.
Из самого раздражающего: когда пишешь на LabView блок, дополнительно еще держишь в голове, а вместится ли этот код в тот маленький прямоугольничек оставшегося свободного пространства, или придется думать, как бы раздвинуть всё нераздвигаемое вокруг еще немного.
Или когда надо править код на ноутбуке без мышки
Как мне показалось LabView — это маркетинговая попытка показать, что программировать легко могут и не программисты, с помощью прямоугольничков и проводков
Из самого раздражающего: когда пишешь на LabView блок, дополнительно еще держишь в голове, а вместится ли этот код в тот маленький прямоугольничек оставшегося свободного пространства, или придется думать, как бы раздвинуть всё нераздвигаемое вокруг еще немного.
Или когда надо править код на ноутбуке без мышки
Как мне показалось LabView — это маркетинговая попытка показать, что программировать легко могут и не программисты, с помощью прямоугольничков и проводков
Почему вы ошибки проектирования приписываете к недостаткам LabView? Там точно так же можно объединять части кода в целое и представляться они будут единым блоком. А если у вас в LabView не хватает места на одном экране, чтобы увидеть всю композицию, то представьте себе код без вызовов функций в несколько тысяч строк и сравните с ним. Хорошая схема ничем не отличается от хорошего кода пока и то и то мы воспринимаем зрительно.
Немного некорректное сравнение. Возьмите любую более-менее сложную программу на LabView — в один экран не уместится. Но я говорил не об этом. Допустим, есть какой-то фрагмент, когда, в который надо немного добавить кода в соответствии с корректировкой задачи. И первое, о чем придется задуматься: хватит ли места внутри прямоугольника под этот код, а если не хватит, то где его брать, учитывая, что вокруг всё пространство занято
Так ведь и я о том же.
Вот у нас есть метод и там 20 строчек кода, нам нужно добавить еще 5. Тут же возникает вопрос — не пора ли нам создать новый метод (прямоугольник) и сократить текущий метод на 10 строчек или все таки впихнуть эти 5 строчек (станет 25) в ущерб читабельности.
Все строчки кода сложного проекта тоже на экране не уместятся.
Вот у нас есть метод и там 20 строчек кода, нам нужно добавить еще 5. Тут же возникает вопрос — не пора ли нам создать новый метод (прямоугольник) и сократить текущий метод на 10 строчек или все таки впихнуть эти 5 строчек (станет 25) в ущерб читабельности.
Возьмите любую более-менее сложную программу на LabView — в один экран не уместится.
Все строчки кода сложного проекта тоже на экране не уместятся.
Если размер функции определяется разработчиком в соответствии с архитектурой — это одно, а если ограничивается размерами прямоугольника в который надо эту функцию вписать — это совсем другое. И, увы, хорошей архитектурой решить проблемы трудно читаемого и трудно модифицируемого (имею ввиду размещение компонентов) кода, не всегда получится. Порой приходится делать единственно возможным, некрасивым способом
Вы как-то очень уж серьёзно к вопросу подошли… Спагетти-образный код можно где угодно сделать, просто любой LabVIEW программист практически неминуемо пройдёт через эту стадию, так как графическая среда очень к этому располагает. С опытом обычно приходит понимание того, как вести разработку на LabVIEW, чтобы добавление кода осуществлялось легко и не приводило к спагетти, при этом большинство диаграмм не превышала бы размеров одного экрана (в большом проекте могут быть тысячи таких диаграмм). Тут как бы параллельно с разработкой в голове идёт непрерывный процесс функциональной декомпозиции и диаграммы не разрастаются с увеличением сложности. Ну и частый рефакторинг, конечно необходим (диаграмму выше это не спасёт — там заново переделать проще).
Красивая теория. В LabView она заканчивается, когда начинается практика, и получается «код» как на картинке выше
Не, это не теория, это практика. Я просто в LabVIEW больше десяти лет работаю, у нас в отделе трое LabVIEW — программистов и мы разрабатываем проекты весьма приличных размеров (при этом разработка идёт «по учебнику» — ну то есть спецификации, контроль кода и всё такое). И нет такого спагетти — кода, как на картинке выше. В LabVIEW уровень вхождения относительно невысок, но простота LabVIEW иллюзорная — чтобы стать профессионалом, требуется года этак три-четыре активного программирования — тогда теория выше постепенно станет практикой.
Я бы хотел посмотреть, как бы вы красиво выполнили код такой несложной задачи, вполне практической: Имеется 30 датчиков одинакового типа, каждый датчик в реальном времени выдает 4 параметра, допустим float ток и напряжение и два boolean параметра: датчик исправен и датчик включен. Надо отобразить показания всех датчиков на одном экране, допустим 3 ряда по 10 слева направо, сверху вниз, в виде 2 танков (ток, напряжение) и 2х подписей (включен/отключен, исправен/ неисправен) на каждый датчик. Данные от датчиков можно эмулировать любыми функциями от времени и индекса датчика.
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?
На Delphi, например, эту задачу я могу выполнить за полчаса, красивым кодом, с короткими методами. Сколько времени уйдет, чтобы сделать это на LabView и насколько это получится красиво и без лапши?
Что-то в вашей компании не так, если методологию написания кода выбирают менеджеры, а не программисты.
Кстати, а еще спагетти можно варить и есть на обед! Тоже неплохая экономия бюджета.
Пойду перепишу пару проектов пока не поздно.
Я требую пояснения профита от спагетти-методологии в системном администрировании(см. картинку в статье), или «юмор»+«опасно для людей с эпилепсией и неустойчиво психикой» в теги.
Для приведённой картинки, где изображён двухсекционный гамак по мотивам сверхурочных работ в крупном датацентре, спагетти-подход позволил сделать цельную конструкцию без диспропорциональных дыр и дифференцировать жёсткость по её поверхности, что положительно скажется на качестве ночного отдыха персонала.
(Тег "impromptu" стоял изначально.)
(Тег "impromptu" стоял изначально.)
В статье описан злой анти-подход. Давайте все начнем индусить, писать спагетти код и потом умрем от количества багов. Автор пишет, что типа добавление одной функции очень быстро делается. Только стоит их добавить 20 — и крен кто потом найдет, где эти функции запрятаны. Метод для компаний, нанимающих низкоквалифицированных индусов и пытающихся с помощью них делать неподъемные проекты. Лучше как раз наоборот как можно раньше прививать культуру написания хорошо структурированного и поддерживаемого кода, рассказывать про такие вещи как SOLID, антипаттерны, дать почитать книгу Code complete, итд Но главное — это практика.
Из моего детектора сарказма полетели искры, а потом потух экран, и теперь ничего не показывает.
Мне вот интересно, спагетти-методология имеет какое-то отношение к летающему макаронному монстру? xDDD
Дочитал, полный негодованием.
Зато лишний раз задумался о том, что такое хорошо, а что такое — плохо.
Зато лишний раз задумался о том, что такое хорошо, а что такое — плохо.
А аббревиатура SDD теперь будет обозначать также Spaghetti Driven Development.
В статье подробное и развернутое описание давно известной методологии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О достоинствах спагетти-методологии