LINUX.ORG.RU

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

 , , , ,


3

2

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

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

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

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

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

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

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

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

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

Л. Торвальдс



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

В совецком союзе информатику именно так и преподавали - рисовали квадратики и стрелочки между ними. Без комплуктеров. Мы думали нас обманывают, а из нас оказывается архитекторов делали!

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

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

MittenShmitten
() автор топика

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

Интересно, как быстро тебя назовут моим виртуалом и забросают камнями?

torvn77 ★★★★★
()

дедушке вынырнуть бы из водопадного манямирка и лабораторных работ на два экрана, чтобы понять, почему никто не любит UML (потому что рисование чего-то более или менее серьёзного – отдельный труд, не имеющий ничего общего с программированием, да и с проектированием слабо связанный). подавляющее большинство и в natural language не всегда в состоянии сформулировать, а требовать выбрать адекватную модель и корректно её изобразить от типичного перекладывателя JSONов приведёт к тому, что перекладыватель свалит к конкурентам с повышением зарплаты, а следующий обойдётся уже сильно дороже.

надёжное и отказоустойчивое ПО работает в основном под Linux/UNIX

святая толстота

anonymous
()

Мне хотелось бы узнать, много ли на ЛОРе среди разработчиков моих единомышленников - тех кто солидарен с мыслями изложенными в статье

Наверняка, не мало.

и тоже практикует проектирование ПО перед кодингом

Наверняка, мало.

ashot ★★★★
()

на ранних стадиях создания программы заказчик и разработчик однозначно и верно поняли друг друга и согласовали техническое задание

да дедушка гений вестимо. как же мы не догадались - все согласовать заранее да и все.

?ля, да это же уже давно на куски разобрала индустрия, пройдясь перед этим по конвееру граблей, гуглите waterfall methodology failure

крч такой в такой бред верят только люди которые не занимались никогда никакой проектировкой и программированием, и тролли

к какой категории подлежит препод я догадываюсь. а ты, автор?

anonymous
()

Когда падает криво спроектированный самолёт - пользователи погибают.

Когда падает криво спроектированная программа - пользователи терпят.

К сожалению когда решает рынок, то кто первым встал - того и тапки. Так что систему не починить.

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

крч такой в такой бред верят только люди которые не занимались никогда никакой проектировкой и программированием, и тролли

Не соглашусь.

Я 15 лет проектирую перед кодингом. Без всяких waterfall. Обычные блок-схемы алгоритмов, графы переходов конечных автоматов, описание архитектуры.

Рекомендую прочитать статью.

StoryTeller
()

Можно пример правильных программ, написаных^Wспроектированных дедушкою? Ну, чтобы знать, как надо.

anonymous
()

ах, да, забыл про юмл сказать - юмл это же вообще ор на весь двор.

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

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

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

Как это относится к проектированию ПО?

А UML вообще для лохов, которые не умеют кодить, вися на хвосте.

Это ты типа так ловко ввернул аллегорию про обезъян? :)

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

Я поднимаю свой бокал
За то, что был закопан кал.

Это были стихи, ведь их надо писать, а не проектировать.

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

Ну ввернул.

Как это относится к проектированию ПО?

Что «это»?

thesis ★★★★★
()

Универсальный язык моделирования (UML), на который одно время у многих были большие надежды, используется далеко не всегда

Потому что он говно.

сначала нарисовать «картинки»

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

до того, как начинать программирование системы, необходимо разобраться с ее поведением

Нет лучшего способа описать поведение программы, чем написать её. Код — это И ЕСТЬ описание поведения.

практикует проектирование ПО перед кодингом

Если ты уже запроектировал программу, то чего там кодировать? Запускай компилятор.

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

Для рисования графов я использую graphviz. Для алгоритмов — VSCode. Схемы... даже не знаю, что имеется в виду.

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

единственные люди, которые не несут ответственности за свою работу

Вообще-то так принято говорить о госчиновниках. Государство - способ ухода от ответственности.

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

В принципе да, но, скажем, от пользователя твоего API трудно ожидать, что он будет читать код.

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

Miguel ★★★★★
()

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

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

был один контрактор, написавший для нас классную систему автогенерации Swagger-документации из кода

долго писал, интересно?

anonymous
()

Если аппаратура проектируется всегда, и только потом производится, то проектная документация на программы на практике выпускается крайнередко.

Не всегда. Часто перед проектированием надо сделать несколько прототипов. Сложное изделие вы с первого раза не спроектируете. Также далеко не всё можно просчитать, часть характеристик можно узнать только изготовив прототип.

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

документации мало, потому-что программисты - ленивые ушлепки, либо потому-что их программы того не стоят

середины нет

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

Хорошо написанная программа выполняет функцию документации.

+1

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

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

Я 15 лет проектирую перед кодингом. Без всяких waterfall

Опыт разработки ПО - 5 лет, не считая университета и школы

ты ж мой хороший

anonymous
()

«Программы –не стихи, их надо проектировать, а не писать»

Ну это же наброс. А нельзя их и проектировать и писать, чтобы хорошо читались? И к тому же речь обо всех вообще программах. Опять же наброс. Может этот

Очень толковый препод

плохо себе представляет разнообразие всевозможных программ по типам и объёмам данных и целевым оптимизируемым эксплуатационным параметрам?

Ну для ЛОРа, как пример грамотного наброса - я считаю, зачёт.

anonymous
()

Я не хочу проектировать, я хочу аджайл и смузи!

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

гнусные никому ненужные стихи, пожалуй да, надо

anonymous
()

Схему данных я обычно рисую.

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

То есть понять как работает программа может только программист.

Понятие «хорошо написаннае» такое же растяжимое как и «хороший программист».

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

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

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

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

плохо себе представляет разнообразие всевозможных программ по типам и объёмам данных и целевым оптимизируемым эксплуатационным параметрам?

ты хоть почитай кто это на википедии, прежде чем судить о квалификации препода.

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

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

Может ты скажешь, почему автомобили с «автопилотом» на самом деле с «асистентом водителя» и если водитель кого то собъёт, то отвечать будет он, а не программист.

Про посадки чиновников ты и сам можешь найти в интернете информацию.

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

Абсолютно не могу судить о его квалификации, как преподавателя. Судя по тому, что он свои идеи Вам смог объяснить и научить ими пользоваться как раз преподаватель он хороший. Тут одно время были мегатреды про Метапрог, видимо их автор тоже его ученик :) Я, кстати, ничего против квадратиков и стрелочек не имею, тоже люблю порисовать простым карандашом на белом листе бумаги :)

А ещё когда заказчики в погонах, то понятно, что им квадратики со стрелочками как-то плавнее заходят :) Но не у всех же такое счастье.

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

anonymous
()

Кто проектирует софт? Да почти все, хотя бы в уме. Надо же понимать, что ты писать будешь. Почему не проектируют в uml? Потому что программисты пишут, а не рисуют. Uml хорошо эффектным менеджерам подходит. Что надо сделать, чтобы было ТЗ? Надо завести отдельного человека, который дожмёт заказчика и заставит его согласовать ТЗ.

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

Потому что он говно.

+много

Нет лучшего способа описать поведение программы, чем написать её.

Нет конечно

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

Зачастую это описание излишне детальное. Если в команде работает хотя бы двое без схемы не обойтись.

Если код толще 1000 строк (условно), даже если кодер один ему все равно нужна схема. Хорошо если он это осознает и может накарябать чето на листочке. Плохо если он этого не осознает и рисует смутную картинку у себя в голове.

AntonI ★★★★★
()

В тех немногих книжках что я читал про организацию разработки пишут то же самое.

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

AntonI ★★★★★
()

В конце 70-х - начале 80-х, при Миллсе, IBM активно продвигала PDL. До сих пор кое-где используется. Интересно, что всякие диаграммы и схемы из него генерируются в одно касание, а вот обратное неверно. Впрочем, духовных наследников anonimous уже достаточно понабежало.

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

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

ya-betmen ★★★★★
()

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

я не кодер, но с Шалыто согласен.

Линукс здесь при том, что надёжное и отказоустойчивое ПО работает в основном под Linux/UNIX.

неа.
QNX, VxWorks, etc.

Minona ★★☆
()

А что дед написал сам, чтобы поучать других? К разработке линукса он имеет отношение?

anonymous
()

С академической точки зрения описанный подход правилен и понятен, проблема возникает на практике.

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

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