Здравствуйте, 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, Вы писали:
_>Проблема такая — в команде низкая культура разработки. Такое ощущение что мало кого интересует профессиональный рост, люди часто делают копипаст (вместе с комментами), вместо того чтобы написать по-людски, никто не хочет писать юнит-тесты. Да и вообще мало кто любит думать (хотя наверное склонность к лени — свойство человека) Как быть? Какими методами решаете такие проблемы? Как поднимаете культуру? Делимся опытом
Вам культуру или ехать? Нет потребности — нет культуры.
), и я чуть было даже не купился на ловушку аспирантуры с реальным преподаванием. Хорошо, вовремя остудила необходимость подстраивать расписания на работе и в универе.
