Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Показать людям, что профессиональный рост приведёт к соответствующему вознаграждению. Купить хороших книг по программированию и сделать библиотеку. Нанять в команду ведущего разработчика — настоящего профессионала и энтузиаста, готового обучать и помогать другим. Проводить code review. Поощрять взаимопомощь (может быть, попробовать парное программирование). Для ключевых модулей системы заранее проектировать архитектуру, дизайн и интерфейсы (возможно, нанять хорошего архитектора). Наладить процесс continuous integration — убедиться что есть система контроля версий, багтрекер, на сервере собирается билд и гоняются тесты, при поломках рассылаются e-мэйлы. Поставить на сервер детектилку копипаста, других метрик, измерять, как изменилось покрытие тестами после чекина — если уменьшилось или тесты падают или критически просели метрики — автоматически отклонять чекин. Тех, кто не способен или принципиально не хочет думать — скорее всего, следует уволить.
Кстати, по некоторым исследованиям, на рынке труда можно найти разработчиков, готовых работать за вдвое большую зарплату, и при этом приносящих в 10-20 раз больше пользы на работе. Но, к сожалению, их не всегда легко отличить на собеседовании от просто дорогих бездельников.
Здравствуйте, nikov, Вы писали:
N>Кстати, по некоторым исследованиям, на рынке труда можно найти разработчиков, готовых работать за вдвое большую зарплату, и при этом приносящих в 10-20 раз больше пользы на работе. Но, к сожалению, их не всегда легко отличить на собеседовании от просто дорогих бездельников.
Здесь сказывается низкая культура отбора персонала...
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Аналогичная ситуация, поскольку заказчику нравится брать в нашу команду людей без опыта (особенно достает его "let him try; what a challenge" и прочая ахинея). Для особенно одарённых, и злостно упрямых товарищей без опыта делаем постоянные код-ревю, причём довольно в агрессивной форме (зуб за зуб), выставляя на всеобщее обозрение наиболее глупые куски кода -- иногда, но помогает. Но часто бывает так, что такой шаблон искореняется у горе-программиста где-нибудь на подсознательном уровне, приэтом порождая ещё более извращённые кодовые конструкции в ближайщем будущем. Но, по видимому, без этого никак. Т.е., или нужно, чтобы люди почувствовали, что это для их же блага, или — вон из команды, как писал выше nikov.
Здравствуйте, Цыба, Вы писали:
Ц>Аналогичная ситуация, поскольку заказчику нравится брать в нашу команду людей без опыта (особенно достает его "let him try; what a challenge" и прочая ахинея).
Я как-то не очень понимаю. Если он заказчик, то отбор команды — не его ума дело. А если он — большое начальство, то пусть сам и трахается со набраной им слабой командой.
И да, не надо наниматься менеджером чего либо, если ваше должностное положение не предполагает соответствующих полномочий.
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
1. Введите объективные критерии приемки сделанной работы. К примеру, сделанной считается работа, соответствующая техническим требованиям и проходящая тесты без ошибок
2. Не считайте работу сделанной, если она не удовлетворяет этим критериям
3. С теми, кто систематически не делает свою работу, поступайте соответственно
Здравствуйте, Pzz, Вы писали:
Pzz>Я как-то не очень понимаю. Если он заказчик, то отбор команды — не его ума дело.
А он так не думает. Если раньше мы сами куда меньшей тогда командой решали, кто нам подходит, а с кем лучше не связываться вообще, то последним временем его мало волнует, нужен ли нам тот или другой человек. Чтобы не возникало вопросов о драматичности сей ситуации, скажу только, что у него есть ещё сын лет 18 от роду, который что-то там варганит нам на WebGL для проекта. Да-да, это чудо по его же (заказчика) инициативе живёт в продакшене своей мутной жизнью. Тот код — зверские джунгли (сам CSS — вообще песня чуть ли не в одну строку; а потом ещё и жалеется, что Subversion криво сливает ветки). В общем, такое вот дело бывает в жизни; тут даже заикнуться о качестве его кода — это сродни неуважения, что-ли.
N>Показать людям, что профессиональный рост приведёт к соответствующему вознаграждению.
Профессиональный рост и вознаграждение — штуки ортогональные. Профессиональный рост чаще ведет к повышению ЧСВ. Увеличение вознаграждения же достигается несколько иными путями (и обсуждается в "О Работе").
А тредстартеру я бы хотел задать свой обычный вопрос: ЗАЧЕМ?! Зачем упомянутый "профессиональный рост команды" нужен лично вам? Зачем он нужен начальству? А он точно нужен? Профессионально выросшая команда захочет больше денег, но будет ли она в конкретных условиях приносить больше пользы?
В тредстартере, похоже, говорит традиционный для всех людей зуд "хочу сделать как лучше", при этом, к сожалению, тредстартер забывает о субъективности понимания "лучше". Я вот тоже люблю учить (и поучать ), и я чуть было даже не купился на ловушку аспирантуры с реальным преподаванием. Хорошо, вовремя остудила необходимость подстраивать расписания на работе и в универе.
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты.
что значит "не хочет"? куда смотрит руководсвто? если руководство не требует писать тестов, то их пишут только те, кто уже обжегся на молоке и теперь дует на воду. если руководство требует писать тесты, а их не пишут, то с таким успехом они могут и не программировать вообще.
> Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
кнутом и пряником. раздаем таски, включающие в себя юнит-тесты. без юнит теста написанный код автоматически отвергается. шутка.
на самом деле все намного сложнее. на примере функции сортировки легко показать, что корректный юнит тест, проверяющий функцию sort меньше, чем в 10,000 строк кода даже на скриптовых языках никак не укладывается (иначе это будет сильно неполный тест). сортировку можно при компактном форматировании уложить и 10 строк.
если взять производителей процессоров, то они параллельно разрабатывали процессоры и системы тестирования. причем, бюджет последних был сильно толше. тоже самое можно сказать о языках. посмотрите сколько строк в том же ядре js и сколько строк в тестах. причем, тесты писать задача намного более сложная. легко написать функцию сложения двух чисел, но намного сложнее написать тест. в силу сложности тестов, нужно писать тесты для тестов. а это уже рекурсия.
юнит тесты, кстати, далеко не единственные. есть и другие. их вообще много... и тестирование по это целая наука и в компании должен быть отдел тестеров и отдел "госприемки" для контроля качества.
а у вас не низкая культура разработки, а низкая культура управления. грубо говоря, вы возмущаетесь почему таксист не хочет ремонтировать машину и не следит за ее техническим состоянием. так это не его работа.
впрочем, эта аналогия хромает. если машина стоит, то таксист ни хрена не получает денег. если зарплата программистов зависит от кол-ва продаж, а кол-во продаж определяется качесвтом и сроками сдачи, то мужики либо разбегуться, либо будут чесать в мозгу.
но как ни крути -- культура она не от природы. культура она от воспитания. а друрной пример заразителен.
кстати, а разве вы не в курсе как лихо увольняют тесторов, на чьих тестах программа упорно спотыкается? даже в ms был скандал и куча народа оттуда оставила комменты в блогах, что тесты показали совместимость вислы ниже плинтуса. тестеров разогнали и сразу исчезли проблемы совместимости. после того, как выяснилось, что проблемы не исчезли, а затаились, то разогнали тех, кто разогнал тестеров, наняли новых и в семерке уже допилили.
вот вы пишите тест, который выявляет ваши проблемы, которые не возникают у 99% юзеров. и что? вам же ремнем по попе. так что тесты писать должны независимые подразделения, которые как раз заинтересованы найти проблемы. им за это платят. а писать тест под себя -- это же показывать свою голую и грязную задницу окружающим. "не взлетит" (с)
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, мыщъх, Вы писали:
>> Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом М>кнутом и пряником. раздаем таски, включающие в себя юнит-тесты. без юнит теста написанный код автоматически отвергается. шутка.
Почему шутка? В большинстве случаев вполне разумный подход.
М>на самом деле все намного сложнее. на примере функции сортировки легко показать, что корректный юнит тест, проверяющий функцию sort меньше, чем в 10,000 строк кода даже на скриптовых языках никак не укладывается (иначе это будет сильно неполный тест). сортировку можно при компактном форматировании уложить и 10 строк.
Это перебор. Во-первых, что толку считать строки, если не известен стиль. Надо считать количество тестовых наборов данных. Во-вторых, для проверки всех характерных ситуаций достаточно до ~50 тестовых наборов. Но кроме того для функций типа сортировки крайне желательно (а для многоуровневой логики и обязательно) проверять каждый раз на несколько случайных наборов.
М>если взять производителей процессоров, то они параллельно разрабатывали процессоры и системы тестирования. причем, бюджет последних был сильно толше.
Очень жаль, что результаты этого всего нельзя увидеть со стороны.
М> в силу сложности тестов, нужно писать тесты для тестов. а это уже рекурсия.
Я уже тут описывал подход, которым пользуюсь — инверсии тестов: в сложном тесте надо вставлять ручки для его явной поломки и проверять, что он ломается как задумано. Это тоже автоматизируется и таки даёт результаты.
М>а у вас не низкая культура разработки, а низкая культура управления. грубо говоря, вы возмущаетесь почему таксист не хочет ремонтировать машину и не следит за ее техническим состоянием. так это не его работа.
Может, его, а может, и не его. Если это таксист по договору со своей машиной — то таки его.
М>но как ни крути -- культура она не от природы. культура она от воспитания. а друрной пример заразителен.
Угу, тут надо именно что воспитывать хорошими примерами.
М>кстати, а разве вы не в курсе как лихо увольняют тесторов, на чьих тестах программа упорно спотыкается? даже в ms был скандал и куча народа оттуда оставила комменты в блогах, что тесты показали совместимость вислы ниже плинтуса. тестеров разогнали и сразу исчезли проблемы совместимости. после того, как выяснилось, что проблемы не исчезли, а затаились, то разогнали тех, кто разогнал тестеров, наняли новых и в семерке уже допилили.
Если эти слухи правда, то это ещё одно доказательство, что Баллмер доведёт её до цугундера.
М>вот вы пишите тест, который выявляет ваши проблемы, которые не возникают у 99% юзеров. и что? вам же ремнем по попе. так что тесты писать должны независимые подразделения, которые как раз заинтересованы найти проблемы. им за это платят. а писать тест под себя -- это же показывать свою голую и грязную задницу окружающим. "не взлетит" (с)
Чушь и работает именно там, где отвратительный менеджмент.
При хорошем менеджменте программист должен быть заинтересован найти у себя баг раньше, чем его найдут тестеры. А в нормальной разработке основная проблема — нащупать путь решения, и нормальный разработчик не должен стыдиться того, что в начале у него "голая и грязная задница", потому что это неизбежно. Нормальное понимание любой части кода придёт только на 3-4-м подходе к нему с заметной переделкой.
Повторюсь, при нормальном менеджменте чем раньше найдут ошибку, тем лучше. Поэтому до отправки коммита лучше, чем после отправки (на review), на ревью лучше, чем после коммита, после коммита, но до попадания на тест в QA отдел лучше, чем в QA отделе, и так далее. Если это надо описать метриками, чтобы работало — пусть будет описано метриками.
Кстати, свежий примерчик — я вчера потерял час на том, что "доработал" не проверяя изменение после теста, но до коммита — показалось, что так будет лучше, и не учёл побочный эффект. Заметил сам, но не мог понять, как это уже удовлетворённый тест вдруг перестал работать.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, michael_isu, Вы писали:
_>>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
N>Показать людям, что профессиональный рост приведёт к соответствующему вознаграждению. Купить хороших книг по программированию и сделать библиотеку. Нанять в команду ведущего разработчика — настоящего профессионала и энтузиаста, готового обучать и помогать другим. Проводить code review. Поощрять взаимопомощь (может быть, попробовать парное программирование). Для ключевых модулей системы заранее проектировать архитектуру, дизайн и интерфейсы (возможно, нанять хорошего архитектора). Наладить процесс continuous integration — убедиться что есть система контроля версий, багтрекер, на сервере собирается билд и гоняются тесты, при поломках рассылаются e-мэйлы. Поставить на сервер детектилку копипаста, других метрик, измерять, как изменилось покрытие тестами после чекина — если уменьшилось или тесты падают или критически просели метрики — автоматически отклонять чекин. Тех, кто не способен или принципиально не хочет думать — скорее всего, следует уволить.
Если отвергать коммит в случае недостаточного покрытия тестами, высокой Cyclomatic complexity и низкой class coupling, это поможет? Допустим поставили — все детектится. Человек типа сделал задачу — чекинить не может. Начинает переделывать — все равно херово сделал. И т.д. Как это повлияет на настрой человека? Как понять, в какой момент ему помочь, если он сидит и молчит, ковыряет что-то молча и все. А если ему надоест постоянно свое переделывать и он решит сменить работу? Этого надо как-то избежать
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Решается тестовым заданием на пару недель.
Здравствуйте, michael_isu, Вы писали:
_>Если отвергать коммит в случае недостаточного покрытия тестами, высокой Cyclomatic complexity и низкой class coupling, это поможет? Допустим поставили — все детектится. Человек типа сделал задачу — чекинить не может. Начинает переделывать — все равно херово сделал. И т.д. Как это повлияет на настрой человека? Как понять, в какой момент ему помочь, если он сидит и молчит, ковыряет что-то молча и все. А если ему надоест постоянно свое переделывать и он решит сменить работу? Этого надо как-то избежать
Отслеживай работы на daily standup`ах, спрашивай людей о том, с какими трудностями они сталкиваются.
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Ваша должность в коллективе? Какие полномочия и обязанности?
Если разработчик — валить в места, где таких вопросов не возникает
Если руководитель — ответить на вопрос, почему в коллективе царит такая атмосфера (возможно, нужно набрать других людей на должность тимлидов/сеньоров, а возможно просто задачи не предполагают лучшего процесса)
Здравствуйте, SkyDance, Вы писали:
SD>А тредстартеру я бы хотел задать свой обычный вопрос: ЗАЧЕМ?! Зачем упомянутый "профессиональный рост команды" нужен лично вам? Зачем он нужен начальству? А он точно нужен? Профессионально выросшая команда захочет больше денег, но будет ли она в конкретных условиях приносить больше пользы?
У нас некий онлайн-сервис, который делается уже 5 лет. И в силу активного роста бизнеса, он постоянно развивается и очень большими темпами. Такими же темпами плодится говнокод. Из-за этого там периодически всплывают всякие баги и порой недоработки архитектуры. И это напрямую сказывается на клиентах, т.к. мы предоставляем достаточно критичный для других бизнесов сервис.
Мне просто интересно делать этот сервис, много интересных задач. Я за 4 года участвовал в нескольких десятках заказных проектах, и хочу сказать что возвращаться туда не хочу вобщем вариант смены работы пока исключен.
Начальству нужно потому, что сам тех. дир и тим лид постоянно решают возникающие проблемы, т.к. другие люди не всегда понимают что нужно делать. Отчасти это связано с некоторой текучкой кадров, опять же по исходной причине, видимо. Более профессиональная команда у нас будет приносить явно большую пользу, т.к. проект свой, долгосрочный, растущий, и даже если зарплата у членов команды увеличится в 1.5 раза, проект от этого выиграет во много раз. Т.к. сейчас уже задачи делаются не так быстро как на старте, команда пухнет от кол-ва разработчиков, с соответствующими издержками на коммуникацию и обмен знаниями и т.д.
Здравствуйте, sdf, Вы писали:
sdf>Здравствуйте, michael_isu, Вы писали:
_>>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
sdf>Ваша должность в коллективе? Какие полномочия и обязанности?
Ведущий программист. Структура такая — тех. директор -> тим лид -> ведущие разработчики и мидлы. Напрямую я решать ничего не могу, но некоторый вес у меня все же есть и я могу продавливать некоторые решения и практики, которые будут использоваться во всей команде.
sdf>Если разработчик — валить в места, где таких вопросов не возникает
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, pkl, Вы писали:
pkl>>Решается тестовым заданием на пару недель.
_>Не решается. Тестовые задания никто не делает. Студенты не нужны.
Вот кто не делает, тот и не работает.
Но часто бывает так, что такой шаблон искореняется у горе-программиста где-нибудь на подсознательном уровне, приэтом порождая ещё более извращённые кодовые конструкции в ближайщем будущем. 
