«Дефрагментация мозга. Софтостроение изнутри» kitabının incelemeleri

"Я старый солдат, и я не знаю слов любви", – как бы говорит нам автор, желая вернуться в славное время формошлёпства на Delphi, и отрицая существование больших распределённых систем. Книга полна ностальгии по ушедшим временам и брюзжания, что «в наше время трава была зеленее и специалисты специалистнее».

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

При прочтении книги, у меня в мыслях возник образ автора как умудренного жизнью программиста, разочаровавшегося в своей «бессмысленной» профессии и мире разработки программного обеспечения. Он не скрывает прозу жизни – технологии развиваются не туда и не так, в отрасли работают случайные люди, менеджеры ничего не понимают в технических деталях и занимаются только одним – разделом бюджета. Экзистенциальные мучения души программиста-поэта периодически уносят читателя в мир мечты, где истинные инженеры-программисты трудятся над кратким, понятным и красивым кодом… Правда, возвращаясь из этого мира, писатель замечает, что в этом мире, к сожалению, нам с вами не жить. И чем дальше – тем хуже. Хорошее программирование закончилось лет эдак 15-20 назад.

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

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

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

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

Книга поможет сделать взвешенный выбор профессии для огромного пласта вчерашних школьников: от тех, кто с наивной радостью видит свой первый «Hello World!», до тех, кто считает себя гуру софтостроения, накручивая из готовых элементов конструкции, тормозящие на чем-то слабее машин последнего поколения.

Судя по книге, автор обладает опытом разработки программ под 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.

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

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

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