Проектирование и эволюция программ

Sonic86 · 08/04/08 8562

Возьмем какой-нибудь большой программный комплекс, который пишут несколько десятков человек. Теперь возьмем довольно частые (на мой взгляд) факторы. Будем считать, что программа в общем и целом уже написана, но у нее есть множество средних небольших разнообразных недостатков, которые программисты дорабатывают. Программа в целом является довольно связной, т.е. программисту, что-то пишущий (к.л. модуль) нужно с вероятностью примерно 0,05 обращаться к знаниям, относящимся к другим модулям. Пусть программист пишет не какой-то один кусок программы, который может охватить мысленно, а выделяет небольшие кусочки, неглубоко анализирует то, что там происходит (поскольку у него еще много других таких же проблем) и вносит какие-то исправления. Нередко также встречается, что заказчик не имеет единого, подробного, детального плана программы хотя бы по причине ее громоздкости, неглубокого понимания ее работы, и требует в каждый момент времени какое-то случайное требование. Далее, верификация программы, опять же по причине ее сложности делается на нескольких, наиболее вероятных практически тестах, поэтому остается неизвестным, правильно программа работает или нет. Также существует в нормальных компаниях разделение программистов на мегапрогеров, пишущих фундаментальные вещи, и обычных, пишущих какую-нибудь частную фигню прикладного характера. Ну и так далее. И тому подобное.
Получается, что программа не планируется и строится как здание, а эволюционирует в прямом смысле слова, как живой организм! Вот только ничего хорошего в этом нету, и разум в ней от этого не появится. У программы появляются черты, аналогичные чертам организма: никто толком не знает, как он работает, появляется много похожего кода и много сложного кода, в котором трудно разобраться и который никто разбирать не хочет. Появляется много лишнего кода (аналог молчащей ДНК) вида if 1=0 then /*многобуков*/ end if; Появляется много кода, которые дублируют друг друга. Работа программы становится вероятностной, и бороться с этим почти невозможно. Программа не делается окончательно, каждая ее часть постоянно меняется. Есть также еще предположение, что программа возникает, растет, развивается, как живой организм, потом накапливает в себе много ошибок, становится неуправляемой и умирает.

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

-- Пт окт 22, 2010 21:00:11 --

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

Day · 30/09/10 119

Цитата:

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

ИМХО, очень глубока

Цитата:

насколько это часто встречается?

Постоянно.

Цитата:

как с этим бороться в указанных условиях?

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

Цитата:

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

Увы! Пока мы будем обдумывать, наша программа станет никому не нужна.
Или найдется кто-то более шустрый. сделает менее надежную, но работающую вещь.

Postrelyonysh · 25/10/10 17

Sonic86 в сообщении #364944 писал(а):

насколько это часто встречается?

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

Sonic86 в сообщении #364944 писал(а):

как с этим бороться в указанных условиях?

Заменой методологии проектирования с идиотского Object-Oriented Design'а на старый добрый Language-Oriented и, как желательное следствие, сменой инструментов разработки. Беда только в том, что программисты "старой школы" непригодны для этого, а любое радикальное изменение - риск. Но, как говорится, кто не рискует...

-- Пн окт 25, 2010 15:47:06 --

Day в сообщении #365192 писал(а):

сделает менее надежную, но работающую вещь.

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

Sonic86 · 08/04/08 8562

Postrelyonysh писал(а):

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

Обалдеть! Значит не я один такой..., ну хоть ущербным чувствовать себя буду меньше.

Postrelyonysh писал(а):

Sonic86 писал(а):

как с этим бороться в указанных условиях?

Заменой методологии проектирования с идиотского Object-Oriented Design'а на старый добрый Language-Oriented и, как желательное следствие, сменой инструментов разработки. Беда только в том, что программисты "старой школы" непригодны для этого, а любое радикальное изменение - риск. Но, как говорится, кто не рискует...

а если я не директор, а обычный исполнитель? Податься во фрилансеры...
Меня интересовали более частные советы. Например, как тестировать написанный код. Мне просто необходимо сейчас быстро и качественно работать.
Вот такой, например, совет: написать что-то, уйти, прийти через час и все забыв критично перечитать, и исправить.

arseniiv · 27/04/09 28128

Postrelyonysh, мне кажется, вы преувеличиваете… :roll:

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

Maslov · 09/08/09 3438 С.Петербург

Sonic86 в сообщении #366095 писал(а):

Меня интересовали более частные советы. Например, как тестировать написанный код.

Сейчас основной упор всё больше делается на автоматизированное тестирование: ПО разрабатывается таким образом, чтобы основную часть функциональности можно было покрыть тестами, выполняющимися в автоматическом режиме.

Другими словами, схема примерно такая:
- детально планируем очередной кусок функциональности, который надо реализовать;
- пишем программные тесты, которые позволяют проверить, насколько новая функциональность удовлетворяет спецификациям;
- реализуем новую функциональность в программном коде и обеспечиваем безошибочное выполнение всех тестов;
- для того чтобы убедиться, что мы не сломали ничего из реализованного ранее, выполняем все "предыдущие" наборы тестов.

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

Sonic86 · 08/04/08 8562

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

Maslov · 09/08/09 3438 С.Петербург

Sonic86, получается, я тоже повторяюсь :)

Sonic86 в сообщении #366145 писал(а):

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

Что всё делать исключительно руками? Тесты писать или программу тестировать?

Sonic86 · 08/04/08 8562

И то и другое. С клиента надо вводить данные, сохранять и вообще преобразовывать их в БД, запрашивать оттуда и смотреть потом по специальной отладке - правильно я что-то сделал или нет.

(Оффтоп)

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

В следующий раз если что-то буду делать, обязательно попробую автоматическое тестирование. И отпишусь, наверное.

Maslov · 09/08/09 3438 С.Петербург

А что в Вашем случае является неавтоматизируемым?
- ввод данных с клиента?
- преобразование?
- сохранение данных в БД?
- извлечение данных из БД?
- сравнение с требуемым результатом?

Sonic86 · 08/04/08 8562

Ввод данных с клиента. М.б. это как-то и можно сделать, но я не умею.

-- Пн окт 25, 2010 21:09:14 --

Само создание теста должно быть вводом данных с клиента.

Postrelyonysh · 25/10/10 17

arseniiv в сообщении #366111 писал(а):

У ООП есть своя область применения

Лично я таких областей, кроме агентного моделирования, не припомню.

arseniiv в сообщении #366111 писал(а):

не важно, встроены они в язык или нет

Как раз важно не то, какие конструкции уже встроены в язык, а то, какие новые конструкции может реализовать программист средствами самого языка в условиях конкретной прикладной задачи. Чем ближе адаптирован язык к предметной области - тем легче соблюдать принципы системного подхода. Сложные концепции можно, конечно же, выражать и через композицию низкоуровневых абстракций (переменные, циклы, классы и т.п.), но тогда за деревьями леса не увидишь. Было бы это не важно - не было бы такой популярности всяких кодогенераторов и прочих внешних языковых надстроек вроде GUI builder'ов.

arseniiv в сообщении #366111 писал(а):

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

Вы, верно, хотели сказать "надумана"? Всё, о чём мы здесь говорим - выдумано: до появления Homo Sapience в природе не было Computer Science.

Но допустим, я правильно понял. В таком случае скажу, что вера в мощь и всеприменимость ООП - она таки надумана, и распиаренность этой методологии сильно преувеличена. Всё то же самое можно делать неизмеримо проще и качественнее, и с много более высоким показателем code reuse.

-- Вт окт 26, 2010 09:09:14 --

Sonic86 в сообщении #366095 писал(а):

а если я не директор, а обычный исполнитель?

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

Sonic86 в сообщении #366095 писал(а):

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

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

-- Вт окт 26, 2010 09:10:00 --

Sonic86 в сообщении #366164 писал(а):

Само создание теста должно быть вводом данных с клиента.

Задача генерации кода изнутри программы - прямая дорога в Лиспоподобные технологии. День потеряешь - потом за пять минут долетишь.

bin · 22/09/09 ∞ 1907

Postrelyonysh в сообщении #366027 писал(а):

Sonic86 в сообщении #364944 писал(а):

как с этим бороться в указанных условиях?

Заменой методологии проектирования с идиотского Object-Oriented Design'а на старый добрый Language-Oriented и, как желательное следствие, сменой инструментов разработки. Беда только в том, что программисты "старой школы" непригодны для этого, а любое радикальное изменение - риск. Но, как говорится, кто не рискует...

-- Пн окт 25, 2010 15:47:06 --

Я, можно сказать, программист "старой школы" - окончил МГУ в 1980 ;-)

И про всесильность ООП высказывался критически, например: M.I.Trofimov, The End of Pascal?, BYTE, March, 1990, p.36. M.Trofimov, OOOP - The Third "O" Solution: Open OOP. First Class, OMG, 1993, Vol. 3, issue 3, p.14. Но хоть и нет в мире совершенства, ООП безусловно полезно во многих случаях. Например, для GUI. Большинство популярных сейчас языков имеют смешанную парадигму: не хочешь использовать ООП - не используй, вернее: используй только там, где это нужно и удобно. Не помню точной ссылки, но в разгар ОО революции была опубликована забавная статья, где автор поставил целью написать транслятор ассемблера, строго следуя ОО парадигме. Основной класс был "транслятор", иерархия выстроилась головоломная ;-)

Postrelyonysh в сообщении #366027 писал(а):

Day в сообщении #365192 писал(а):

сделает менее надежную, но работающую вещь.

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

ИМХО, слова "работающая" и "надежная" и должны быть синонимами! Слишком много сейчас "глючного" софта, начиная с ОС и компиляторов. Как следствие, все чаще и чаще происходят техногенные кактастрофы с ужасающими последствиями. Инновации, к сожалению, большей частью тоже выбрасываются на рынок сырыми - следствие жестокой конкурентной борьбы. В то же время пора бы вспомнить забытое многими старое. Прежде всего, это принципы защитного программирования, наиболее полно реализованные в языке Паскаль. Однако, учитывая успехи ОО-подходов, сейчас стоит говорить об ОО Паскале уровня Delphi-7, например. Но и там стоило бы вспомнить о некоторых старых и зарекомендовавших себя приемах. Например, для борьбы с неинициализированными переменными вплоть до MPW Pascal Mac OS 7.x боролись простым, но эффективным способом: run-time система при соответствующей опции загоняла во все переменные определенный код, например, FFFF... попытка использования такой переменной влекла ошибку времени выполнения. А еще, конечно же, нужны удобные анализаторы исходного кода: для обнаружения больших дублирующих фрагментов, мертвого кода и т.д. Чем проще и систематичнее язык, тем проще сделать такой анализатор и тем лучше он будет работать. Для языков типа С++ с его многочисленными неоднозначностями попытки сделать успешные универсальные анализаторы кажутся обреченными на неудачу.

-- Вт окт 26, 2010 16:04:37 --

Пару слов про генераторы кода: вспомним, например, yacc и прчие "бизоны"- разработчики языков с удовольствием применяют их для испытания концепции нового языка, но чтобы сделать удачную версию компилятора для реальной работы, нужно ручное программирование. Я с удовольствием применял и применяю простые генераторы кода во многих своих проектах, но к сожалению на практике их возможности ограничены. Когда и если AI достигнет таких высот, что пользователь сможет скомандовать компьютеру "напиши мне программу, рещающую следующую задачу...", то такой генератор, может, будет полезен. Хотя возможен казус, повторяющий неоднозначное отношение к машинному доказательству широкоизвестной теоремы о четырех красках: "как можно доверять доказательству или программе, которую никто из людей не может понять?" ;-)

-- Вт окт 26, 2010 16:09:55 --

Sonic86 в сообщении #364944 писал(а):

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

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

-- Вт окт 26, 2010 16:26:21 --

Sonic86 в сообщении #366095 писал(а):

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

Многое зависит от конкретной задачи. Но часто для трудноустранимых ошибок нужно ее локализировать и сделать легко наблюдаемой. Для этого код стоит минимизировать, т.е. написать как можно более короткую программу (с применением тех же библиотек), которая воспроизводит ту же ошибку. И для тестирования бывает полезным похожий подход: минимизировать объем тестируемого кода. В идеале тестировать каждый раз один модуль, не превышающий размером нескольких сотен строк. Все такие тесты стоит документировать и сохранять в отдельной папочке (с подпапочками) и с указателем для быстрого поиска - в больших проектах папочка разбухает до "гигов". Очевидно, что подключив в систему протестированный модуль, нужно убедиться, что он работает правильно и в системе, т.е. тестирование в два этапа: 1) тестирование модуля на корректность; 2) тестирование системы на совместимость с новым модулем.

Postrelyonysh · 25/10/10 17

bin в сообщении #366409 писал(а):

Я, можно сказать, программист "старой школы" - окончил МГУ в 1980

Уточню, что я имел ввиду "старую школу" стран СНГ. На западе зачастую учат нормально. На русском языке литературы по хорошему программированию аццки мало.

bin в сообщении #366409 писал(а):

ООП безусловно полезно во многих случаях. Например, для GUI.

Типичнейший пример ситуации, где ООП особенно не в тему - это как раз GUI, и единственная причина его здесь популярности - это массовая доступность дешёвых дрессированных кодеров, которые, кроме свистоперделок, ничего нормального написать не могут. Эрик Реймонд об этом писал.

Между тем перед вашими глазами яркий пример не-ООПного GUI - веб-страница. Я же предпочитаю Tcl/Tk.

bin в сообщении #366409 писал(а):

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

А ещё можно штаны через голову надевать - тоже очень удобно.

bin в сообщении #366409 писал(а):

В то же время пора бы вспомнить забытое многими старое. Прежде всего, это принципы защитного программирования, наиболее полно реализованные в языке Паскаль.

С какими "стырами" подходами и с какими "забытыми" языками в сравнении? С фортрано-ассемлерной кашей из GOTO?

bin в сообщении #366409 писал(а):

Однако, учитывая успехи ОО-подходов, сейчас стоит говорить об ОО Паскале уровня Delphi-7, например.

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

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

bin в сообщении #366409 писал(а):

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

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

bin в сообщении #366409 писал(а):

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

Это следствие того, что они не знают более удобных и адекватных средств.

bin в сообщении #366409 писал(а):

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

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

bin в сообщении #366409 писал(а):

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

И что же делать, если ошибка конструктивная, а не алгоритмическая? Если неправильно выбранное проектное решение, нарушающее элементарные математические принципы (как это часто бывает с сиплюсплюсо-дельфёвым наследованием классов), ставя рабочую систему под угрозу влияния человеческого фактора?

Maslov · 09/08/09 3438 С.Петербург

Postrelyonysh, Ваше пафосное обличение ООП страдает полным отсутствием аргументации и какой бы то ни было конкретики. ООП, в его традиционном понимании, включает в себя инкапсуляцию, наследование и полиморфизм. Что конкретно вызывает такое негодование с Вашей стороны?