Тут мы пообсуждали localstorm мою статью о CopyPaste. Ну и пришли к выводу, что да CopyPaste бывает полезен, но скорее для профессионалов, в тот момент когда люди понимают зачем и как его использовать.
Ну и по ходу у нас вышло вот такое обсуждение:
Victor>Поэтому я и говорю, что безусловно есть применению копированию, но для серьезного большинства малоопытных программистов (и тех кто их окружает) — это абсолютное зло.
localstorm>, у меня нет другого решения проблемы неопытных программистов, кроме как начать давать им реальные задачи, показывать, где они не правы и просить больше так не делать. 🙂 Не станешь же думать, что вот, этот чувак не опытный, надо у него отобрать отвёртку и напильник, а то покалечит нашу систему 🙂
Я полностью согласен о том, что единственный метод обучить — это работать с ними, показывая хорошие решения и объясняя почему плохие решения плохие. Но я не согласен, что отбирание напильника (или бензопилы) такая уж плохая идея.
Сначала небольшая аналогия, а потом к делу. Представим себе, что у нас есть Linux машина и мы всем раздаем root права. И администратор говорит, ну что же поделаешь, что пользователи могут к черту все системы разнести, я приду починю, пожурю, объясню в следующий раз как надо и как не надо делать.
Так вот, как-то так уже сложилось, что в среде программистов какое-то уж совсем нездоровое равенство. Все имеет право использовать весь набор инструментов.
Так вот, я выступаю за то, чтобы разграничить права на использование инструментов, как разграничены права пользования в Linux. Условно говоря, главный программист может делать любые действия. Средний программист не имеет права изменения критических существующих интерфейсов и ядра системы. Младший программист не имеет правда добавления новых файлов, copypaste и т.п. Еще раз… Это всего лишь пример. У меня сейчас нет в кармане полного списка прав и как все разделить и разграничивать.
Естественно задача проблемного кода решается даже без введения ограничения на инструментарий путем review кода до сommit’а его в SVN. Но даже на этом уровне, получается, что доступ к более опасным tool’ам будет съедать время главного программиста, так как ему придется объяснять, что Вася, не бери бензопилу, не меняй интерфейсы в классах.
Но, все таки гораздо удобнее было бы таки, по мере роста программиста позволять пользоваться более широким инструментарием. Опять же, это упростило бы работу самого программиста тоже. Когда у него есть всего 10 методов работы с кодом, а не 100, их будет гораздо легче освоить и использовать корректно.
Да, кстати, localstorm пишет в своем ЖЖ о управление проектами, программировании и других IT радостях жизни. Рекомендую почитать — хорошие и взвешенные мысли.
P.S. В многих комментариях проскочила одна и та же мысль. Можно же откатиться по системе контроля, так что ничего страшного. Я согласен, что откат уменьшает в десятки раз нанесенный ущерб. Но! Пусть нам нужно скажем сделать какой-то модуль. Мы можем это сделать двумя методами — даем неопытному его дизайн, он его делает плохо, мы объясняем как делать хорошо, он переделывает. Или мы сначала объяняем как делать хорошо и он сразу делает хорошо. Второй путь по большему счету более эффективный (с точки зрения компании). Замечу, «откатить» плохой дизайн мы можем мгновенно, но дизайн все равно придется второй раз делать. Поэтому, когда мы заранее знаем где лежат грабли, имеет смысл действовать проактивно, то есть решать проблему ДО того, когда она стукнула тебя по голове.
http://rsdn.ru/Forum/Info/FAQ.philosophy.kungfu.aspx
Не, ну это же классика кун-фу:
* Сначала ты не знаешь, что нельзя делать то-то
* Потом знаешь, что нельзя делать то-то
* Потом ты понимаешь, что иногда таки можно делать то-то
* Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.
* Когда тебя спрашивают «как мне добиться желаемого», ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: «вообще-то, главное — гармония.»
* На вопрос обиженных учеников: «а как ее добиться?», ты говоришь: «никогда не делайте то-то».
Полностью согласен.
Так оно и есть. Мгновенно допрыгнуть до ситуации «Гармония = хороший ход» и объяснить это другому разработчику невозможно. Поэтому сначала бьем по руками или вообще не даем делать то-то (в нашем случае copy/paste).
Потерялся коммент из-за 404 при попытке логина через OpenID 🙁
OpenID не работает. Все теряют.
О, т.к. без логина работает, то примерно восстановлю мысль.
Во-первых, бензопила — не самая хорошая аналогия. Мясо невозможно провернуть назад, как говорится. Если чего себе отпилишь, то если пришьют, то будет уже «не то».
Код всегда можно откатить, если что-то реально сломали.
Так что не доверяйте администрировать SVN junior’ам 🙂 С Linux та же фигня. Да и вообще с невиртуализированными ресурсами. Быстрых и безболезненных способов восстановления в общем-то нет 🙁 Всегда делается с такой-то матерью и со стрессом. Особенно, если это продакшн система 🙂
А насчет того, что неопытные сотрудники съедают время опытных, так это совершенно нормально. Более того, так всегда и будет. Это неизбежно и в общем-то именно так и происходит их превращение в опытных. Можно и на собственных ошибках, но мне не хотелось бы работать в такой конторе, где всё на чём бы я смог научиться — собственные синяки, а те, кто их уже когда-то набил витают где-то в космосе, т.к. из время очень дорого, им не до такой мелюзги типа меня 🙂
ok. Я чувствую сквозь все комментарии проходит одна и та же тема ответа. Я отпишу в P.S. статьи о возвожности «отката» в source control.
То, что неопытные сотрудники съедают время — это нормально. Но они могут съедаеть его получая больше умений из этого и меньше умений из этого.
Обязательно надо иметь что-то в роде песочницы (тренированного зала), где юному «падавану» можно все. Опять же, если это оторвано от реалий, то будет не эффективным обучением.
Ограничение инструментов разработки — отличная идеей. Хотя очень трудно приложить к современным инструментам разработки. Такое ощущение, что и инструменты, и код(и дизайн), и процессы должны быть идеальны, что бы такое ограничение могло быть.
Я дописал P.S. Проблема состоит не только в необходимости убрать внесенные изменения, но и в необходимости по второму кругу делать изменения, только уже правильно.
Да, я согласен реализовать это дело сложновато. Скажем так, пробема в том, что при нынешнем разнообразии разных tool’ов, их малой интеграции с друг другом, фактически такое не возможно.
При тесной интеграции IDE, системы контроля версий, багов, управления предприятием, такие вещи делались бы на раз.
Если просто объяснять как сделать хорошее решение, то неопытный просто не поймёт чем же оно лучше. А вот если дать ему сделать как он хочет (понаступать на грабли), потом показать, что он ещё упустил в своём решении, и как таки сделать это всё правильно, то да — времени он затратит раза в 2 больше, но польза будет значительно больше чем в 2 раза, т.к. он не только поймёт как надо сделать правильно, а ещё и поймёт почему его 1-е решение было неправильным — а вот это уже позволит ему не повторять его ошибки.
Уже сравнивал — позволить сделать с ошибкой и объяснить как её исправить и сделать правильно, даёт лучший эффект при обучении как работы в целом, так и работы с системой в частности(ибо залезут туда, куда ты и подумать не мог — зато лучше начнут понимать логику системы).
Таки ждал этого комментария 🙂 И честно говоря нечего ответить. Действительно с точки зрения скорости обучения — быстрее человек учиться, когда два раза получил по лбу граблями — третий раз уже не наступаешь.
С другой стороны, компании от этого может быть не слишком тепло. Частенько человек учиться в одной компании, а потом использует свои знания в другой.
Хотя опять, же, для того чтобы человек получил граблями по лбу, ему нужно сначала таки разрешить пользовать copy/paste, изговнять проект вдребезги. Пытаться его в таком виде support’ить годик, не попадая ни в один deadline и работая на выходные. И вот в конце года он таки сообразит, что активно используя copy/paste год назад, он организовал себе веселую жизнь.
Если же все заканчивается на том, что он делает плохо и ему говорят как сделать лучше, то у него нету обратной связи (его по лбу ничего не бъет) и вот тогда таки выгоднее сначала говорить, а потом что-бы он делал или блокировать вообще возможности делать неправильно.
Ну зачем же сразу «пользовать copy/paste, изговнять проект вдребезги. Пытаться его в таком виде support’ить годик, не попадая ни в один deadline и работая на выходные».
Вполне достаточно выполнить 2 пункта:
1) давать небольшие задачи («детские грабли») — чтобы можно было относительно быстро потом показать как делать надо.
2) Посадить на maintenance проект на фикс багов, чтобы он увидел к чему могут приводить ошибки, которые он допустил, если их допускать и запускать.
Такое сочетание хорошо прочищает мозги и очень хорошо учит читать код.
Все таки, если мы говорим об эффективности обучения, то между 1) и 2) большой разрыв. Человек видит как делать надо, получает по лбу чужими граблями. Но, все же он не получает по лбу именно своими граблями, поэтому обратная связь не так сильна.
Хотя впрочем, мы достаточно сильно отклонились.
как-то в дебри зашли в этих умствованиях.
Есть определенные задачи которые поподают программистам через тим-трекинг. нужно следить чтобы критически важная задача не попала Васе и тд. Потом, я думаю что сегодня все используют систему контроля версий и авт. сборку. Если даже Вася полезет менять интерфейсы и загубит сборку, это легко исправить.
«Загубит сборку» это «код перестанет собираться» или «внесено маленькое изменение»?
Как трекер сможет защитить код от изменений, если Васе в его мелкой задаче захотелось чуточку изменить основные подпрограммы? Всего чуть чуть… И поломалось только на платформе XYZ при наличии библиотеки ABC версии QWE.
Наверное речь все же об обзорах…
roll back в системе контроля версий изменений Васи решит проблему. Трекер -для управления и мониторинга какая задача кому пришла. 🙂
Я дописал P.S.
Проблема доступа к опасным tool’ам состоит не только в «откате». Но и в том, что вероятнее всего пользуясь copy/paste разработчик сделает работу плохо. Вывод, нам прийдется делать
а) Откат
б) Разъяснение почему плохо
в) Ему придется делать работа снова
С другой стороны, если бы доступ к copy paste был запрещен, то вероятность возникновения такой проблемы была бы гораздо меньше.
Опять же, мы только говорили о Copy/Paste. Но в целом есть достаточно много опасных действий.
Так, вот если вероятность плохо сделать работу пользуясь опасными решениями равна 80%, а не пользуясь ими равна 30%. То, таки выгодно закрыть к ним доступ заранее.
мммм есть софтверная фирма, выпускающая программы, весь код лежит в SVN откуда он и собирается. О каких опасных решениях кроме изменения этого кода мы говорим??
в PS ты описал 2 решения, но принцип работы один — человек меняет код модуля.
те здесь опасное решение -это только не знание структуры кода, которое он меняет.
ok. Убираем слово опасность.
Если человек что-то делает плохо, а потом переделывает — мы теряем на этом некоторую сумму. Если не дать ему это делать плохо (уменьшить вероятность делания плохо) то мы получаем денежный выигрыш.
То есть, блокирования copy/paste — приводит к уменьшению вероятности сделать плохо и приводит к уменьшению издержек производства. Я именно об этом веду речь.
я что-то потерял нить, в чем проблема ?
В том что нет софта который может ранжировать доступ к определенным файлам ?
Или нельзя применить смекалку для удешевления контроля за опасными тулзами? ( типа есть пользователь на которого эксклюзивно залочены файлы: модели, интерфейсы, скрипты. Логин юзверя «ЛИД» … иссесено если изменения с ним согласованы он «нужные» файлы отпускает … И тут уже: чем больше у ЛИД’а критичных файлов — тем хуже лид 🙂 тем больше у него гемороя. )
Тут еще есть психологический фактор: я «вижу» кратчайший путь решения поставленной задачи, но «тулзы» глючат и говорят что у меня нет доступа … приходится делать , через … вобщем в обход, в итоге реализация получится еще хуже чем кривая ( ибо заведомо неоптимальная(которой были нужны опасные тулзы) реализация была адаптированна к тому что есть в наличии … естесвенно за большее время … + дебаг … и в результате рефакторинг 🙂 )
С другой стороны: если сервер контроля версия настроен таким образом что лиду сваливаются наличия изменений в критичных ( по его мнению) файлах, и отфильтровываюся по Тем, кто эти изменения внес — всегда проще 🙂
Критические секции знаю. А критические файлы… Что это?
C++ отказывается от использования файлов для обозначения блоков кода. C# ввели расширение методов ( http://msdn.microsoft.com/ru-ru/library/bb383977.aspx ).
Снабдить cvs чем-либо типа http://pmd.sourceforge.net/cpd.html и высылать тимлиду уведомления? Человек существо изобретательное, после 2х пинков научится обходить программу.
Обобщу проблему следующим образом.
Проблема, что максимальная точноть по которой можно разбить кому из программистов что можно, а кому нельзя — являются файлы.
а) Невозможно указать что-то ниже файла (а-ля нельзя изменять интерфейсы)
б) Невозможно указать tool’ы которыми нельзя пользоваться (а-ля copy/paste)
Обе проблемы не супер критичные, если что-то сделано не так, то это можно отловить в какой-то момент.
Но…. Собственно насчет этого «НО» и спорим.
Я говорю, что лучше проблемы предотвращать (как болезни), чем лечить.
Мне кажется тут идет «смешение уровней»:
есть 4 основные роли в разработке:
1 Архитектор(виденье системы, патерны интерфейсы,бутылочные горлышки, маштабируемость, итп.)
2 Проэктировщик(Тот кто знает: Как реализован интерфейс и как новую «фичу» можно безопасно прикрутить в рамках парадигмы которую заложил архитектор. )
3 Разрабочик ( получает от проэктировщика проэкт, где и чего нужно реализовать, ОН НИКОГДА НЕ ЛЕЗИТ В ОБЕКТНЫУЮ МОДЕЛЬ где может реально накасячить, ему это просто не нужно, ибо если нужен новый интерфейс ему напишут какой и где он должен быть)
4 Руководитель проэкта. (следит за тем чтобы уровни не смешивались и все работало «как надо» 🙂 )
если:
Кто-то из решил взять на себя более одной роли: потенциальный косяк.
Идеальная тулза, это та, которая выполняет одно дейсвие ИДЕАЛЬНО 🙂
Комбайн — многофункционален ДИШЕВЛЕ суммы всех идеальных тулзов, но труден в поддержке и не гибок 🙂
Тут как в традиционном: Быстро/Качественно/Дешиво — выбирай любые 2! 🙂
Ну, во первых такое четкое разделение ролей достаточно редко. Оно существует в крупных компаниях, причем только в хорошо организованных крупных компаниях.
В большинстве же компаний роли таки активно смешиваются.
ugg boots on sale
cheap ugg boots
ugg