LINUX.ORG.RU

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

 , , , ,


2

2

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

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

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

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

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

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

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

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

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

Л. Торвальдс



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

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

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

Перевод спецификации UML в сокращённом варианте с пояснениями - это книжка на 600 стр.

Неужели у рядового разработчика будет время, чтобы эту лабуду читать?

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

Роботу не нужны умные вещи. Робот - чтобы работать работу.

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

Перевод спецификации UML в сокращённом варианте с пояснениями - это книжка на 600 стр.
Неужели у рядового разработчика будет время, чтобы эту лабуду читать?

а вот microdo3nik кричит «что там осиливать». но должен отметить, спецификация UML – дело десятое, рядовому перекладывателю JSON'ов не её в первую очередь знать надо, а доменную область в совершенстве, чтобы его модель хоть как-то была близка к реальности. проблемы у большинства начинаются уже тут

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

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

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

спецификация UML – дело десятое, рядовому перекладывателю JSON’ов не её в первую очередь знать надо, а доменную область в совершенстве

«В совершенстве» доменную область не знает никто, даже архитект заказчика. У какого-то манагера возникает идея в голове, потом после дискуссий прений сторон R&D что-то проектирует и реализует. Нужно ли это клиентам и в такой ли форме или в совершенно иной неизвестно, особенное если клиент массовый (те же смартфоны). A «рядовому перекладывателю JSON» вообще на все наплевать, лишь бы тесты не фейлились, релиз релизился и з/п платилась.

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

И чё все прикопались к Гитлеру?

88

anonymous
()

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

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

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

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

domain, предметная область называй как удобнее

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

даже архитект заказчика

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

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

А в твоем неограниченном опыте предметная область по плечу (по мозгам?) «рядовому перекладывателю JSON» или ты описываешь маниловский сценарий?

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

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

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

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

если человеку нравится перекладывать JSON’ы за полкозули — хрен ты его заставишь отвлечься.

ну мало ли, может он это делает лучше кукаретика концептуальщика, который знает все о предметной области (или думает, что знает), но не понимает, как и что реализовать. А перекладыватель JSON и библиотеки все попробовал и сравнил, и знает, в какой либе какой баг не закрыт и какой валидатор фичастее, и проч.

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

std:string string01 = «Ночь\r\n»;

Родина им \v дала, а они \r\n жрут!

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

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

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

Итого, UML - фантазии теоретиков кунг-фу. Серверная JavaScript - лажовая «коробочка и/из песочницы» для лажовых говнокодеров думающих о компьютере как о бездонной бочке, которая о -двойное- чудо, неожиданно и мгновенно заканчивается. Тудаже бездумное применение всяких докеров, миграций, фреймворков и остальной лажи для написания программ любительского уровня, типа мессенджер или текстовые редакторы.

Т.е. нормальной подготовки среднестатистического программиста уровня 80-ых - 90-ых сегодня почти и не осталось. За последние 15 лет видел пару человек. И ситуация с годами все хуже и хуже. В основном везде выскочки пишущие наборами фреймворков, которым не хватает терабайта озу чтобы говно-сайтик интернет магазина просто открывался. Для 1К-сотки посещения сегодня строят целые дата центры.

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