LINUX.ORG.RU

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

 , , , ,


2

2

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

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

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

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

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

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

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

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

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

Л. Торвальдс



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

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

Сидел я как то

Я как то тоже сиживал. В ИК-10, Кыштым. На строгом семёру оттянул … Эх, времена БЫЛИ …

Владимир

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

да я прочитал, там сама завязка треда странная

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

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

Владимир.

anonymous
()

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

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

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

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

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

Вопрос очень простой. Новый разработчик должен прочитать все доки ко всем вызовам и что-то понять? Разумеется нет. Хотя на практике да. И это отстой.

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

ты не уважаешь сообщество разработчиков и плюёшь на своих коллег

Тех, кто целенаправленно портит мой код — да, не уважаю.

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

Они это бессознательно. Я художник я так вижу. Целенаправленности нет.

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

Да, Столяров он ТАКОЙ …

Владимир

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

Бесполезно, я уже попытался это выяснить. Толку никакого. Видимо,

просто увидел знакомое слово

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

что значит он не должен читать доку по апи но на практике читает?) зачем же он это делает?

если чел собирается вносить изменения в апи то стоит ознакомиться с текущим вариантом, если нет то можно пока не читать.

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

Я думаю это не постановка вопроса, в заманивающее читателя название статьи.

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

Хвост (лат. cauda) в сравнительной анатомии — отдел сегментированного тела, располагающийся позади анального отверстия и не содержащий кишечника.

«Позади анального отверстия» – это как вообще? Моей фантазии не хватает, чтобы это представить. Позади отверстия, ыыыы (бьётся головой об стену).

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

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

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

  1. Картинка в голове заказчика – без ньюансов, и никаким ТЗ ты из него эти ньюансы не вытянешь, потому что он сам не осознаёт их, пока не обнаружит, что программа, написанная строго по его ТЗ, делает не то и не так, что ему на самом деле было нужно. Чтобы не повторяться.

  2. Плюс в процессе работы в 100% случаев обнаруживается, что можно сделать лучше (удобнее для юзера, эффективнее, etc.), чем заказчик сформулировал. И в 50% из этих 100% случаев для этого требуется мелкое несущественное (без негативных эффектив) отступление от ТЗ.

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

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

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

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

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

Потому что

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

вариантов решения проблемы две - долго и нудно обьяснять заказчику основы работы компьютера, ос и будущего софта, дабы он понял что можно сделать быстро/легко/просто=дёшево (соединить пластиковые линейки в кластер и прогнозировать запасы линеек по тенденции победы титана над пластиком), что сделать сложнее ибо требуется «допы» (построить зависимость износа линеек от температуры во время борьбы с титаном) а что сделать с помощью одного только компьютера без внешних средств - невозможно (крутить линейку с обратной связью, превышающей по скорости системный таймер)

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

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

чем дольше тусуешься в одной конкретной области […] ТЗ залетает как по маслу

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

по сути достаточно накидать им перечень уже решенных ранее задач

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

Но я вещал про то, что водопад с предварительной полной проработкой ТЗ – нереал. И эти все ньюансы взаимодействия с заказчиком общего вывода не меняют.

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

Это я как практик говорю.

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

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

Есть такой дедушка, зав. кафедрой в ИТМО

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

Не умаляя пользы от проектирования и документации там где они оправданы, таки есть случаи когда требования к программе не ясны до её написания, и есть случаи когда программирование это именно что написание стихов (а стихи, кстати, вполне себе проектируют, если вдруг уважаемый академик не в курсе). И таких случаев подавляющее большинство, а что из себя представляют исключения прекрасно ясно из статьи, чисто по кейвордам «военпред», «согласование», «НПО», «ГОСТ». Сейчас в моде другие кейворды - TTM и MVP, а от работы предпочитают получать творческое удовольствие. Да, понятно что он про ответственные сферы, но я лично предпочту расколотиться со всей семьёй на самолёте софт для которого писали в удовольствие, чем жить в мире где творчество сдерживается бюрократией.

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

Тетрадочка и ручка. Легковесно и кроссплатформенно.

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

Враньё, кстати. Всё самое крутое железо - DIY. Только из него и вырастают достойные серийные продукты, как те же hackrf, flipper и arduino, и возможно это только по причине гибкой разработки, постоянных экспериментов и переделок. Никаких согласований и актуальной документации в этих условиях быть не может.

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

Unless ты работаешь с постоянными заказчиками, уже привыкшими понимать тебя с полуслова

No! реально могут быть разные люди но из одной сферы. у нас тут небольшой приток новых инженеров (читай - заказчиков) образовался в довольно специфической области (колориметрия) - год назад я бы с ними тз согласовывал сутками, но так случайно получилось что я за последний год много занимался именно спектрометрами всякими и вот теперь прям легко получается всё согласовывать - на лету в диалоге парсятся ихнеи «у нас тута решётка ловит от А до Б» в человечьи «ну тогда охват от В до Г с разрешением Д по спекам Е» и сразу на бумажку, а так бы переводить да рыть «шта эта ваще за фигня» приходилось постоянно с перекидыванием по почте письмами «получил, ушёл думать» :-) В обратную сторону то-же работает - понятно как самому писать ТЗ на протокол обмена с ихнеми железяками - т.е. понятно где там будут медленные данные а где быстрые, сколько их в принципе может быть и что из них нужно а что проще самому пересчитать (программисты то между собой то-же ТЗшками обмениваются, притом что для «прикладного» легко, просто и понятно то для «железячного» наоборот, и .. наоборот :-) )

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

Но я вещал про то, что водопад с предварительной полной проработкой ТЗ – нереал. И эти все ньюансы взаимодействия с заказчиком общего вывода не меняют

Ну странно ждать от человека, который не знает, как пишется слово «нюанс», что он сможет все их учесть даже при самом способствующем процессе

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

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

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

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

Ты «забыл» такую мелочь ресурсы: бюджет и время.

Не тред, а сборище таксойдистов-неосиляторов, мля

Ну так что ты тут тогда делаешь?

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

реально могут быть разные люди но из одной сферы

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

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

Никаких согласований и актуальной документации в этих условиях быть не может

Ты «забыл» такую мелочь ресурсы: бюджет и время

не мы, а вы. не нам, а вам

Ну так что ты тут тогда делаешь?

бисер мечу, чего непонятно

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

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

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

Ладно, спокойной ночи. Приятно было пообщаться.

dimgel ★★★★★
()

Наброшу, не читая: программы не ситхи, джедая на выйдет.

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

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

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

<голосом Дроздова>

Здесь вы можете наблюдать очень редкое явление, которое имеет большое значение для экосистемы ЛОРа. Пятихвостый звездочник наставляет особь, которая вот вот обрастет последним хвостом и в конец потеряет умственные способности. Он тыкает пальцем в рыбу и произносит: «где у ней жопа». Он как бы показывает добродетель и хочет передать опыт своего поколения, но на самом деле ему попросту более нечем заняться.

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

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

что значит он не должен читать доку по апи но на практике читает?) зачем же он это делает?

если чел собирается вносить изменения в апи то стоит ознакомиться с текущим вариантом, если нет то можно пока не читать

Ну прочитает он доки к эйпиай и что? Что это даст ему? У него задача сменить БД на другую, например. Эйпиай тут вообще при чём?

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

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

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

Просто же.

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

А «я Яве аннотации» в данном случае будет как пометка мелом не стене, что провод в стене проходит зигзагом по диагонали.

Основная проблема как раз в том, что масса программистов считает себя у мамки самыми умными и «они лучше знают» и так далее. По итогу – горы не документированного говнокода.

А самое главное, что есть ещё и проектная нагрузка. И нагрузка к тому как там «залихватски» всё написанно не имеет отношения вообще. А проект, UML, и прочее дерьмо – прямое отношение.

Вот ведь дела. В машиностроении больше уделяется чертежду изделия, как правило, чем самому изделию. Потому что чертёж – это всё. А сваял на коленке – это рукаделие и ремесленничество. Не промышленная тема.

В ремесленнисчестве и рукоделии достаточно и «в Яве аннотаций» и Доксигена, и Сваггера и прочих инструментов для очумелых ручек.

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

И при этом толпы этих люмпен-программистов играют на руку одновременно и заказчику и начальнику. Вместо того, чтобы подвести член к носу и заявить, что сперва это дело нужно проектировать и это время и деньги. Где и есть основная загвоздка. Зачем платить за какой-то там проект? Он де денег не приносит. Да и воообще проект (заказ) может не взлететь. А тут траты лишние и прочее.

Но фактически, имея проект, работать над ним намного проще. И ротацию кадров проводить проще. И т.н. басс-фактор уменьается. Точнее уменьшаяется вермя введения нового разработчика в проект, чтобы сделать что-то с ним. И при текучке кадров проще.

На дистанции оно дешевле. Но если проект продать проблематично. То код продаётся. И за код, даже если его очень долго писать (из-за заговнокоженности виду отсутствия проекта), то это ничего. Ведь код продаётся. А проект – нет.

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

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

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

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

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

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

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

Нет. Такого варианта нет. С заказчим смысл говорить тольк на языке бизнесс-логии и всё. Хочешь такую выборку – готовья отлистать за сервак побольше вот на столько.

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

программа – главное представление, оно же и единственное

Лютое, феерическое 4.2.

Все пишут программы, но практики знающие теорию пишут хорошие программы.

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

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

Откуда ты взял этот подход? На крупных проектах ни кто не в состоянии прочитать весь код) Пока он это будет делать то что уже прочитано поменяется) Это тупая идея читать код просто так.

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

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

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

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

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

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

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

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

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

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

Проект развивается по этапам. Все определено в ГОСТ. НИОКР, эскизный проект, ОКР. На каждом этапе требования уточняются и дополняются.

PS Сразу видно, что опыт работы у вас небольшой.

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