LINUX.ORG.RU

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

 , , , ,


2

2

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

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

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

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

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

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

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

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

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

Л. Торвальдс



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

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

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

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

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

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

Ты хоть видел одного заказчика, который может внятно объяснить что хочет в итоге?

Конечно, как правило такие заказчики в продуктовых компаниях, они сами делают в своей компании IT отдел и знают зачем он им.

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

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

TDrive ★★★★★
()

ППКС. Ну, почти

Но это меняет не многое.

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

Я тебя так сильно задел? Какая рьяная особь.

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

Ты хоть видел одного заказчика, который может внятно объяснить что хочет в итоге?

Всегда есть согласованное тз и план-график работ. Я же должен обосновать перед заказчиком и проверяющими органами стоимость и сроки? Или ты думаешь попрошу пару-другую миллиардов и мне их сразу дадут?

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

Ты хоть видел одного заказчика, который может внятно объяснить что хочет в итоге?

вот бы придумали таких людей, которые бы выясняли, чего хочет заказчик до того, как вбуханы сотни денег в agile as fuck разаботку бесполезного кода. а если бы они ещё и за актуальностью требований следили потом…

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

Всегда есть

Ха-ха-ха!

проверяющими органами

Ха-ха-ха!

anonymous
()

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

http://www.softcraft.ru/design/moving/

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

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

«В крупных проектах», «в мелких проектах» и так далее. Речь не про эфемерную размерность, а про то, что программисту для фичи Икс не нужно этот код вообще читать и понимать. А только свою часть. И не методом Ивана Сусанина выяснять где там его часть, а где не его. В роли Поляков «в Яве аннотации», а в роли леса – говнокод этого проекта. Чего тут вообще может быть не понятно, я не понимаю.

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

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

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

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

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

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

Сто процентов. Если бы не одно но. В стартап- и около того среде большая чаксть проектов не заканчивается вообще. Вместо кода заказчику можно показыавть кракозябры и Идиш. И рассказывать, что де «мы прикрутили вот здесь авторизацию». Потому что проект с бо́льшей вероятностью загнётся, чем будет завершён. Причем со стороны заказчика. У него кончится финансированние и так далее.

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

От того, и забиватеся болт на всё. И согласие идёт со всем, что предложит заказчик. А значит – игнорированнием банального проектирования. Даже проектированния нагрузки. Короче, такие дела.

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

Речь не про эфемерную размерность, а про то, что программисту для фичи Икс не нужно этот код вообще читать и понимать. А только свою часть.

Еще раз, у него даже не получится прочитать весь код проекта если это не фигня какая нибудь мелкая. Сам прикинь, допустим проект в 150к строк кода, и сидят 10 человек которые каждый день добавляют в проект еще 1к строк. Что ты там собрался читать?

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

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

Да они могут на постоянке рабоать. Без закатов. За счёт того, что масса проектов закрывается из-за отсутствия финасов у заказчика. Или от того, что проект при запуске не взлетел (никоому не нужен) и его реальные проблемы (говнокод) никто не успел заценить.

Отношение успешных проектов к загнувшимся 1/10 в лучшем случае. Часть из них загибается ещё до запуска. И от этого аутсорц-конторки безо всяких закатов существуют годами. И даже имеют положительные рекомендации от пары всё-таки удачных проектов.

Вакханналия как она есть. И они портят программистов ). Аутсорц вообще пора уже прировнять к растлению. И статью за это.

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

Еще раз, у него даже не получится прочитать весь код проекта если это не фигня какая нибудь мелкая. Сам прикинь, допустим проект в 150к строк кода, и сидят 10 человек которые каждый день добавляют в проект еще 1к строк. Что ты там собрался читать?

Да, я согласен.

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

Зачем ты заставляешь меня повторяться? Я же уже написал что аутсорс так и работает.

Спокойно. Я ещё не дочитал.

anonymous
()

По сабжу: да, проектирую все, что можно спроектировать.

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

Юзаю https://www.diagrams.net, как селфхостед и как декстоп апп. Демка — https://app.diagrams.net

ravaya
()

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

seiken ★★★★★
()

Так смешно, когда люди лезут из своих академий (где у них бесконечное время и бесконечные ресурсы в виде бесплатной рабочей силы для проектирования и реализации их гениальных сферконей) в реальную разработку со своими ценными советами. Ах, какая жаль, UML не взлетел! Программы — не стихи. Делойте хорошо чтобы было хорошо, а плохо ни делойте.

Не видел ни одной сложной хорошо работающей программы, разработанной российскими академиками.

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

Не видел ни одной сложной хорошо работающей программы, разработанной российскими академиками

Тетрис например.

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

мужики ловили рыбу, а поймали рака
целый тред на лоре они в ТЗ искали
где у рака хвост, и подсоединён ли он
коаксиально.

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

Нэнси Голд

Ужос нах!

Может возродим дух /c/? На pfpmd, например.

Неееее…

Фарш невозможно провернуть назад и мясо из котлет не восстановишь!

shkolnick-kun ★★★★★
()
Ответ на: комментарий от microdo3nik

в реальную разработку

Поделки на скорую руку – это в лучшем случае рукоделие. В реальности – дешёвый понт уровня детского сада.

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

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

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

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

половина перекладывателей JSON и прочих full-stack разработчиков не способны внятно объяснить, как их код работает, даже на родном языке, который на ЕГЭ сдавали, выразить то же самое в UML моделях за приемлемое время — задача и для большинства остальных непосильная. не потому что UML плохой, а потому что других программистов у меня для вас нет.

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

высосанная из пальца дихотомия какая-то

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

Вот вам стих!

std:string string01 = «Ночь\r\n»;
std:string string02 = " Лежу на жене\r\n";
std:string string03 = " Одеяло прилипло к ЖОПЕ\r\n";
std:string string04 = «\r\n»;
std:string string05 = «Я кую кадры\r\n»;
std:string string06 = " Советской\r\n";
std:string string07 = " Стране\r\n";
std:string string08 = «\r\n»;
std:string string09 = «На ЗЛО\r\n»;
std:string string10 = " Буржуазной\r\n";
std:string string11 = " Европе\r\n";

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

не осилить UML

Чего там осиливать, лалка. Дальше бред про ЕГЭ проскипал, сорян, иди сдавай свои лабы и понтуйся перед школьниками.

выразить то же самое в UML моделях за приемлемое время

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

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

О чём и речь, никто кроме упоротых академишей таким бредом не занимается. В реальном мире нет смысла втискивать полное описание модели в UML, потому что это никому не нужно. Этим прагматичные люди и отличаются от академишей — первые осознают ценность своего времени и не занимаются ненужной хернёй потому что «так правильно».

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

не осилить UML

Чего там осиливать, лалка. Дальше бред про ЕГЭ проскипал, сорян, иди сдавай свои лабы и понтуйся перед школьниками.

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

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

мамку свою индустрией попугай.

В реальном мире нет смысла втискивать полное описание модели в UML, потому что это никому не нужно. Этим прагматичные люди и отличаются от академишей — первые осознают ценность своего времени и не занимаются ненужной хернёй потому что «так правильно».

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

jobig
()

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

anonymous
()

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

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

cvs-255 ★★★★★
()
Ответ на: комментарий от jobig

диаграмы

ой как мы удобно переобулись на ходу

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

так что иди перед скубентами понтуйся своим умл, лошара

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

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

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

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

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

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

отождествление UML с лабами хороший, критерий, кстати. примерно как «мы не на экзамене»

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

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

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

Если в команде работает хотя бы двое без схемы не обойтись.

И этот человек что-то имеет против визуального программирования?!

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

Такой подход низводит программиста до макаки, тупо набивающей код по чужой указке, и убивает полёт мысли.

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

То, что есть шарашкины конторы, где директор, архитектор и штукатур - одно и тоже лицо, никак не характеризует область в целом, даже если в массе своей шарашкиными конторами делается львиная доля всего «рынка»: ни завод, ни аэропорт они не построят. Что не мешает охрененному количеству «любителей» херачить будки, бани, вплоть до небольших коттеджей, на весьма хорошем уровне…

yyk ★★★★★
()

Есть такой дедушка, зав. кафедрой в ИТМО - Анатолий Шалыто. Очень толковый препод.

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

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

Тебе чем нультиреч не нравится? Можно ласково попросить у ультракозла консолидировать /c/ с 2.0 и 4.0, заявившись в место обитания правящей верхушки.

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

На pfpmd, например. Это где сделали регистрацию чуть ли не по инвайтам?

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

ПО создано для того, чтобы делать ошибки быстрее и проще

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

Кому-то надо компьютер для этого.

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