Тут мы пообсуждали localstorm мою статью о CopyPaste. Ну и пришли к выводу, что да CopyPaste бывает полезен, но скорее для профессионалов, в тот момент когда люди понимают зачем и как его использовать.
Ну и по ходу у нас вышло вот такое обсуждение:
Victor>Поэтому я и говорю, что безусловно есть применению копированию, но для серьезного большинства малоопытных программистов (и тех кто их окружает) – это абсолютное зло.
localstorm>, у меня нет другого решения проблемы неопытных программистов, кроме как начать давать им реальные задачи, показывать, где они не правы и просить больше так не делать. 
Не станешь же думать, что вот, этот чувак не опытный, надо у него отобрать отвёртку и напильник, а то покалечит нашу систему
Я полностью согласен о том, что единственный метод обучить – это работать с ними, показывая хорошие решения и объясняя почему плохие решения плохие. Но я не согласен, что отбирание напильника (или бензопилы) такая уж плохая идея.
Сначала небольшая аналогия, а потом к делу. Представим себе, что у нас есть Linux машина и мы всем раздаем root права. И администратор говорит, ну что же поделаешь, что пользователи могут к черту все системы разнести, я приду починю, пожурю, объясню в следующий раз как надо и как не надо делать.
Так вот, как-то так уже сложилось, что в среде программистов какое-то уж совсем нездоровое равенство. Все имеет право использовать весь набор инструментов.
Так вот, я выступаю за то, чтобы разграничить права на использование инструментов, как разграничены права пользования в Linux. Условно говоря, главный программист может делать любые действия. Средний программист не имеет права изменения критических существующих интерфейсов и ядра системы. Младший программист не имеет правда добавления новых файлов, copypaste и т.п. Еще раз… Это всего лишь пример. У меня сейчас нет в кармане полного списка прав и как все разделить и разграничивать.
Естественно задача проблемного кода решается даже без введения ограничения на инструментарий путем review кода до сommit’а его в SVN. Но даже на этом уровне, получается, что доступ к более опасным tool’ам будет съедать время главного программиста, так как ему придется объяснять, что Вася, не бери бензопилу, не меняй интерфейсы в классах.
Но, все таки гораздо удобнее было бы таки, по мере роста программиста позволять пользоваться более широким инструментарием. Опять же, это упростило бы работу самого программиста тоже. Когда у него есть всего 10 методов работы с кодом, а не 100, их будет гораздо легче освоить и использовать корректно.
Да, кстати, localstorm пишет в своем ЖЖ о управление проектами, программировании и других IT радостях жизни. Рекомендую почитать – хорошие и взвешенные мысли.
P.S. В многих комментариях проскочила одна и та же мысль. Можно же откатиться по системе контроля, так что ничего страшного. Я согласен, что откат уменьшает в десятки раз нанесенный ущерб. Но! Пусть нам нужно скажем сделать какой-то модуль. Мы можем это сделать двумя методами – даем неопытному его дизайн, он его делает плохо, мы объясняем как делать хорошо, он переделывает. Или мы сначала объяняем как делать хорошо и он сразу делает хорошо. Второй путь по большему счету более эффективный (с точки зрения компании). Замечу, “откатить” плохой дизайн мы можем мгновенно, но дизайн все равно придется второй раз делать. Поэтому, когда мы заранее знаем где лежат грабли, имеет смысл действовать проактивно, то есть решать проблему ДО того, когда она стукнула тебя по голове.
