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

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

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