LINUX.ORG.RU

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

 , , , ,


3

2

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

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

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

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

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

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

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

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

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

Л. Торвальдс



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

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

Ещё немного, и сейчас ты расскажешь, что RDBMS - это тупик и все гоу на монгу.

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

Дядя, а по тезису «рукописи не горят, а алгоритмы не протухают» ты слил, или еще имеешь что сказать?

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

Очень сложный язык и вообще сложная тема.

Язак сложный, потому что сложная тема, или тема сложная, потому что сложный язык?

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

Это всё достаточно неоднозначные вопросы на самом деле.

alpha ★★★★★
()

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

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

Гленфорду Майерсу приписывают цитату:

We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process

Примерный перевод:

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

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

Квант. механику и весь этот матаппарат придумал не Ландау.

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

Я имел в виду, что Ландау писал для гораздо меньшего количества людей, чем пишет, например Шалыто или Майерс. Соответственно его аудитория более калиброванная и отборная и там люди действительно могут свободно читать формулы и им не нужны графими и прочая визуализация.

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

Я имел в виду, что Ландау писал для гораздо меньшего количества людей, чем пишет, например Шалыто или Майерс. Соответственно его аудитория более калиброванная и отборная и там люди действительно могут свободно читать формулы и им не нужны графими и прочая визуализация.

Он для студентов первокуров, то есть вчерашних школьников писал если что.

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

В совке ЖС бы назвали акронимом и предложили бы его использовать для микроконтроллеров.

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

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

Я понимаю, что это средство коммуникации. Это очень хреновое средство коммуникации.

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

Проблема в том, что код часто отражает поведение неявно.

Да, это правда. Плохо написанный код может быть очень невнятным.

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

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

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

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

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

Shadow ★★★★★
()

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

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

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

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от Shadow

PlantUML мегарулит и педалит в написании ТЗ и документации

+1

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

а картинка интуитивно понятна всем

Э, нет, картинка точно так же может быть совершеннейшим говном, в котором фига с два кто разберётся. Разница в том, что код хотя бы работает и что-то там делает, а картинка — дело совершенно безответственное.

Miguel ★★★★★
()

отчего-то «хорошо спроектированные» частенько читаются как вызов Ктулху. Отнюдь не стихи

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

Пример - в числодробилках есть понятия шаблона численной схемы.

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

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

Разница в том, что код хотя бы работает и что-то там делает, а картинка — дело совершенно безответственное

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

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

Я читал не школьный учебник и не учебник для перваков. Я читал про сверхтягучесть гелия.

MittenShmitten
() автор топика
Ответ на: комментарий от Miguel
  • Схемы метрополитена в метро.
  • Планы эвакуции в зданиях.
  • Навигация в музеях, гос.учреждениях и других местах с большими потоками людей.
  • Дорожные знаки.
  • Эмодзи, стикеры, иконки.

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

Есть ещё поговорка: «Лучше один раз увидеть, чем сто раз услшать». Она как бе говорит нам, что визуальное восприятие продуктивнее чем слуховое. Причём тут текст? А при том, что читая ты проговариаешь слова и как бы слуаешь сам себя.

Я считаю более спорить с тобой бесполезно.

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

Язак сложный, потому что сложная тема, или тема сложная, потому что сложный язык?

Я считаю что сложность это чисто субъективная оценка информации. Допустим есть некая информация, понятная одному человеку и не понятная другому. Чем они отличаются?

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

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

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

Нет конечно, ландаушиц это вполне себе типовой курс физики. Он конечно не для инженеров, но в целом хорошо написан, это классика.

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

Я вот без картинок не могу.

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

Это очень хреновое средство коммуникации.

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

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

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

У меня одногрупник так кодил, благо С такое позволяет. Он писал код пока строчка не кончалась, потом переходил на следующую. И цвет у него был один…

Еще древние что ли заметили, что все люди делятся на геометров (тех кто мысли пространственныи образами) и алгебраистов (тех кто мыслит формулами). За точные названия не поручусь.

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

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

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

Кстати, SVG формат является подмножеством XML (капитан очевидность), вы вполне можете его читать! Раз уж так хочется.

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

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

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

Значки, иконки, карты вместо слов - это к слову один из столпов Accessibility и Инклюзивности! В тч в разработке ПО.

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

Везде используются картинки.

И все перечисленные моменты не имеют отношения к программированию и к программистам.

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

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

Чтобы выражать проблему и её решение непосредственно кодом (статически, текстом) нужен DSL

Примерно так наверное и придумали ООП, объект - существительное, метод - глагол, поле - прилагательное. Давайте писать стихи.

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

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

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

Чтобы выражать проблему и её решение непосредственно кодом (статически, текстом) нужен DSL

графсхема - это тот же дсл

метапрог походу ничему людей не научил

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

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

ты, дружище, видно совсем шиз

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

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

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

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

я бы посмотрел на булыжник на колесе

что сказать то хотел?

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

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

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

от единомышленников ничему не научишься

эхокамера же

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

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

Нет, примерно так придумали ЛИСП.

объект - существительное, метод - глагол, поле - прилагательное

Ты удивишься…

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

графсхема - это тот же дсл

Вообще ни разу. UML диаграммы ещё куда ни шло.

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