В первую очередь скажу, что мне по смыслу и по способу изложения материала понравилась статья Эльдара. Как раз, готовя новую статью, обдумывал материал в том же ключе, что написал Эльдар. Поэтому, я повторяться не буду ‑ прочитайте, сначала, его статью, а потом мою приписку «сбоку».
У управленцев Эльдар описал, что часто присутствует чрезмерное увлечение различными методологиями. От себя скажу, что у программистов это выливается в поиски «божественной» архитектуры. У сисадминов – излишняя прыть в переустановке всего и вся «потому, что это круче, чем было».
В общем-то, весь смысл далее читать статью я могу убить сразу, сказав, что это чаще всего возрастное. Старшим коллегам просто надо держать при себе длинную линейку, присматривать за своими молодыми коллегами, и, вовремя, точным ударом больно бить их по пальцам. Потом, человек набирается опыта, становится осторожнее и разумнее в своих поисках «божественного нечто».
Сисадмины.
Третье, почти недоступное большинству, правило: знать потребности пользователя. Конечный пользователь редко когда знает, какие из его задач можно решить с помощью компьютера. Вот, если вы сумеете в нужный момент подсказать верное решение, то прослывете «золотым незаменимым человеком». Зачастую это очень простые решения, совершенно очевидные для вас, но не для непросвещенных в ИТ коллег.
И вот, когда эти принципы будут у вас в крови, тогда и придет понимание, что слово «круче» само по себе пустое, и не может являться целью. Проблемы будут решаться легко и минимальными телодвижениями. Достаточно будет сделать пару настроек, худшем случае «поднять» сервис. Оборудование будет работать годами, не зависая, и ведя себя весьма прогнозируемо. Со стороны, вы будете выглядеть как чародей- все работает само собой, вы только пару раз на кнопочки надавили, и что-то там исправилось, что-то еще запустилось. И все делается без суеты, без излишнего копошения, точно и выверено. Вот только тогда вас назовут отличным специалистом, настоящим профессионалом.
Программисты.
У программистов пусть более витиеват. Практически с самого начала карьеры надо решить следующую дилемму. С одной стороны, хорошо, если начинающий программист сразу будет учиться правильно программировать: знать различные алгоритмы обработки данных, паттерны проектирования. С другой стороны, не имея достаточного опыта, свои новые знания он будет применять очень кособоко, как в таких случаях говорят, «да, за такое руки отрывать надо!». Лично я для себя решил, что начинающим программистам про паттерны точно рассказывать не надо. Именно из-за озвученной дилеммы я выступаю против паттернов. Потому, что начинающих они сбивают с толку, а опытным уже не нужны- они и так на практике их освоили. И где же та грань, когда можно «безвредно» изучить паттерны? Именно, начитавшись Фаулера, «банды четырех» молодой, неокрепший ум ударяется в поиски «божественной» архитектуры приложения. Не знаю тут никакого рецепта, не знаю. Только опыт, только свои «шишки».
Но и тут немало сложностей! Часто трудно определить грань, между простотой и плохим, не масштабируемым решением. Да, мы прошли уже немалую цепочку в принятии правильного, «божественного», единственно верного решения и, тем не менее, у нас есть довольно высокая вероятность остаться у «разбитого корыта» (т.е. принять неправильное решение). И тут, вблизи правильного решения, расслабляться нельзя. Я не утрирую. Вот реальный пример из моей практики. Мы внедряли систему ERP. Внедрялась она со скрипом, и под сильным нажимом начальства на подчиненных, которые «отбрыкивались» от нее, как только могли. Потому, что система была неудобная. Она была мощная, многофункциональная, но неудобная. Экранные формы изобиловали кучей мелких кнопочек, буквально размером 4х4 пикселя, иначе они все в экран не влезали. Большинство стандартных кнопок и горячих клавиш были весьма своеобразно переопределены. Почему это произошло? Программисты были опытные, суть задачи понимали великолепно, выбирали самое простое решение (чего же проще- налепить еще одну кнопку куда-нибудь, вместо того, чтобы основательно порефакторить всю форму?). Так чего им не хватило, чтобы сделать правильно? Интуиции. Да, в конце всего сложного пути принятия решения стоит не нечто логичное, понимаемое, а интуиция. Иррациональное чувство прекрасного. Ощущение того, что если сделать именно так, то будет правильно. Без логики и без объяснений: «Я думаю, что надо делать так.»
И вот, на вершине мастерства, программист в чем-то пересекается с опытным админом, ведь у админа конечный пункт- знать потребности пользователя, что тоже опирается на неосязаемую интуицию.
PS: Да, кстати, а «божественной» архитектуры ПО не существует. 😉