Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Здравствуйте, 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>>Решается тестовым заданием на пару недель.
_>Не решается. Тестовые задания никто не делает. Студенты не нужны.
Вот кто не делает, тот и не работает.
Здравствуйте, michael_isu, Вы писали:
_> А если ему надоест постоянно свое переделывать и он решит сменить работу?
Так даже лучше, и в чём-то даже благородно, ткскзть. Если молодой разработчик наступает на те же грабли в который (далеко уже "энный") раз — есть ли смысл держать его в команде, в которой устоялись свои проверенные временем и командой правила, которых он не понимает / не хочет придерживаться?
Здравствуйте, Цыба, Вы писали:
Ц>Так даже лучше, и в чём-то даже благородно, ткскзть. Если молодой разработчик наступает на те же грабли в который (далеко уже "энный") раз — есть ли смысл держать его в команде, в которой устоялись свои проверенные временем и командой правила, которых он не понимает / не хочет придерживаться?
Описанная проблема — не проблема 1 молодого разработчика, а как минимум проблема 3-4 человек, в т.ч. имеющих статус "ведущий" с вытекающим ЧСВ.
Здравствуйте, michael_isu, Вы писали:
_>Здравствуйте, Цыба, Вы писали:
Ц>>Так даже лучше, и в чём-то даже благородно, ткскзть. Если молодой разработчик наступает на те же грабли в который (далеко уже "энный") раз — есть ли смысл держать его в команде, в которой устоялись свои проверенные временем и командой правила, которых он не понимает / не хочет придерживаться?
_>Описанная проблема — не проблема 1 молодого разработчика, а как минимум проблема 3-4 человек, в т.ч. имеющих статус "ведущий" с вытекающим ЧСВ.
Не понимаю, что именно вы имеете в виду. Здесь присутствует только стремление держать код в чистоте и упрямое нежелание некоторых товарищей соблюдать эти правила ради всеобщего блага.
_>Какими методами решаете такие проблемы?
В случае коммерческой фирмы с наёмными работниками — только сверху. Обладающие культурой должны начальством возвышаться над остальными (подчёркивать их авторитет, назначать на более высокие должности, платить больше денег). Не обладающие (изначально, или утратившие) — понижаться/выгоняться. Для колеблющихся должен быть 1 очевидный путь, которым можно вырасти в этом коллективе.
Здравствуйте, nikov, Вы писали:
N>Здравствуйте, michael_isu, Вы писали:
N>Кстати, по некоторым исследованиям, на рынке труда можно найти разработчиков, готовых работать за вдвое большую зарплату, и при этом приносящих в 10-20 раз больше пользы на работе. Но, к сожалению, их не всегда легко отличить на собеседовании от просто дорогих бездельников.
Полностью согласен. Но:
1) Желающих платить 2х нет, а свалить специалиста на 0.5-0.8х навалом
2) Типичное собеседование с "выучи наизусть все методы и параметры и все задачки-головоломки" отфильтровывает 99.9% таких людей
Как сказано было, низкая культура найма и вечное нежелание платить.
А людей лучше всего искать среди стартаперов. Человек, написавший свой продукт (не код!) с нуля, сам и запустивший его, обладает мировоззрением совершенно другого порядка.
sdf>>Ваша должность в коллективе? Какие полномочия и обязанности?
_>Ведущий программист. Структура такая — тех. директор -> тим лид -> ведущие разработчики и мидлы. Напрямую я решать ничего не могу, но некоторый вес у меня все же есть и я могу продавливать некоторые решения и практики, которые будут использоваться во всей команде.
Валить однозначно. У вас есть только иллюзия влияния на коллектив, реальных полномочий нет. Это самая поганая ситуация. Sad but true.
sdf>>Если разработчик — валить в места, где таких вопросов не возникает _>Валить не вариант пока.
Валить как только сможете. Есть куча мест, где не надо людям объяснять очевдные вещи и как раз нужны те, кому не нравится работатьв бардаке. Пытаясь людей. которых бардак устраивает, из него вытащить (не имя реальной власти) вы только зря потеряете время и нервы.
Re[3]: Низкая культура разработки
От:
Аноним
Дата:
09.06.12 21:41
Оценка:
Здравствуйте, michael_isu, Вы писали:
_>Ведущий программист. Структура такая — тех. директор -> тим лид -> ведущие разработчики и мидлы. Напрямую я решать ничего не могу, но некоторый вес у меня все же есть и я могу продавливать некоторые решения и практики, которые будут использоваться во всей команде.
А нафига еще ведущие разработчики? Вас там что, 200 человек?
Re: Низкая культура разработки
От:
Аноним
Дата:
09.06.12 21:48
Оценка:
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
У меня такая же ситуация, работаю в проекте шесть лет. Ответ: лично вам ничего не сделать. Рыба гниет с головы. Проблема в том, что самое большое начальство должно понимать, что из себя представляет разработка ПО, и почему необходим профессиональный подход. Если оно этого не понимает — все, труба, дальше будет разложение снизу вверх: непрофессиональный менеджер проекта, непрофессиональный тимлид, непрофессиональные разработчик -> в коде помойка, задержка сроков, неуязвимые баги и т.д. Но прогноз необязательно фатальный: вот у нас эта тяжелая болезнь продолжается уже шесть лет, пациент скорее жив, чем мертв, но говнокод множится, и баги становятся все бредовее и тяжелее для фикса, сроки реализации каждой фичи поражают воображение, и сделать с этим ничего нельзя, потому что это система, которая начинается с начальства, неправильно представляющего себе разработку ПО.
_>У нас некий онлайн-сервис, который делается уже 5 лет. И в силу активного роста бизнеса, он постоянно развивается и очень большими темпами. Такими же темпами плодится говнокод.
В этом случае уже практически невозможно взять и все махом покрыть тестами, отревьювить, зарефакторить и т.п.. Моё глубокое убеждение — такие вещи, если они вдруг не начинают выстреливать (как какой-нибудь фейспалм фейсбук), лучше оставить как есть, раз уже 5 лет так развивалось — можно быть уверенным, еще 5 лет будет развиваться. Да, будут баги, недоработки, проблемы. Чтобы у клиентов было меньше проблем, вводите staged solutions (грубо говоря, две параллельно живущие версии, stable и featured, клиенту предоставляется SLA на стабильную, а также возможность с багами, но пользоваться обновленной версией).
_>Начальству нужно потому, что сам тех. дир и тим лид постоянно решают возникающие проблемы, т.к. другие люди не всегда понимают что нужно делать.
Если бы это начальству было надо — думаю, проблема бы решалась. По опыту, на данном уровне развития проекта, начальство хочет набрать как можно больше клиентов и денег с них. "Проблемы мы будем решать потом, по мере их поступления" (С)
_>Более профессиональная команда у нас будет приносить явно большую пользу, т.к. проект свой, долгосрочный, растущий, и даже если зарплата у членов команды увеличится в 1.5 раза, проект от этого выиграет во много раз. Т.к. сейчас уже задачи делаются не так быстро как на старте, команда пухнет от кол-ва разработчиков, с соответствующими издержками на коммуникацию и обмен знаниями и т.д.
Ага, а вы хотите еще больше людей, времени и работы С юнит-тестами и т.п..
В общем, так. Я не в первый раз ваши вопросы вижу, и вы создаете впечатление вменяемого человека. Что бы я посоветовал. Покажите ПРИМЕР. На себе. Сделайте так, как вы бы хотели, чтобы работали и остальные. Остальные либо за вами потянутся, либо вас проклянут (потому что им не хочется работать больше — их устраивает текущий уровень). Там и видно будет, повышение вам светит, али увольнение
Здравствуйте, SkyDance, Вы писали:
SD> В тредстартере, похоже, говорит традиционный для всех людей зуд "хочу сделать как лучше", при этом, к сожалению, тредстартер забывает о субъективности понимания "лучше". Я вот тоже люблю учить (и поучать ), и я чуть было даже не купился на ловушку аспирантуры с реальным преподаванием. Хорошо, вовремя остудила необходимость подстраивать расписания на работе и в универе.
У меня после определенного опыта преподавания... На халяву, учить бывших студентов в коммерческой структуре, если не прописано в должностных обязанностях, нет никакого желания. И если начальство пытается нагнуть меня такими левыми обязанностями — я ухожу... Эт личное мнение
F>У меня после определенного опыта преподавания... На халяву, учить бывших студентов в коммерческой структуре, если не прописано в должностных обязанностях, нет никакого желания. И если начальство пытается нагнуть меня такими левыми обязанностями — я ухожу... Эт личное мнение
Любое занятие приедается, если его сделать работой
Здравствуйте, sdf, Вы писали:
sdf>Валить как только сможете. Есть куча мест, где не надо людям объяснять очевдные вещи и как раз нужны те, кому не нравится работатьв бардаке. Пытаясь людей. которых бардак устраивает, из него вытащить (не имя реальной власти) вы только зря потеряете время и нервы.
Куча мест? Видимо я плохо фильтрую. Как их выявлять на собеседовании?
Здравствуйте, michael_isu, Вы писали:
_>Куча мест? Видимо я плохо фильтрую. Как их выявлять на собеседовании?
Хороший вопрос.
Можно применить тест
Позадавать наводящие впоросы по итогам теста (вроде того, сколько багов в багтрекере и какие правла прхождения ревью кода), пообщаться с людьми, принимающими решения (лидами).
Узнать, какие подукты компания уже выпустила, чем планирует заниматься.
Здравствуйте, Балбес, Вы писали:
Б>А людей лучше всего искать среди стартаперов. Человек, написавший свой продукт (не код!) с нуля, сам и запустивший его, обладает мировоззрением совершенно другого порядка.
Я думаю, что такого человека трудно найти. Мировоззрением-то он должным обладает, но сможет ли он работать на чужую идею/продукт — это вопрос.
Здравствуйте, nikov, Вы писали:
N>Показать людям, что профессиональный рост приведёт к соответствующему вознаграждению. Купить хороших книг по программированию и сделать библиотеку. Нанять в команду ведущего разработчика — настоящего профессионала и энтузиаста, готового обучать и помогать другим. Проводить code review. Поощрять взаимопомощь (может быть, попробовать парное программирование). Для ключевых модулей системы заранее проектировать архитектуру, дизайн и интерфейсы (возможно, нанять хорошего архитектора). Наладить процесс continuous integration — убедиться что есть система контроля версий, багтрекер, на сервере собирается билд и гоняются тесты, при поломках рассылаются e-мэйлы. Поставить на сервер детектилку копипаста, других метрик, измерять, как изменилось покрытие тестами после чекина — если уменьшилось или тесты падают или критически просели метрики — автоматически отклонять чекин. Тех, кто не способен или принципиально не хочет думать — скорее всего, следует уволить.
Это не работает в общем случае и не нужно в конкретном. Если система решает заданные задачи, то "мифический рост" и "качество кода" не нужны.
N>Поставить на сервер детектилку копипаста, других метрик, измерять, как изменилось покрытие тестами после чекина — если уменьшилось или тесты падают или критически просели метрики — автоматически отклонять чекин.
Пробовали. Все забывают о задаче, но активно работают над повышением метрик.
Здравствуйте, michael_isu, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Вам культуру или ехать? Нет потребности — нет культуры.
Но часто бывает так, что такой шаблон искореняется у горе-программиста где-нибудь на подсознательном уровне, приэтом порождая ещё более извращённые кодовые конструкции в ближайщем будущем. 
