Re: Программирование на функциональных языках - как научить?
Alexey Pechnikov -> debian-russian@lists.debian.org @ Wed, 19 Aug 2009 15:13:13 +0400:
AP> Возникла проблема - пытаюсь научить программистов писать на тикле,
AP> но они пишут, как раньше писали на С - море глобальных переменных и
AP> т.п. И на С это было бы достаточно хреново, но на динамическом
AP> языке и вовсе кошмар. Что им дать почитать, чтобы они поняли
AP> разницу и начали программировать более "адекватно"? Образование у
AP> людей высшее, физико-математическое (нижегородский радиофак, если
AP> быть точным). Отличительная особенность - очень упрямы...
AP> Как пример одного из "шедевров" - инклюд с сотней проверок на то,
AP> откуда он вызван. Полдня пытался понять, как он работает, не
AP> получилось, а сам автор говорит, что за недельку разберется или
AP> перепишет целиком...
Я знаю один надежный метод. За то время, в течение которого он
"разбирается или переписывает", не платить зарплату. За недельку
разберется? Четверть зарплаты недополучит.
Вообще же все сильно зависит от имеющихся рычагов.
Можно требовать сдачи кода, который можно нормально поддерживать - и не
принимать работу, пока он таковым не сделан. Это требует сдельной
оплаты. Ну или штрафов.
Можно не платить зарплату время с момента обнаружения проблемы с работой
его кода до момента, когда проблема пропадет и новых не появится. Под
девизом "за работу этого кода тебе уже заплатили". Это требует
какого-то договора на поддержку на случай увольнения по собственному. С
материальной ответственностью за время простоя, да.
Можно уволить и нанять других. Или уволить, сделать их работу
самостоятельно и взять себе их зарплату. В общем, все зависит от
ситуации.
Потому что люди либо хотят делать работу хорошо - и тогда достаточно
один раз сказать, либо не хотят - и тогда надо либо мотивировать
сильнее, чем "не хочу", либо не пользоваться их услугами вообще.
В принципе, если человек может написать с твоей точки зрения через
задницу, но его код работает, и он отвечает за внесение в его
функциональность потребных изменений в потребное время - то это его
личное дело, как писать. Донести надо, что результат работы - это не
то, что здесь и сейчас "вроде работает", а нечто, что будет работать (а
не "вроде работать") и в будущем, и без лишнего геморроя обрастать
изменениями функциональности по мере необходимости. С другой стороны,
надо помнить про принцип KISS - иначе код не заработает никогда, как бы
правильно он ни был написан.
--
А еще следует потребовать, чтобы программисты, перед тем, как писать код,
внимательно прочли спецификацию: с сыром - это чизбургер.
Игус в <Pine.LNX.4.44.0401231840020.15582-100000@moon>
Reply to: