Хороший выбор плохой архитектуры

Источник: embarcadero

Vsevolod Leonov

Познавательная активность

моих друзей-блоггеров стимулирует очередную итерацию в анализе получаемой информации. Евгений Чмель, один из победителей нашего с DelphiFeeds.ru конкурса блогов, в своей "собирательной" статье довольно удачно совместил собственные размышления с достаточно вдумчивой селекцией опубликованных книжных мыслей.

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

Выбор в условиях неопределённости

Психологический портрет хорошего разработчика обязательно будет укомплектован румяным и красивым комплексом неполноценности. Мы сомневаемся в себе уже в момент проклика в Project->New Application. Редкий кусок кода мы готовы признать красивым, эффективным и выше всякой критики. Мы часто страдаем от собственного "дилетантства", "косорукости" и "быдлокодерства". Обычно, чем умнее и опытнее разработчик, тем больше скептицизма он испытывает, глядя на направление развития собственной системы. Давайте немного поизбавляемся от заниженной самооценки.

Основная проблема в разработке архитектуры ПО - неопределённость. Мы не знаем:

степени стабильности бизнес-моделей (где гарантия, что через полгода нас не попросят коренным образом перестроить БД?);
периода сохранения интереса нашего начальства к качеству создаваемой системы (слушай, сделай хоть как-нибудь, лишь бы она работала сейчас, а не через месяц);
запаса прочности собственного энтузиазма (надоело, сделаю тяп-ляп, а потом, когда станет ясно, что нужно реально для пользователей, пересмотрю всё заново).

В условиях неопределённости

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

Перефразируя выжимки из теории игр (которая идёт значительно дальше предсказаний результатов лотереи), относительно архитектуры ПО можно выделить ряд стратегий:

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

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

Если плохая архитектура существует

значит это кому-нибудь нужно. Хочу кратко рассказать случай из моей жизни. Жила-была очень способный разработчик - Елена. Большой опыт, умение делать всё от базы до интерфейса. Создавала систему CRM для компании, где работала более 10 лет. Прошла путь от маленькой базёнки до кроссплатформенного монстра. Работала в одиночку.

Система CRM была краеугольным камнем бизнеса. Сервисная компания могла конкурировать на достаточно плотном рынке только из-за того, что очень быстро адаптировалась к новым условиям, бойко выдумывала различные скидочные программы и качественно мониторила количественные показатели степени удовлетворения клиентов.

Но Елена в какой-то момент передумала быть программистом и решила стать финансистом. То ли сказался развод с мужем, то ли надоело обращение "Леночка, ты почему не доделала ввод данных?", а захотелось пожить в образе "Елена Михайловна, когда у Вас будет время посмотреть документы?". Мозгов-то Лене Абросимовой было не занимать.

Чем кончилось дело

спросите вы? Сначала она захотела уволиться, в чём ей было с удовольствием отказано, т.к. архитектура оказалась настолько запутанной, что банда молодых горячих парней без (уже) Елены Михайловны не могли "вкурить" даже в основные 20 таблиц с 50 хранимыми процедурами. И уже на совещании с привлечением генерального было принято решение перевести Лену в финансистки, попутно оплатив ей корпоративный MBA, лишь бы она на ближайшие 2 года не помышляла об уходе из компании, была доступна для консультаций и могла бы на худой конец пофиксить внезапно всплывший баг.

Как вы понимаете

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

Вот в этой абсолютно реальной истории (а я оставил несколько скрытых совпадений) есть один неявный вывод - господа IT-директора, занимайтесь стратегией!

Перенос VBA-макросов в Delphi (исходники).

Дороги ведут к "Хранилищу". Обсуждение "больных тем" информационных проектов.

Главная » Delphi