Первый пример. Без малого 10 лет назад под большой проект писал я ПО. В одиночку, быстрыми темпами. Потом еще несколько лет были мелкие доделки, версия программ доросла до 3.5. И, в общем, все- работало годами без переделок. Я уже уволился оттуда лет пять назад, но, общаясь со знакомыми, периодически интересовался судьбой своих программ. Новые программисты, молодые и горячие, приходили, "махали шашкой": "Кто писал ЭТО?! Да мы сейчас за три дня перепишем..." И далее звучал список самых последних крутых технологий программирования, с помощью которых собирались переписать. Я спрашивал, а что не устраивает? В основном, только то, что использовалась БД Interbase, а не MS SQL Server, что доступ к базе был через специализированные компоненты доступа, а не через ADO, что пользовательский интерфейс был построен на базе стандартных компонент, а не на DevExpress. Когда молодые программисты брезгливо морщили носики от всего этого "старья", то они не учитывали время, когда это все писалось. В конце девяностых MS SQL Server был совсем другим- его Microsoft только купила у Sybase и по функционалу и производительности тот же Interbase делал его как сосунка, DevExpress просто не существовало и т.д. Функциональность устраивала, код не был "лапшой" (все примитивно- обычное накидывание компонент на форму и простая логикой). Реально, желание переписать ПО было не более, чем амбицией молодых перспективных специалистов (см. п. 2 исходной статьи). Я тогда еще, пару лет назад сказал, что ничего из этого не выйдет- там не то, что 3 дня, там реально минимум на год было работы, а с учетом того, что надо было, помимо переписывания, еще и текущую работу выполнять, то и все 3 года занял бы процесс переписывания. Да и смысла не было в этом совсем.
Итак, взмахнув лихо шашками, начали процесс переписывания. Прошло более 3 лет. За это время удалось переписать только несколько вспомогательных утилиток и процесс умер, сошел "на нет" сам собой.
А мое ПО уже десятый год, без существенных модификаций, продолжает работает. С одной стороны приятно, и я испытываю гордость за созданное мною ПО, но с другой-сколько ж ему, горемычному, еще пахать? Давно пора б заменить другим, более современных ПО, уже все разумные сроки эксплуатации вышли. Представьте себе БД, с которой молодые специалисты не хотят связываться из-за брезгливости, работает в автономном режиме уже десяток лет! На время моего ухода там уже было 1,5 млн. записей, а теперь и все 5 млн. будет- ее же никто не чистит, не обслуживает... а только ухудшает.
Да, да, ухудшает. Новые программисты делаеют свои дописки, лоскутами пытаются что-то переписать на своему разумению, налепили сбоку своих компонент, которые им больше нравятся. В результате, проект превращается потихоньку в мешанину разных технологий программирования, разных подходов, постепенно переходя в неуправляемое состояние.
Занавес. Минута молчания.
Второй пример. Примерно год назад разрабатывал я один модуль. Перед до мною возникла проблема, как правильней его сделать. Была фабрика классов с метаданным, нужными этим классам. Возник вопрос, как лучше поступить с метаданными: создавать копию метаданных для каждого объекта заданного класса или ссылаться на метаданные класса, лежащие в фабрике? С одной стороны, если сохранять метаданные в объекте, то можно для каждого объекта в отдельности задавать свой набор метаданных, кастомизировать их, но с другой стороны- это же избыточно. С одной стороны избыточность невысокая- их совсем не много, но с другой стороны, если надо глобально всем сразу изменить метаданные, то удобней, когда используется единый набор метаданных. Хм, выбор явно не однозначный. Логика была за вариант общих метаданных для всех. А потом, если понадобится, то можно и "ленивое" копирование организовать. Но интуиция, сформированная на опыте, подсказывала, что надо копировать. Да это не логично, да, "ленивое" копирование- хороший вариант. Но, все равно, лучше копировать, и точка! Интуиция победила. Т.к. метаданные- это обычная структура, не класс, то копирование их в коде- это одна строчка. Спустя год я реально ощутил, как здорово, что я не повелся на аргументы логики, а прислушался к "дочке" своего опыта - интуиции. Оказалось востребованным динамическое изменение поведения классов, и тут замечательно пригодились метаданные, в которых я стал хранить флаги состояний. Где надо- использую паттерн "декоратор", а где-то обычными if'ами обхожусь, анализируя метаданные.
Вот и сейчас я пишу код, пока не понимая до конца зачем я именно такой вариант выбрал. Я просто чувствую, что так правильней, и знаю, что я не ошибаюсь в своей интуиции.
Гляжу на код более молодых коллег: он правильный, логичный, но... он ошибочный. Раньше я старался подобрать слова, чтобы объяснить, почему лучше сделать по-другому. Это очень трудно сделать потому, что надо суметь объяснить невидимые в рамках нынешнего задания вещи. То, что возникнет через месяц, через год и потребует полного переписывания ныне кажущегося логичным кода. Теперь я уже просто говорю: "Сделай так, приятель!" Без объяснений- придет время, и этот приятель поймет, что я был прав.
Очень хочется стать настоящим гуру в своем деле, чтобы уметь не только чувствовать правильные вещи, но и суметь их убедительно объяснить другим. Показать на примерах по текущему заданию, где ошибка в логике, почему текущая логика тупиковая. При этом имея ввиду вещи, которые реально выходят за рамки текущего задания. Это архисложная задача.
Тут есть другая крайность- увлечься избыточными абстракциями. Такое происходит, когда знаний уже много, а опыт еще их не перевесил. Не сформировалась инженерная культура, нет интуиции. Поэтому нет понимания того, где надо остановиться.
А еще хочется, как настоящему гуру, писать код с "защитой от дурака", код препятствующий его не правильному использованию, и чтобы это был очень простой и элегантный код.
Я стараюсь, я учусь, я набираюсь опыта. Я уже не молодой перспективный специалист, но еще и не гуру. Я в пути.
