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

[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
Конечно, толковую технологию производства софта на голой практике не построишь. Но я и не прошу (пока!) таких деталей.
Всеобщая стандартизация - отдельный вопрос для обсуждения.
Пока хотелось бы услыхать различные мнения о средах и применяемых в них языках. Т.с. - прогноз на большую долговечность.
Я считаю, что начинать обсуждение лучше с низу и не настаивать на абсолютной истине, а там уж можно подниматься выше. Думаю, это не менее поучительно, чем говорить сразу о теории.

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

[Alf]

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

По поводу языков: лично я наблюдаю сильнейшую конвергенцию, выразительность различных языков не только растет, но и сближается. Конечно, более новые языки при этом имеют преимущество, ведь при их разработке учитывались недостатки предшественников. Но и более старые языки тоже не стоят на месте, развиваются, хоть им это и сложнее: давит совместимость с прежними стандартами. И как бы свысока ни смотрели приверженцы, скажем, C++ на коллег, предпочитающих Delphi, и как бы не насмехались над последним Visual Basic'ом, следует признать: сегодня следует говорить в первую очередь не об особенностях конкретного языка, а об особенностях парадигмы объектно-ориентированного программирования. Хорошо ориентирующийся в ООП программист с легкостью овладеет синтаксисом нового для себя языка и начнет писать качественные программы, а вызубривший наизусть Страуструпа и усугубивший это дело чтением стандарта новичок, кое-как ознакомленый лишь со структурным подходом, обречен плодить химер.

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

Я считаю, что систему, рассчитанную на долгий срок эксплуатации и развития, следует строить из достаточно автономных подсистем с хорошо определенными стандартными интерфейсами. В этом случае при необходимости модернизации можно относительно безболезненно заменить черный ящик другим, аналогичным. Сегодня любой смышленный подросток может, например, заменить видеокарту в домашнем компьютере на более мощную или добавить модуль оперативной памяти по этой самой причине - они имеют стандартный интерфейс и являются взаимозаменяемыми. Софт в данном случае не имеет таких уж кардинальных отличий. Например, если мой сервер баз данных MS SQL 2000 оказался слабоват и было принято решение приобрести мощный сервер, скажем, на RISC-процессорах, на которых не поддерживаются продукты MS, это не должно стать такой уж трагедией. На смену старому серверу придет новый, с Oracle поверх Solaris, например. И если я не закладывался на особенности диалекта SQL от MS (читай - следовал стандарту) и при этом обзавелся подходящими драйверами для доступа к данным (ODBC, OLE DB, ADO.NET, ...), переход будет достаточно плавным. конечно, админам придется поднапрячь мозги, но их (админов) для того и держат.

Другой пример - Web-сервер. Клиенту без разницы, находится ли на другом конце провода Apache или же IIS, если на корректный запрос, выданный стандартным браузером через стандартный HTTP, он получает корректный ответ.

Итак, резюме. Я считаю, что не играет столь уж большой роли, в какой операционной системе и тем более на каком языке написан конкретный модуль, при условии, что он обладает прозрачным, хорошо документированным, желательно стандартным интерфейсом и соответствует спецификациям. Пока соблюден интерфейс, с внутренностями можно делать что угодно. Чем лучше продуман интерфейс, тем дольше он имеет шанс прожить в неизменном виде. Вспомните, сколько поколений компьютеров пережили RS-232, Centronix, SCSI или PCI.

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

[Джон]

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

А в тему, скажу. 100% согласен насчёт абсолютной истины - не может быть её, утопия всё это. Можно конечно попытаться привлечь теорию и светлые мысли о коммунистическом будущем, только оно всё-равно не достижимо. Вот две недели назад, сдали бету. В четверг оказался уже "безработным", ну... шеф пришёл. Торжественно отправил в отпуск, сопроводив торжественным двухчасовым крэш-курсом C# - только не 2го на 2005 студии. А первого, тк очередной "мой" проект делается именно на нём. И теперь я C# программист. Во как! За 2 часа. Коллега прикололся, что теперь он всем про это расскажет, на что я ему ответил, что тогда расскажу всем, что он сейчас на VB 6.0 программит. Вот так и живём. Причём на месте C# мог бы оказаться и Pascal, и VB, и PHP, и любой другой язык или платформа. И никто не гарантирует, что через полгода я не заявлю, что всю эту дребедень лучше и НУЖНО делать на С++. И всё начнётся с начала. Поэтому на средах и языках я бы тоже не сосредотачивался.
Другие жизненные наблюдения: нет ничего хуже, чем разбираться в чужом коде (эт я к тому, что для будущих переделок желательно сохранить не только оригинальный код, но и программера, оный код сотворившего); второго "точно такого же как этот" проекта не бывает; если что-то "выучил" впрок - оно тебе никогда не пригодится; если предположить невозможное и уже готовый проект вдруг надо  программировать заново, то всё-равно всё сделаешь всё по другому. Вот, собственно говоря, такая практика. Поэтому, лучше знать об этом и не строить иллюзий, о проектах, которые можно реанимировать малой кровью через 2,3,5 лет. Причём, чем дольше, тем сложней. Отсюда повоторюсь, если проект действительно перспективный  - единственная реальная помощь в будущем - подробное описание всех алгоритмов и решений, история всех изменений и "выкручиваний". Особенно когда проект создаётся в интимной обстановке. К сожалению у буржуинов это не принято, каждый старается быть незаменимым сотрудником, дескать "без меня хрен разберётесь". Поэтому документация чисто формальная. Вот у нас раньше - инструкции были так инструкции, по ней не то, что телевизор настроишь, а ещё и отремонтируешь и новые блоки засунешь, все принципиальные схемы с разводкой печаток были. А у них? Попробуй по инструкции телевизор настроить? Ты что? Этож у специального человечка кусок хлеба с майонезом забрал, уж он добряк и домой к тебе приедет не поленится, и всё тебе настроит, и денюжку с тебя сдерёт. Ну да ладно, это уже вопрос психологии и профессиональной этики. Но сделать это реально. А уж переложить готовые решения на современную платформу - особого труда не составит. Причём документировать надо сразу. По себе знаю, особенно если вещь была простая и долго решения не искал - забывается месяца через 2 напрочь. Потом сам сидишь и думаешь - и нафиг я это так сделал? Мож клиент именно так захотел, а может ничего умней в тот момент не придумал, а может просто на поезд торопился? Про код написанный другим я вообще молчу. Только ручонками помашут. ХОтя в принципе ситуация наверное всем знакомая.
Вот такая вот реальность "с низу". Какую уж тут теорию можно надстроить - не знаю. ИМХО - никакую. Если бы всё было так просто, давно уже были бы программы-роботы, которые бы сами программировали, и нам было бы нечего делать.

Насчёт сред и языков - я лучше высказываться не буду. Причина простая - ИМХО это только запутает, тк ну кто в этом мире знает, что такое добро и что такое зло? Уж сколько бедная несчастная MFC библиотека существует, а практически все воспринимают её как нечто самостоятельное - "вот API это - да, весчь, а MFC - это гавно", хотя это по сути API и MFC практически одно и то же. И если уж о таких "древних" тривиальных вещах очень скудные познания, то что тогда говорить о "новинках" типа .NET-платформы? Я думаю тебя не устроят цитаты познавательно-популярных брошюрок рекламного ведомства дяди Билла. И ведь никто не гарантирует, что через пяток лет, они не откажутся от неё, как отказались в своё время от такой классной, маленькой, удобной WTL. Да просто посмотреть на разницу в возрасте между версией 1.1 и 2.0 и их совместимость. А ведь сколько торопыг уже наделали софта под 1.1 Так что лучше сохранять на будущее - идею, а её реализация дело второстепенное.

[Dimka]

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

Боясь попасть пальцем в небо, такого глобального прогноза не дам - всё течёт, всё меняется.

Однако полагаю, учитывая объёмы уже написанного и нежелание его переписывать, что Java для корпоративных информационных систем - это надолго, отчасти сродни некогда популярным COBOL и FORTRAN.

C/С++ будут жить, но их проблема для данной задачи в том, что, несмотря на живучесть языка, библиотеки и технологии под них меняются стремительно, а устойчивых, повсеместно используемых, стандартизованных библиотек для работы с БД и GUI для этих языков нет.

Я считаю, что начинать обсуждение лучше с низу и не настаивать на абсолютной истине, а там уж можно подниматься выше.

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

[Dimka]

Вот у нас раньше - инструкции были так инструкции, по ней не то, что телевизор настроишь, а ещё и отремонтируешь и новые блоки засунешь, все принципиальные схемы с разводкой печаток были. А у них?

Сломался - купи новый. Коммерция, общество потребления. К софту, кстати, тоже относится.

[Джон]

dimka, умом я это понимаю. Так и должно быть. Но вот с душой проблемки.

[Dimka]

dimka, умом я это понимаю. Так и должно быть.

А почему "должно быть"? Это вариант счастья по Генри Форду - вот тебе гайка, чтоб ты её закручивал, и зарплата за это дело - будь счастлив!

Но вот с душой проблемки.

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

[Dimka]

Вот, попалось сегодня:

http://www.cnews.ru/reviews/articles/index.shtml?2006/07/21/206386

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

[Dimka]

Ну и там рядом другая статейка отчасти в тему:
http://www.cnews.ru/reviews/articles/index.shtml?2006/07/19/206273

[Alf]

Попалась на глаза книга Стива МакКоннелла "Совершенный код" ("Code Complete"). Книга вышла год назад, но каким-то образом прошла мимо меня незамеченной. На мой взгляд, весьма правильная книга о том, как правильно писать правильный код. Пока прочитал немного больше сотни страниц, не разочарован. Да и рекомендации правильных парней, таких как Мартин Фаулер, Джон Бентли, Джон Роббинс, Майкл Ховард, Гради Буч и Кеннет Розен (рекомендателей больше, но фамилии остальных мне, увы, незнакомы) дорого стоят. Если кто-то вообще способен писать правильный софт, то они в их числе в первую очередь.

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

[zubr]

С практической точки зрения, имхо, лучше всего разбить задачу на несколько подзадач. Каждую подзадачу выполнить в виде отдельной dll или ActivX-компонента, все это достаточно подробно документировать (подзадачи и сборку). В дальнейшем, возможно, это позволит переписывать не целиком программу, а ее отдельые модули. А при разработке програмы предусмотреть все на 5 лет вперед невозможно, имхо.

[Dimka]

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

В книжке Эдварда Йордона и Карла Аргилы "Структурные модели в объектно-ориентированном анализе и проектировании" приведён один показательный пример... даже процитирую:

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

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

Мораль сей басни такова, что ушлый, скажем, в ActiveX программист может создать прекрасный (с технической точки зрения) дизайн системы, разбить её на легко заменяемые компоненты и т.д. Но все эти прелести его никак не спасут от ошибок логической модели. Если логическая модель не очень удачна, то сопровождение такой информационной системы при любой самой качественной её технической реализации превратится в ад.

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