Хорошо обучать вытачиванию деталей – сделал ученик слишком тонкую, нагрузили ее как следует – сломалась. Сделал слишком толстую, показали разницу с нормальной деталью и спросили – зачем лишний металл расходовать?
В каратэ технике обучать так же удобно: выпрямил в майя-гири опорную ногу, сенсей по ней шлепнул слегка, ласково приговаривая при этом “что прямое, то ломается” – и запомнишь урок на всю жизнь ;)
А вот в живописи уже гораздо сложнее. Еще хорошо, когда учитель говорит – здесь тени неправильно лежат при таком источнике. В крайнем случае можно ученика заставить натурный эксперимент поставить, чтобы доказать это. А вот как быть, когда недостатки формулируются как “передний план перегружен” или “тона в левом верхнем углу слишком яркие”? Есть здесь какие-то объективные критерии проверить правильность претензий учителя? По-моему, нет. Либо веришь и набираешься ума-разума. Либо не веришь и идешь к другому учителю. Ну или пытаешься доказывать всему миру, что твое видение предмета правильное :) В конце-концов, у Винсента ван Гога и Поля Гогена получилось. После смерти…
Программирование же в этом смысле является чем-то средним между слесарным ремеслом (или каратэ, если хотите) и живописью. С одной стороны, написана программа, которая работает – т.е. выполняет то, что от нее требуется. Но смотришь на ее исходник, и понимаешь, что “передний план-то перегружен”. Что можно сделать проще. Или чуть сложнее, но гибче. Понимать-то понимаешь, но когда дело доходит до объяснения… Тут-то и начинаются сложности.
Хорошо, когда буквально на пальцах можно объяснить, как сделать проще. Например, было:
int get_multiply() {
int result = SINGLE_FACTOR;
if( some_condition() )
result = DOUBLE_FACTOR;
return result;
}
а можно было бы сделать:
int get_multiply() {
return some_condition() ? DOUBLE_FACTOR : SINGLE_FACTOR;
}
(Хотя, если такого кода много в разных ипостасях, то указывать на каждую возможную модификацию нереально – время находится только на то, чтобы сказать: “можно сделать проще.”)
Хуже, когда дело касается “вкусовых” пристрастий, ведь любую более-менее серьезную задачу можно решить несколькими способами. Кто-то делает ее решение с использованием классов A, B, C и D. Мне кажется, что можно было бы обойтись классами C и D, но добавив общего предка E. Работать будет и так, и так. Но какое решение лучше? Мне на основании собственного опыта и набитых шишек может казаться, что моим способом. Моему подчиненному может так не казаться.
Аргументы “Поверь моему опыту, у тебя передний план перегружен” или “Передний план перегружен, я сказал!” не проходят. Программа работает. Как она будет расширяться в будущем – это гадание. Может как я говорю, может не так. Худшее, что здесь может произойти – это долгая и бессмысленная перепалка на тему того, какая вероятность больше (еще одна вариация соревнования “у кого длиннее”).
Поэтому свою точку зрения нужно аргументировать (хорошо сказано, *ля). Но для аргументации нужно время, нужна демонстрация альтернативной реализации. А ведь код уже есть, и он работает, да только мне не нравится. Поскольку выработанный за долгие годы нюх подсказывает, что “передний план-то перегружен”, и все это придется основательно дорабатывать напильником, если придется этот код сопровождать. (А сопровождать-то придется. Причем, в соответствии со всеми законами подлости, сопровождать именно тебе, и в самые кратчайшие сроки, когда какому-нибудь VIP-клиенту что-нибудь в голову стукнет.)
И все этого хорошо, если не возникло никаких личностных претензий, вроде “Ты всегда ругаешь мой код!” Тут вообще руки опускаются, и хочется оставить все как есть, отрезав напоследок: “Ну смотри сам, сопровождать будешь лично ты.”
В общем, жалко, что аргументы “Потому, что я так сказал!” не канают… :(
PS. С программами-то еще ладно. Там хоть какие-то объективные критерии могут быть найдены. А вот с документацией куда хуже. “Этот абзац непонятен” – “Как непонятен? Я же здесь все подробно написал.” – “А мне, как читателю, непонятен.” – “Ну не знаю, я все понимаю!”
PPS. Любые совпадения с реальными персонажами, фрагментами программ и диалогов являются случайными и непредумышленными. Я описал сборный портрет молодого программиста. Сам был таким в районе 1992-1999 годов, особенно в части документации.
PPPS. По молодости все мы талантливые программисты, пишущие качественный код и отличную документацию. С годами мы осознаем, что это, мягко говоря, далеко не так. К сожалению, на это уходит много времени и нервов наших учителей.
(как по мне, так OCaml в виде скрипта еще менее читаемый, чем в виде автономной программы ;)
