О божественном знании

В первую очередь скажу, что мне по смыслу и по способу изложения материала понравилась статья Эльдара. Как раз, готовя новую статью, обдумывал материал в том же ключе, что написал Эльдар. Поэтому, я повторяться не буду ‑ прочитайте, сначала, его статью, а потом мою приписку «сбоку».
У управленцев Эльдар описал, что часто присутствует чрезмерное увлечение различными методологиями. От себя скажу, что у программистов это выливается в поиски «божественной» архитектуры. У сисадминов – излишняя прыть в переустановке всего и вся «потому, что это круче, чем было».
 В общем-то, весь смысл далее читать статью я могу убить сразу, сказав, что это чаще всего возрастное. Старшим коллегам просто надо держать при себе длинную линейку, присматривать за своими молодыми коллегами, и, вовремя, точным ударом больно бить их по пальцам. Потом, человек набирается опыта, становится осторожнее и разумнее в своих поисках «божественного нечто».

  

Сисадмины.

У сисадминов с этим достаточно просто: сначала минимальный уровень прав, потом больше, и так, в течение 7-10 лет, глядишь, вырастет профи из «мальчика-на-побегушках». Обычно начинают с того, что поручают настройку клиентских мест. Главное тут, чтобы молодой сисадмин научился не тупо переставлять ОС, а находить причины сбоя, локализовать их и устранять. Ведь сам процесс переустановки часто сопряжен с сохранением конфигурации пользователя, его рабочих файлов и последующим восстановлением. А это может быть не быстрый процесс, а ведь пользователю работать еще надо. Не всегда даже имеет смысл вообще устранять ошибку ‑ проще ее просто обойти (например, с одного USB-порта принтер не печатает, переключил на другой, если стал печатать, то и фиг с ним, с первым USB-портом). Важно научится решать проблему минимальным количеством телодвижений.

Второе, чему должен научиться сисадмин, – это здоровый консерватизм. Переустанавливать программное обеспечение имеет смысл только в случае, если это реально оправдано. Не по принципу «это круче», а, например, устранена серьезная брешь в безопасности, или появилась новая функциональность, востребованная в организации.
Третье, почти недоступное большинству, правило: знать потребности пользователя. Конечный пользователь редко когда знает, какие из его задач можно решить с помощью компьютера. Вот, если вы сумеете в нужный момент подсказать верное решение, то прослывете «золотым незаменимым человеком». Зачастую это очень простые решения, совершенно очевидные для вас, но не для непросвещенных в ИТ коллег.

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

Программисты.
У программистов пусть более витиеват. Практически с самого начала карьеры надо решить следующую дилемму. С одной стороны, хорошо, если начинающий программист сразу будет учиться правильно программировать: знать различные алгоритмы обработки данных, паттерны проектирования. С другой стороны, не имея достаточного опыта, свои новые знания он будет применять очень кособоко, как в таких случаях говорят, "да, за такое руки отрывать надо!". Лично я для себя решил, что начинающим программистам про паттерны точно рассказывать не надо. Именно из-за озвученной дилеммы я выступаю против паттернов. Потому, что начинающих они сбивают с толку, а опытным уже не нужны- они и так на практике их освоили. И где же та грань, когда можно "безвредно" изучить паттерны? Именно, начитавшись Фаулера, "банды четырех" молодой, неокрепший ум ударяется в поиски "божественной" архитектуры приложения. Не знаю тут никакого рецепта, не знаю. Только опыт, только свои "шишки".

Когда приходит опыт, тогда в голове правильно, "по полочкам", раскладываются и паттерны, и базовые алгоритмы обработки данных. И наступает следующий этап. Умение правильно принять решение о том, какой именно подход использовать для решения задачи. Решений, как правило, бывает несколько. Обычно, это происходит из-за недостаточного понимания сути задачи. Моя рекомендация: углубляться в задачу, разбирая ее на мельчайшие составные части до тех пор, пока абсолютно четко не станет ясно, как именно решать задачу.Т.е. надо научиться отсеивать множество решений, через более глубокое понимание сути задачи.

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