Рецензии на книгу «Дефрагментация мозга. Софтостроение изнутри» Сергей Тарасов
Книга эта - очерки и полевые записки айтишника. Его точка зрения на сложившиееся мироустройство, маленькие заметки о практике и байки из жизни. Если понравился Джоэль Спольски и его книги - блоги, то эта тоже понравится.
Спасибо за отзывы и ваше читательское терпение.
Из введения к моей новой книге "СУБД для программиста. Базы данных изнутри": Книга «Софтостроение изнутри» посвятила немалое количество сюжетов теме «как это не надо делать» и прогрессирующей в среде программистов некомпетентности в области баз данных, приводящей к катастрофическим для проектов последствиям на более поздних стадиях. В отличие от предтечи, настоящее издание будет носить ровно противоположный характер, следуя принципу «как это лучше сделать». Опираясь на опыт работы в продуктовом софтостроении и в технической экспертизе СУБД‑решений, автор постарается в рамках повествования помочь вам не утонуть в информационном потоке и разобраться в часто возникающих на практике проблемах, не отрывая их от теории.
Анонс книги "СУБД для программиста. Базы данных изнутри"
Судя по книге, автор обладает опытом разработки программ под 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.
Я, как и автор, считаю наследование реализаций в ООП довольно сомнительным решением и не испытываю восторга от шаблонов проектирования. Можно ознакомиться с шаблонами, почерпнуть для себя что-то полезное, но маниакально выстраивать систему с использованием "идеологически верных" решений я бы не стал.
Наконец, у меня, как и у автора, противоречивое отношение к гибкой методологии разработки. С одной стороны, проектированием нельзя заниматься вечно - нужно остановиться на достаточно хорошем решении, чтобы начать двигаться к цели, а не пытаться выстроить башню из слоновой кости шаблонов проектирования. С другой стороны, гибкую методологию разработки часто используют как фиговый листок для прикрытия отсутствия навыков проектирования. Постоянно сменяющие друг друга спринты не дают остановиться и подумать о том, что ты делаешь, переосмыслить подходы и улучшить архитектуру. Зато исполнитель может отчитаться об имитации бурной деятельности: количество закрытых задач в менеджере управления задачами и фиксаций в системе контроля версий неизменно растут.
Источник