LINUX.ORG.RU

Программы - не стихи, их надо проектировать, а не писать.

 , , , ,


3

2

Этот пост как спроектировать.... заставил меня вспомнить о замечательном человеке и его статье. Есть такой дедушка, зав. кафедрой в ИТМО - Анатолий Шалыто. Очень толковый препод. И вот его статья «Программы –не стихи, их надо проектировать, а не писать» - http://is.ifmo.ru/main/article_ap.pdf .

Кроме критики сложившейся ситуации с производством ПО, Шалыто даёт ссылки на свои примеры проектирования и показывает почему так делать правильно. Ссылки прямо там в статье. Битых ссылок не встречал.

Вот самые интересные цитаты:

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

Бардак с ПО творится почти во всем мире. Если аппаратура проектируется всегда, и только потом производится, то проектная документация на программы на практике выпускается крайнередко. Универсальный язык моделирования (UML), на который одно время у многих были большие надежды, используется далеко не всегда, причем даже в тех случаях, когда он применяется, диаграммы обычно строят одни люди –архитекторы, а другие –программисты в лучшем случае в них заглядывают.

Я считаю, что до того, как начинать программирование системы, необходимо разобраться с ее поведением, ипредлагаю не начинать сразу писать программу, а сначала нарисовать «картинки»–графы переходов, которые опишут поведение будущей программы в терминах состояний, переходов между ними и действий, выполняемых в состояниях и/илипереходах.

К чему это я? Мне хотелось бы узнать, много ли на ЛОРе среди разработчиков моих единомышленников - тех кто солидарен с мыслями изложенными в статье и тоже практикует проектирование ПО перед кодингом. А заодно интересно каким софтом вы пользуетесь для рисования схем, графов, алгоритмов. Может кто-то поделиться своими примерами проектов ПО.

PS, для модераторов. Линукс здесь при том, что:

Простота требует проектирования и хорошего вкуса.

Л. Торвальдс



Последнее исправление: MittenShmitten (всего исправлений: 1)

Не солидарен. Требования никто не знает, пока программу не напишут. Толку нет от этих проектирований. Надо быстро писать и в прод. А потом быстро переписывать, когда будет понимание, что надо. Андроид писали изначально как прошивку для фотоаппарата. Ну и толку было бы его проектировать, если потом он пригодился совсем в другой нише. И такое везде.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

«Если бы строители работали также, как программисты пишут программы - первый же залетевший дятел разрушил бы здание до основания».

«Чем отличается программирование от лифтостроения, а тем что заказчику при приеме лифта не придет в голову -: „Хмм, как классно лифт ездит вверх вниз, а можно сделать чтоб было еще влево, право?“

Minona ★★☆
()

Просто надо не метаться по сферам а стараться работать в одном конкретном направлении - тогда в голове всегда будут графы «так хочет заказчик», «вот так на самом деле надо» и «вот так оно в итоге будет работать».
Аналогично с языками/окружением - в голове постепенно строятся графы «как оптимально обеспечивается хранение/передача/обработка», «как в конкретной среде работает многопоток и соотв как под капотом работают очереди/блокировки/синхронизация» и т.п.
Лично для меня всегда самым проблемным в плане графов «в голове» был именно многопоток, его да, приходится иногда рисовать на бумажке чтоб не забыть про все внешние заходы

rukez ★★★★
()

А заодно интересно каким софтом вы пользуетесь для рисования схем, графов, алгоритмов.

Pikchr, диалект PIC Кернигана за авторством Ричарда Хиппа.

anonymous
()
Ответ на: комментарий от Miguel

Алгоритмы — это и есть код.

«Государство это Я!»(с)

Код это ОДИН ИЗ способов представления алгоритма, причем далеко не всегда самый понятный. Один и тот же алгоритм может быть запроган очень по разному, даже для самого простого алгоритма код может быть нифига не прозрачным за счет криворукрсти автора или всяких оптимизаций.

Более того, с развитием железа и яп код протухает. Алгоритмы нет.

AntonI ★★★★★
()

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

Пока на рынке изменений не предвидится.

anonymous
()
Ответ на: комментарий от AntonI

Более того, с развитием железа и яп код протухает. Алгоритмы нет.

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

anonymous
()
Ответ на: комментарий от anonymous

Сейчас квантовая криптография как правило юзается (там где юзается) для установления обычного шифрованного канала.

Так что Лиза я Вам конкуренцию в парикмахерской составить не смогу.

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

У Мольера был герой, говорил прозой и сам этого не осознавал.

Всё он осознавал, только названия не знал.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Код это ОДИН ИЗ способов представления алгоритма блаблабла

Посмотри контекст. Обсуждалось то, как Я пишу алгоритмы в VSCode.

Miguel ★★★★★
()
Ответ на: комментарий от cobold

Относи это к первому варианту - криво сделанный самолёт. Вот например в случае с боингом отвечал сам боинг как компания.

ya-betmen ★★★★★
()
Ответ на: комментарий от AntonI

А какое отношение решение задачи факторизации за (log n) имеет к шифрованию канала?

anonymous
()
Ответ на: комментарий от Miguel
  1. для кого ты их пишешь?

  2. ты их все таки пишешь а не рисуешь, да?

Пример - в числодробилках есть понятия шаблона численной схемы. Это простая но очень важная картинка. Ее можно хоть в ASCII графике сделать и вставить в код, но эта картинка очень много поясняет.

Сама численная схема написанная в виде формул, это от пары строк до талмуда страниц арабской вязи. Узкие специалисты понимают. Код ее реализующий обычно не понимает никто кроме автора.

Если тебе ненужно предварительное проектирование, выписывание алгоритмов словами/картинками и пр. - наверное ты работаешь один и над задачами где это все ненужно. Но пытаться свой личный скромный опыт натянуть на всю индустрию это как бэ… не надо так.

AntonI ★★★★★
()
Ответ на: комментарий от Miguel

Схемы… даже не знаю, что имеется в виду.

Я вот рисую достаточно много схем процессов просто в Inkscape.

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

alpha ★★★★★
()
Ответ на: комментарий от AntonI

для кого ты их пишешь?

Для своего работодателя.

ты их все таки пишешь а не рисуешь, да?

Конечно.

наверное ты работаешь один

Нет.

Но пытаться свой личный скромный опыт натянуть на всю индустрию

Я работал в игроделе, разработке антивирусов, биг-дате, вебе, и ещё много в чём. Я бы не назвал свой опыт «скромным».

Miguel ★★★★★
()
Ответ на: комментарий от alpha

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

Плохо. Хотя бы потому, что эта твоя схема через месяц перестанет соответствовать действительности.

Miguel ★★★★★
()

Наверное товарищ всё-таки не про проектирование кода и алгоритмов.

Проектирование ПО должно быть выше кода. Даже - вообще без кода.

Тут-то как раз ПО как стихи. Если «палка-селедка» не считать.

Хорошо спроектированное ПО умеет с наименьшим количеством костылей расширять функциональность. Как, например, pacman (на мой взгляд). Плохо спроектированное - не умеет. Как, например, ext4 (на мой взгляд).

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

Toxo2 ★★★★
()
Ответ на: комментарий от Miguel

Для своего работодателя.

Работодатель читает то что ты написал? Или это все таки читает только компилятор? Если только компилятор - значит ты это пишешь только для компилятора все таки. И если это так, то значит у вас bus-фактор=1.

Нет.

И твои коллеги смотрят в твой код и говорят - все понятно, ок. Круто, че… А через 10 лет какой нить джун переводя твой код на какой нить питон-6 сможет понять твой код?

Я работал в игроделе, разработке антивирусов, биг-дате, вебе, и ещё много в чём. Я бы не назвал свой опыт «скромным».

Мой очень скромный опыт говорит что код не снабженный доками умирает вместе с его аффторами - его невозможно патчить и модифицировать. Сейчас вот ровно такая история у нас с одним прекрасным старым кодом на фортране 00х годов рождения.

А сложный проект без предварительного проектирования с картиночками сделать невозможно. Взаимодействовать с коллегами без картиночек тоже невозможно. Это при том что я не работал ни геймдеве ни в вебе ни в бигдате, да и в команде у нас редко бывает больше двух человек.

В книжках пишут примерно то же самое.

AntonI ★★★★★
()
Ответ на: комментарий от Miguel

схема через месяц перестанет соответствовать действительности.

Как тока схема перестает соответствовать действительности, на очередной встрече говориться «Помните вот ту схему (фоточка доски/файл из инкскейпа)? Она теперь вот такая (на доске маркером рисуется новый вариант/показывается новый файл).» Ок, говорят остальные, доска фотается/файл пушится под гит, вопрос закрыт.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от Miguel

Плохо.

Нет.

Хотя бы потому, что эта твоя схема через месяц перестанет соответствовать действительности.

Цель не в том чтобы выбить эту иллюстрацию в камне.

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

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

Допустим объяснить схему CI в CentOS Stream лучше начинать с картинки типа https://pic4a.ru/22/emB.png чем со стены текста.

Формальная схема наподобие https://docs.fedoraproject.org/en-US/rawhide-gating/_images/Rawhide%20Single-Build%20Updates%20Gating%20Flow.jpg в данном случае мало чем поможет.

alpha ★★★★★
()
диаграммы обычно строят одни люди –архитекторы, а другие –программисты в лучшем случае в них заглядывают.

Я работал на разных проектах, с архитекторами и без, умею чертить UML, а лет в 12-13 даже блок схемам обучался и могу утверждать что все хня. Никаких серебряных пуль нет.

Схемы не нужны в небольших командах (~5 человек) когда очень грамотный кодер в роли «архитектора» делает скелет проекта, а остальные подключаются и пишут детали.
Когда есть условный «линус торвальдс» и небольшая команда - схемы не нужны.

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

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

Мне кажется именно фреймворки виноваты в том что программы теперь не проектируют, а пишут.

anonymous
()
Ответ на: комментарий от AntonI

Работодатель читает то что ты написал?

Нет. Коллеги читают.

А через 10 лет какой нить джун переводя твой код на какой нить питон-6 сможет понять твой код?

Мне, честно говоря, плевать на джуна, который будет мою Scala переводить на всякую хрень.

Мой очень скромный опыт

Пытаться свой личный скромный опыт натянуть на всю индустрию это как бэ… не надо так.

Miguel ★★★★★
()
Ответ на: комментарий от AntonI

Как тока схема перестает соответствовать действительности

Хаха. Ты регулярно просматриваешь ВСЕ схемы и проверяешь, какая из них соответствует действительности, а какая — нет?

Miguel ★★★★★
()
Ответ на: комментарий от alpha

Стена текста:

- CentOS Labs
  - ?MR checks
  - sources
(build)
- CentOS Stream Koji (build environment)
  - -gate
  - ?package checks
  - -pending
(compose)
- Rest
  - repository, images
  - ?compose checks
  - mirrors

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

Miguel ★★★★★
()
Ответ на: комментарий от alpha

Да, записать это всё словами можно и нужно, но не так.

Ну и отлично. Нафига тогда наскальной живописью заниматься?

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Затем что цель не в том чтобы записать чтобы было и доставалось из шкафа только в момент проведения внешнего аудита. А в том чтобы сэкономить время и ресурсы на понимание вопроса.

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

Да, и без этого жить можно. Но так ты получаешь информацию качественнее и более точно и в большее количество потоков, что облегчает усвоение.

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от alpha

сэкономить время и ресурсы на понимание вопроса.

Рисование, по сравнению с текстом, тратит время, а не экономит его.

Но так ты получаешь информацию качественнее и более точно и в большее количество потоков, что облегчает усвоение.

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

Вспомнилось: «Из задних рядов не без труда протиснулся Косопузый. Его лысина — высокая, яйцом — блистала поверх стульев. На ходу он открывал портфель, вытаскивая оттуда бумаги. Под мышкой косо висел свиток. Это оказалась диаграмма. Он повесил ее на доску и устремил в зал темный взор маньяка.»

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Рисование, по сравнению с текстом, тратит время, а не экономит его.

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

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

Потому что ты так сказал?

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

Ну и да, автору диаграммы это разумеется тоже помогает. Потому что изложение даже одной и той же мысли разными способами позволяет найти проблемы и пропуски.

Вспомнилось:

Сарказм можно применить к абсолютно любому поводу и теме.

alpha ★★★★★
()

Конкретно для случаев типо того, который был в Росатоме, есть https://ru.wikipedia.org/wiki/IEC_61131-3, и компиляторы его языков в конечные автоматы, которые будут управлять ядрёным реактором.

Но я бы не сказал, что это решит проблемы, которые описаны в статье.

P.S.: UML не нужен.

shkolnick-kun ★★★★★
()
Последнее исправление: shkolnick-kun (всего исправлений: 1)
Ответ на: комментарий от alpha

достаточно того факта, что ты прочитав этот самый легкий текст можешь дополнительно сверить его с картинкой

Э... нет. В твоём варианте — не могу, потому что текста нет. В моём — потому что нет картинки.

для разных людей ответ выглядит по-разному

Да, но мы не про абстрактных «разных людей», мы про программистов. Которые на работе занимаются написанием текстов.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Да, но мы не про абстрактных «разных людей», мы про программистов. Которые на работе занимаются написанием текстов.

Пойди освежи воспоминания о спорах на тему читабельности и нечитабельности отступов в питоне :)

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

alpha ★★★★★
()
Последнее исправление: alpha (всего исправлений: 1)
Ответ на: комментарий от Miguel

1этмм занимаются авторы схем. Альфа же пытается до тебя донести, сземы - это средство коммуникации. Как тока кто то кому то хочет что то объяснить тут же достается/ рисуется актуальная схема.

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)

следите за руками

type IO a = RealWorld -> (a, RealWordl)
main :: IO ()
всё остальное берём из математики с её аксиомами, теоремами, алгеброй.

а квадратики со стрелочками нужны для описания данных.

anonymous
()
Ответ на: комментарий от alpha

Кажется Ландау не любил графиков - типа формула говорит сама за себя и нет ничего нагляднее формулы. Мб Мигель это такой Ландау от программирования…

AntonI ★★★★★
()
Ответ на: комментарий от anonymous

юмл это же вообще ор на весь двор

Зря ты так, use case diagram и activity diagram очень полезные штуки именно на этапе согласования фичи, которые помогают заказчику формализовать его хотелки, а исполнителям понять, что вообще от них хотят.

no-such-file ★★★★★
()
Ответ на: комментарий от AntonI

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

И я не придумываю и рисую новую с нуля, а выбираю более подходящую и адаптирую под новый разговор.

alpha ★★★★★
()
Ответ на: комментарий от Miguel

Код — это И ЕСТЬ описание поведения

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

no-such-file ★★★★★
()

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

no-such-file ★★★★★
()
Ответ на: комментарий от AntonI

Я пытался читать книжки Ландау и учебники. Очень сложный язык и вообще сложная тема. Таких как Ландау единицы на весь мир, а проектирование и картинки нужны простым инженерам, которых миллионы.

MittenShmitten
() автор топика
Ответ на: комментарий от untitl3d

рисовали квадратики и стрелочки между ними

Потом пришёл асинхронный JS и стрелочки накрылись медным тазом.

Shadow ★★★★★
()
Ответ на: комментарий от Miguel

текст точнее и легче для понимания

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

thesis ★★★★★
()
Ответ на: комментарий от AntonI

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

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

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

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

Причём оба геометры, и оба могли сказать что-то типа «представим как в пятимерном пространстве две двумерные сферы трансверсально пересекаются по одной точке» Но вот подход к записям и материалам совершенно разный.

alpha ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.