Arbinada.com

Когда провожу ревизию программного кода, всякий раз вспоминаю эпизод из "Осеннего марафона". Бузыкин сидит у Варвары, помогая ей с переводом. Время - половина первого ночи. Происходит примерно такой диалог.
- Скажи, Бузыкин, может я бездарная?
- Неее...
- Но ты же всё повычеркивал!
- Не всё... Но вот это, например, я не мог оставить: "Коза кричала нечеловеческим голосом"

И еще пару вестей из полей...

Давненько я не брал в руки шашек, посему пришла пора написать немного текста на тему практического софтостроения, немного затронув «любимую» тему наживульки (agile).

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

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

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

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

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

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

Сценарий, требующий десяток-другой строк кода для обычного оконного клиента, оборачивается сотнями строк спагетти из HTML, Javascript и Code behind. Событийная модель на порядок беднее не то чтобы VCL/WinForms, а даже FoxPro 2.0 для DOS образца 1992 года. 5 клиентских событий у PageRequestManager, из которых 4 отрабатывают только при асинхронном вызове, оказываются пределом мечтаний.

Существующая подсистема пользовательского интерфейса у клиента из трех-четырех десятков экранных форм реализована примерно сотней тысяч строк, при том, что создатели четко отделили слой представлений от бизнес-логики, а общие элементы выделены в controls разного уровня: от custom до композитных user...

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

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

При разработке пользовательских интерфейсов периодически требуется к элементу управления (control) типа списка/выпадающего списка (ListBox, DropDownList) пристыковать (data bind) коллекцию (список) объектов в качестве источника данных. Дружественный интерфейс предполагает, что данные в списке отсортированы. Но если в списке имеются повторяющиеся значения, то использование стандартных классов типа SortedList или Dictionary становится невозможным.

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

С.Н. Дмитренко, 8 апреля 1993 г.
Из предисловия к переводу книги Leo Brodie "Thinking FORTH. A Language and Philosophy for Solving Problems"

В статье рассказывается о применении технологии модульных тестов при разработке приложений на SQL и его процедурных расширениях.

Так называемое "индустриальное" программирование, культивируемое мегакопорациями, плавно съехало с методик "как надо, чтобы получить результат" к так называемым "антипаттернам", то есть к объяснению того "как НЕ надо". Собственно говоря, такой переход сам по себе является провалом, хотя и не самой идеи индустриализации софтостроения, но методов ее проведения.

Вот на пороге стоит C# .NET версии 4.0. А основная промышленная версия у разработчиков по-прежнему 2.0. Куда же дели 3.0 и 3.5 (пламенный привет и почетная грамота от корпорации добра всем зубрившим матчасть 3.х)? Да просто слили в помойку. Тем самым подтвердив, что это были не самостоятельные версии, а переходные внутренние релизы, которые вместе с 2008 студией выпустили на широкий рынок с единственной целью подсобрать деньжат на пропитание. Это напрямую подтверждается отсутствием сертификаций и учебных курсов (то есть книг на тему "как надо") для нее.

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

Поиск "антипаттернов" - задача исследовательская. Но со знаком "минус". Это поиск отрицаний. На нем не построишь фреймворков. Но эта работа востребована тем больше, чем чаще мелькают версии сырых релизов. И тем больше в сети профилей со значком MVP (Most Visible Professional)

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

Вывел следующую формулировку по поводу языка С++ на базе относительно старого текста: "Достоинством является правило "если ты пишешь на С++, то априори ты не ламер". На самом деле это новая версия старого правила "настоящие программисты пишут на Си".

Оговорюсь сразу, целью очередной заметки серии не является "очернение светлого образа" сборщика мусора (GC - garbage collector) в средах программирования с автоматическим управлением памятью.