Дефрагментация мозга. Софтостроение изнутри

Книга эта - очерки и полевые записки айтишника. Его точка зрения на сложившиееся мироустройство, маленькие заметки о практике и байки из жизни. Если понравился Джоэль Спольски и его книги - блоги, то эта тоже понравится.

Судя по книге, автор обладает опытом разработки программ под Windows. Насколько я могу судить, это в основном корпоративные приложения с использованием Microsoft SQL Server, написанные на Delphi, Java и C#. Приятно, что автор знаком с историей отечественных информационных технологий и во многих случаях вместо западной терминологии использует исторически возникшую раньше отечественную технологию. Например, вместо понятия ЦОД - Центр обработки данных, автор предпочитает наше понятие ВЦКП - Вычислительный центр коллективного пользования, которое, пожалуй, даже лучше отражает суть.

В целом книга представляет собой сборник статей на разные темы. Однако, если попытаться изложить лейтмотив этих статей, то получится примерно следующее. В настоящее время отрасль информационных технологий состоит примерно на 10% из собственно разработки и примерно на 90% из сферы услуг, связанной с установкой, развёртыванием, обслуживанием и сопровождением информационных систем. Автоматизация процессов учёта и прогнозирования позволяет крупным компаниям сокращать офисных работников, которые до автоматизации занимались обслуживанием этих процессов. Бывшие офисные работники переквалифицируются в программистов и, как правило, получают рабочие места в тех 90% отрасли, которые заняты в сфере услуг. Таким образом, в сфере информационных технологий появляется большое количество работников с низкой квалификацией. Для того, чтобы получать от этих работников более-менее стабильный результат, компании используют разнообразные технологии, снижающие планку требований к работникам: это в первую очередь сборка мусора вместо ручного управления памятью, разнообразные ORM вместо SQL, веб-приложения вместо компонентных распределённых приложений, гибкие и экстремальные методологии разработки вместо проектирования. Ставка делается на то, чтобы разрабатывать большие и сложные системы путём грубой силы. Цикл разработки при этом растягивается, код систем разбухает от большого количества промежуточных слоёв, работа программ замедляется за счёт уменьшения локальности обработки данных - данные обрабатываются всё дальше от того места, где они хранятся.

Далее кратко расскажу о наиболее запомнившихся статьях.

В статье "Круговорот" на стр. 20-23 делается интересное наблюдение о том, как автоматизация вымывает сотрудников компаний из офисной работы и отделов АСУ компаний в IT-компании в качестве низкоквалифицированной рабочей силы.

В статье "Изгибы судьбы при поиске работы" на стр. 31-34 автор занимается самолюбованием, пытаясь продемонстрировать читателю не только свою востребованность на рынке труда, но и умение находить высокооплачиваемую работу окольными путями и пиратскими тропами.

В статье "Эволюция аппаратуры и скорость разработки" на стр. 40-43 автор делится любопытным наблюдением: несмотря на прогресс в вычислительной мощности компьютеров, развитие языков программирования и прочих инструментов разработки, скорость работы программ не растёт, а скорость их разработки со временем даже снижается. Повсеместное насаждение ООП вымывает из отрасли женщин, которые неплохо справлялись с написанием связующего кода в чисто процедурном стиле, но не смогли вписаться в объектно-ориентированную парадигму.

На стр. 44-54 в статьях "О карманных монстрах", "ASP.NET и браузеры", "Апплеты, Flash и Silverlight" автор раскрывает ещё несколько причин тенденции, описанной в главе "Эволюция аппаратуры и скорость разработки". Если раньше интерфейс программы можно было редактировать в визуальном редакторе, а бизнес-логику поместить в хранимые процедуры в базе данных, то сейчас повсеместное распространение получила веб-разработка с трёхзвенной структурой приложений, при которой интерфейс формируется путём ручного кодирования, а бизнес-логика помещается на сервер приложений, который по совместительству выполняет функции посредника между интерфейсом и базой данных, выполняя необходимые преобразования данных из одного представления в другое. Веб не ориентирован на хранение состояния клиента внутри сессии в оперативной памяти, из-за чего большинство веб-приложений всё состояние между отдельными запросами сохраняет в базу данных или передаёт на сторону клиента в виде большого файла-куки, а перед обработкой очередного запроса вновь восстанавливает.

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

В статье "UML и птолемеевские системы" на стр. 135-140 ставится под сомнение ценность UML, т.к. он:
1. не универсальный, а унифицированный, т.к. объединяет несколько разных подходов разных авторов к графическому изображению логики программ,
2. не язык, а графическая нотация,
3. не моделирования, т.к. не позволяет собственно моделировать и верифицировать модель.

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

В статье "Приключения с TFS" на стр. 166-170 рассказана, на мой взгляд, классическая история про развёртывание коммерческого ПО под Windows, когда для удачного развёртывания необходимо соблюсти ряд неочевидных условий и побороться со встроенными в каждую программу средствами автоматизации развёртывания, облегчающими установку программы в типовых случаях, но превращающих задачу в многоэтапный квест в случаях нетиповых.

В статье "Лампа, полная джиннов" на стр. 174-194 рассказывается о двустороннем генераторе кода проекта. Мне эта автоматизация показалась прекрасной иллюстрацией недостаточной гибкости полукомпилируемых языков типа Java или C#. Мне по работе приходится больше всего писать на Python и использовать веб-фреймворк Django. Из моделей Django с минимальными усилиями можно получить готовые веб-формы и административный интерфейс, не прибегая к помощи каких-либо генераторов кода.

Мне приходилось сталкиваться с программированием для Windows лишь в самом начале карьеры. Я писал небольшую программу на Visual Basic для создания трёхмерных моделей зуборезных долбяков (это такой инструмент для изготовления зубчатых колёс или шлицов эвольвентной формы) в SolidWorks. Сейчас я пишу программы в основном на языке Python и иногда использую веб-фреймворк Django. Работа моя непосредственно не связана с программированием, но за мной часто остаётся выбор, каким образом выполнить ту или иную задачу. Если это бывает возможно, то я стремлюсь не делать одноразовой работы, а стараюсь вписывать каждое решение в общую систему, разработкой которой и занимаюсь для автоматизации своей работы. Несмотря на то, что мой опыт работы довольно сильно отличается от опыта автора, большая часть мыслей автора мне хорошо понятна и близка.

Так, я не стремлюсь в веб-разработку, потому что после разработки в Visual Basic или в Delphi нынешняя разработка веб-приложений кажется мне чрезмерно усложнённым способом решения задач. Большую ценность для меня представляет непосредственно сама решённая задача, а получившаяся программа является приятным дополнением. Я рассчитываю, что при необходимости смогу легко переписать программу и не особо дорожу исходниками. Когда я смотрю на современную веб-разработку, то мне кажется, что разного рода фреймворки, движки и библиотеки становятся какой-то самоцелью. Люди, надо полагать с удовольствием, корпят над большим количеством кода, который по сути не делает ничего. При этом код приобретает для них самостоятельную ценность.

Я примерно так же как и автор с некоторым пренебрежением отношусь к UML, ООП, ORM и веб-разработке, хотя и пользуюсь ими. Я рисую прямоугольники на клочке бумаги, когда нужно спроектировать структуру таблиц под какую-то задачу. Я не брезгую сделать класс для того, чтобы поместить в него общие данные нескольких десятков функций - ведь эти функции и так имеют общие используемые данные, так зачем использовать процедурный подход, пытаясь скрыть это? Пользуюсь веб-фреймворком Django и его ORM для того, чтобы как можно меньше программировать веб-интерфейсы и как можно чаще пользоваться готовым административным интерфейсом, встроенным в Django. Мне легче написать SQL-запрос, чем запрос с использованием ORM, но я не вижу смысла писать много SQL-запросов и прочего кода, лишь для того, чтобы сделать простейший CRUD. В то же время, я хорошо понимаю, что на ORM бывает нелегко, а то и вовсе невозможно написать эффективный аналитический запрос, который легко пишется на SQL.

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

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

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

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

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