Проблемы поддержки софта или как его правильно писать.

[RXL]

Сначала немного лирики...
Сейчас у меня на работе сложилась следующая ситуация.
Существует софт, созданный и поддерживаемой заграничной конторой. Временами они правят баги, делают новые версии и присылают нам. Софт серьезно врос в работу Компании и заменить его пока нечем.
Конечно, заграничные программеры не могут знать всех наших нужд и местные программисты временами делали удобные программки, работающие непосредственно с базой заграничного софта. N лет назад пару дельфистов-бильдеристов нарисовали несколько программ для автоматизации работы в Компании. Эти программы с годами мало менялись. Люди привыкли ими пользоваться и на текущий момент эти программы то же очень нужны.
Вот наступил момент, когда заграничные товариши решили, что кровь из носа перейти на VB.NET, а так же изметить требования к программному окружению софта. Т.к. самописные программки то же были привязаны к этому окружению, то вполне естественно, что часть из них перестала работать. И мне, как и моим предшественикам, прилось взяться за пересборку софта с более свежими компонентами.
Вот тут и начались проблемы... Какие-то компоненты уже давно не поддерживаются и имеющиеся версии собираются только на старых версиях компилятора. Какие-то еще существуют, но требуют более нового компилятора. И всякая прочая неприятная фигня.
Первой мыслью было частично переписать программы, повыкидывав из них неподдерживаемые компоненты. Только на это нужно время, а его не много, да и кроме этих программ обязаностей не мало. Я то конечно выкручусь - деваться просто некуда, но сама ситуация очень неприятна.
И вот во время очередного перекура в голову пришел вопрос: а как нужно писать программы, чтоб через 2-3-5 и более лет не пришлось их переписывать почти с нуля?

[Алексей++]

Ром, у меня похожая фигня - только программой пользовались около 7 лет, а потом я с нуля переписал - и поддерживаю свою прогу уже год.  Это учитывая, что охранный алгоритм - не изменился за все 8 лет А теперь намечается очередная версия.
Короче - переписывать всё равно придётся когда-нибудь

[Chuda]

во всём виноват некрософт

[Finch]

во всём виноват некрософт

Зачем так категорично. Иногда кривые ручки программистов помогают.

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

[Alf]

Возможно, буду неоригинален, поскольку в технологической теме подобные вопросы уже поднимались, и они достаточно близки мне по роду деятельности. Правда, там дискуссия сама собой заглохла, поскольку у нас почему-то к любому вопросу, на который нельзя ответить однозначно цитатой из MSDN или стандарта ANSI C++, очень быстро теряется интерес. Итак, как бы я ответил на столь каверзный вопрос.

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

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

Следует использовать только стандартные промышленные интерфейсы везде, где это возможно. Есть стандартная железка, годящаяся для твоей задачи, - отбрасывай в сторону паяльник и бери готовое решение. Есть подходящий формат хранения данных, протокол передачи их по сети, интерфейс межмодульного взаимодействия и т.д. - используй, если к этому нет весомых противопоказаний. Если помните, у нас тут была попытка совместного проекта, имеющего некоторое отношение к взаимодействию с аппаратурой. К моему удивлению, первым же делом встал вопрос о разработке своего собственного интерфейса для подключения дополнительных модулей, как будто в природе нет ActiveX, COM, CORBA, RMI... Я бы не упомянул об этом, не будь это обычной практикой.

Да, у стандартных решений есть свои слабые стороны. Но эти стороны тщательно изучены тысячами и миллионами пользователей и хорошо известны, а многим ли лучше получится придуманный за пару часов самопал? Кроме того, стандартные решения великолепно документированы, снабжены инструментарием для реализации в коде и отладки. Любой толковый программист в состоянии разобраться, например, в работе механизма ActiveX и при помощи соответствующего SDK сделать плагин к программе, если возникла возможность расширить ее функциональность.

Использование хорошо документированных интерфейсов и протоколов при максимально возможном следовании стандартам позволяет рассматривать каждый компонент системы как черный ящик и достаточно безболезненно заменять их при необходимости (или добавлять новые). Например, если приложение расширяется подключением ActiveX компонентов, взаимодействует с другими узлами сети посредством TCP (UDP, HTTP, ...), способно осуществлять экспорт/импорт данных в XML, обменивается объектами через SOAP и хранит данные в реляционных базах, доступ к которым осуществляет стандартным подмножеством SQL без особых выкрутасов, - такому приложению я бы не побоялся предрекать долгую и счастливую жизнь.

И последнее IMHO - не позволять софту стариться морально, обновлять по возможности, не утешая себя тем, что пока работает - и ладно. Например, не так давно я отправил в архив последнее задействованное в моей системе приложение, написанное на VC++ 6.0/MFC. Хотя оно и выполняло свои функции, но приводить его в соответствие с меняющимися требованиями было все труднее, и я наконец-то решился переписать его заново на C#. Технологии 90-х годов славно послужили нам в свое время, но им пора на честно заслуженный отдых. Тем более что следование принципу обновления системы по частям, один черный ящик за другим облегчают такое эволюционирование, без резкого скачка, с которым пришлось столкнуться RXL.

[Alf]

во всём виноват некрософт

Вот как? Интересненько. А можно немного поподробнее?

[Chuda]

мда... MFC... C#... а например с Qt всё гораздо проще.

[Алексей++]

Chuda,   поверь, с MFC всё достаточно просто. Иногда - слишком...
В то же время - нет ограничений, просто иногда сина поднапрячься

[Alf]

Гениально. Исчерпывающий и обоснованный ответ. А главное - полностью отвечает на исходный вопрос: как писать софт, чтобы потом не было мучительно больно.

[Chuda]

> как писать софт, чтобы потом не было мучительно больно.

а это можно вот так просто решить в теме форума?

[Alf]

Даже нужно. Для этого специально обученный раздел выделен.

[Dimka]

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

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

P.S. А давайте тему перенесём в соответствующий раздел.

P.S. Эх, зря вы ЛЕСа в Кунсткамеру отправили.

[RXL]

Вот как раз использование "нестандартных" решений мне и не понравилось.
В условиях Delphi и C++Builder это особенно остро, т.к. программисты этих сред почему-то любят использовать сторонние компоненты, без которых вполне можно было бы обойтись. Я прежде всего о компонентах "улучшения внешнего вида" GUI. Легкость создания интерфейса в этих средах частенько приводит к кучи багов и фич.

Если коснуться MS, то они свою лепту в кашу несовместимости вносят постоянно. Сколько уже интерфейсов они напридумывали... И накой нам их .NET? Только из-за того, что разработчик перешел на среду VS.NET потребителю нужно обновить кучу окружения? В результате ведь все равно создается exe-файл!

Qt - это здорово (кроссплатформеность, абстрагирование от ОС, обширный сервис), но и тут не все гладко - от версии к версии меняется значительно. Chuda, попробуй, в порядке эксперимента, собрать какую-нибудь программу, написанную под старые версии Qt. Думаю, проблемы будут.

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

Alf, про твой раздел мы, конечно же, помним. Только вот специфика небольшая - разработка программ непрофессиональными разработчиками. Т.е. про "грамотное ТЗ" лучше сразу забыть - точно, что и как должно работать, никто в конторе не скажет. Про тестирование - то же. Все тестирование - своими руками, а потом правка по мере поступления жалоб.

[Alf]

Вот как раз использование "нестандартных" решений мне и не понравилось.
В условиях Delphi и C++Builder это особенно остро...

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

Если коснуться MS, то они свою лепту в кашу несовместимости вносят постоянно. Сколько уже интерфейсов они напридумывали...

Я бы не был столь категоричен. Если интерфейсы придумывают - значит, это кому-нибудь нужно?.. Тем более что не одни они этим грешат. Возьми тот же Intel и спроси: зачем они меняют свои интерфейсы? Был ведь весьма добротный продукт 8086 в 40-выводном корпусе, и делали бы все совместимым с ним. Не пришлось бы нам каждые 2-3 года при апгрейде процессора отправлять на помойку материнские платы, а вместе с ними и кучу сопутствующего барахла.

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

И накой нам их .NET?

Ответ на этот вопрос весьма сильно зависит от того, кто такие эти самые "мы". Ваша группа? Фирма? Прогрессивное человечество в целом? Каждый находит свой ответ, "накой".

С таким же успехом программист 1С спросит, накой ему С++, если бухгалтерия и так отлично считается. Тот же вопрос задаст сторонник FoxPro, ему этот замороченный язык тоже ни к чему. А дедушке из лесу так и вовсе не нужно ничего, кроме DOS'а, древней версии Pascal'я и мыши с одним пальцем. Я предпочитаю терпимость в этом вопросе. Если человек в совершенстве пишет на COBOL'е, пусть себе творит. Ты вправе покупать его продукты или выбирать другие, но стоит ли заставлять его плясать под свою дудку, даже если она кажется единственно правильной? Жизнь сама рассудит.

В результате ведь все равно создается exe-файл!

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

Только вот специфика небольшая - разработка программ непрофессиональными разработчиками.

А эту специфику замечательно отразил баснописец Крылов:

Беда, коль пироги начнет печи сапожник,
А сапоги тачать пирожник:
И дело не пойдет на лад,
Да и примечено стократ,
Что кто за ремесло чужое браться любит,
Тот завсегда других упрямей и вздорней;
Он лучше дело все погубит
И рад скорей
Посмешищем стать света,
Чем у честных и знающих людей
Спросить иль выслушать разумного совета.

Мне тут и добавить нечего, все сказано.

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

[Dimka]

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

Теоретически хорошо, но практически RXL "надо бы программку", а не курсы по "профессионализации" разработчиков.

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

[Alf]

Теоретически хорошо, но практически RXL "надо бы программку", а не курсы по "профессионализации" разработчиков.

Обратимся к первоисточнику:

И вот во время очередного перекура в голову пришел вопрос: а как нужно писать программы, чтоб через 2-3-5 и более лет не пришлось их переписывать почти с нуля?

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

[Dimka]

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

Согласен. Но меж тем:

Обратимся к первоисточнику:

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

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

А по поводу вопроса RXL - сам эти вопросом уже 1,5 года озабочен. Есть кое-какие соображения, но их надо обдумать, сформулировать, опробовать - и т.д.

[Chuda]

dimka, +1.
Постоянно с таким сталкиваюсь. Лучше десять раз переделают, чем один раз сделать нормально

[Dimka]

Итого 2 вопроса:

1) Как писать устойчивые к изменяющимся требованиям окружающей среды программы (назовём это "живучестью программного обеспечения").

2) Что делать, если вдруг обнаружилась необходимость всё переписать, а времени и средств нет. Стратегии поведения в этой ситуации.

P.S. И выражаю благодарность "дедушке из леса" за поднятие темы, как бы тут ни тошнило остальных от этого "дедушки".

[x77]

И вот во время очередного перекура в голову пришел вопрос: а как нужно писать программы, чтоб через 2-3-5 и более лет не пришлось их переписывать почти с нуля?

Рома, дело не только в вопросе "как" (на который, по сути, уже ответил Альф), но и в вопросе "на чём". от выбора среды и ОС зависит очень и очень многое именно в плане дальнейшей поддержки in a long run.

[Alf]

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

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

[Dimka]

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

О! Можно хотя бы основные перечислить?

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

[Alf]

Непосредственно

О! Можно хотя бы основные перечислить?

Непосредственно относящиеся к вопросу - книги по экстремальному программированию, гибким технологиям и т.п. Например, цитата из Бека:

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

IMHO прямо в тему.

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

[Dimka]

Alf, возможно Бек и полагает, что XP решит все проблемы, однако по методике XP:

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

А теперь сопоставь это с требованием несколько лет сопровождать продукт, когда:

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

В результате ответа на вопрос RXL нет.

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

[RXL]

Вот Игорь как раз выразил интересную мысль - не только как, но и на чем. Скажем, для минимальной поддержки не обязательно нужно знать всю технологию производства. Достаточно минимального набора: чем скомпилить, какие библиотеки нужно подложить и т.п. простые вопросы.
Разве разработчику не нужно думать о том, как сделать так, чтобы с его программой потом сильно не мучились?

[Alf]

Alf, возможно Бек и полагает, что XP решит все проблемы, однако по методике XP:

- Вся команда разработки должна быть "в курсе" того, что разрабатывается (любой программист может выполнять любую тематическую задачу в проекте),

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

- Отсутствие документации - всё "очевидно" из самого кода программы.

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

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

IMHO вполне разумно, если заменить "нужно в данный момент" на "оговорено в требованиях".

- Принцип разработки по пути "наименьшего сопротивления" (что прошло тесты, то считается правильно реализованным)

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

В результате ответа на вопрос RXL нет.

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

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

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

[Джон]

Ром, немного с опозданием - добро пожаловать в клуб. Я такими делами даааавно занимаюсь. Самая "крутая" вещь  была - переделка проги из ДОС под винду. Во как. Дык они ещё хотели, чтобы скорость была как под ДОС. То, что ты из под винды напрямую с аппаратными прерываниями работать не можешь им и не в домёк было. Оказывается свои дрова надо писать, а не просто красивую графическую оболочку сварганить. И почему-то вывод инфы о переданных паре мегабайт (всего-навсего) на 90м пентюхе занимает времени раз в 20 больше, чем под доброй старой ДОС (в текстовом режиме).
Ну, а потом можно так же рассуждать и о новых технологиях типа .NET под NT4. И только не надо клиенту говорить, что NT4 это позавчерашний день, что она уже не поддерживается МС, тк у него в лаборатории 500 машин стоит и исправно в течении 10 лет исправно отправляет сигналы через СОМ порт к принтеру и обратно.
Так что...

как нужно писать программы, чтоб через 2-3-5 и более лет не пришлось их переписывать почти с нуля?

ИМХО - никак. Повезёт не будешь начинать с нуля, но в самом общем случае лучше сразу настроится на худшее. Хотя конечно глупо называть это худшим - хлебушек это наш, тем и кормимся. А всё остальное - утопия, нууу разве что у кого-то есть машинка времени. Единственное, что могу посоветовать - оооочень хорошо и подробно документировать алгоритмы (их можно перенести на любую платформу) и найденные решения, особенно внимательно относится к тн workaround. А вот непосредственный код... Частенько приходится применять одно из правил экстремального программирования - выброси всё и начни сначала, много времени сэкономишь.

во всём виноват некрософт

"Ууууу ты какая." (с)

[Джон]

зы Если честно - ИМХО тема про ХР - это не сюда. Заведём новую, или здесь продолжим?

[Dimka]

ИМХО - никак. Повезёт не будешь начинать с нуля, но в самом общем случае лучше сразу настроится на худшее.

2ALL: можно считать это исходным пунктом для размышлений - моделей и методов, решающих эту задачу, пока нет?

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

"Устойчивость" должна быть понятием не качественным, а количественным, имеющим меру, возможность сравнения альтернатив. Смысл "устойчивости" заключается в том, что модификация/адаптация к новым требованиям более устойчивых к новым требованиям программных систем "дешевле" (перечислить, по какому ряду параметров), чем модификация/адаптация менее устойчивых программных систем.

P.S. А тему надо перенести.

[RXL]

Хм. Давайте решим, в какую сторону идет беседа - в идеалистическую (как действительно нужно писать софт), или более приземненно. Первую ветку я поддержать не могу - я не проф.программист и не раз б этом заявлял. Меня больше интересует практическая сторона: https://forum.shelek.ru/index.php/topic,9251.msg134462.html#msg134462
Конечно, толковую технологию производства софта на голой практике не построишь. Но я и не прошу (пока!) таких деталей.
Всеобщая стандартизация - отдельный вопрос для обсуждения.
Пока хотелось бы услыхать различные мнения о средах и применяемых в них языках. Т.с. - прогноз на большую долговечность.
Я считаю, что начинать обсуждение лучше с низу и не настаивать на абсолютной истине, а там уж можно подниматься выше. Думаю, это не менее поучительно, чем говорить сразу о теории.

Если кто считает тему достойной находиться в "технолгиях программирования" - переносите.