Споры с разработчиками
Резюме?
Да блин - пусть делают что хотят! Потом человек сам наступит на свои грабли, и можно его будет пнуть побольнее 
Вообще лучший вариант здесь - переделывает код тот, кому он не нравится.
Вообще лучший вариант здесь - переделывает код тот, кому он не нравится.
Да блин - пусть делают что хотят! Потом человек сам наступит на свои грабли, и можно его будет пнуть побольнеено по шапке-то будет получать руководитель, а не этот деятель.
Прямо наболело! 
Мне кажется, для демонстрации преимуществ одной концепции над другой нужно заиметь два модуля в проекте, каждый из которых реализует свою концепцию (пусть даже они будут на разной логике а затем их сравнивать - как удобно здесь и как неудобно там.
Мне кажется, для демонстрации преимуществ одной концепции над другой нужно заиметь два модуля в проекте, каждый из которых реализует свою концепцию (пусть даже они будут на разной логике а затем их сравнивать - как удобно здесь и как неудобно там.
ты руководитель - за тобой и должно быть последнее слово.
т.е. подход примерно такой: мы обсудили, к сожалению, к общему варианту не пришли: поэтому надо поступить следующим образом - вот эти куски надо написать помоему, а вот это может делать по своему варианту.
параллельно надо делать две вещи:
1. зарабатывать авторитет. помогая в разборе ошибок, признавая, что у кого-то предложение лучше.
2. вырабатывать описание своего подхода, и постоянно его пропагандировать.
т.е. подход примерно такой: мы обсудили, к сожалению, к общему варианту не пришли: поэтому надо поступить следующим образом - вот эти куски надо написать помоему, а вот это может делать по своему варианту.
параллельно надо делать две вещи:
1. зарабатывать авторитет. помогая в разборе ошибок, признавая, что у кого-то предложение лучше.
2. вырабатывать описание своего подхода, и постоянно его пропагандировать.
для начала выпиши хотя бы приоритеты в порядке убывания важности
укладывание в сроки
универсальность
гибкость
скорость
надежность
повторность использования
время исправление ошибки
и т.д.
и объясни всем почему именно этот порядок важен на вашем участке
дальше при разборе того или иного кода можно уже будет опираться на эти приоритеты
укладывание в сроки
универсальность
гибкость
скорость
надежность
повторность использования
время исправление ошибки
и т.д.
и объясни всем почему именно этот порядок важен на вашем участке
дальше при разборе того или иного кода можно уже будет опираться на эти приоритеты
Ты описываешь ситуацию, когда тимлид лучше разработчика понимает, что и как правильнее делать.
Есть же еще руководители, которые хуже разработчиков разбираются в предмете. Против таких руководителей по-любому у разработчика нарастает некоторая бронебойность, которую пробить не так просто
Нужно значит искать правильные аргументы. Или строго разделять проектирование и собственно разработку (кодирование).
Есть же еще руководители, которые хуже разработчиков разбираются в предмете. Против таких руководителей по-любому у разработчика нарастает некоторая бронебойность, которую пробить не так просто
Нужно значит искать правильные аргументы. Или строго разделять проектирование и собственно разработку (кодирование).
но по шапке-то будет получать руководитель, а не этот деятель.Правильно. Поэтому обычно говорится "под твою ответственность". Это типа тоталитарная демократия - предлагаешь свое решение, будь готов потом защищать его до конца.
Ага!) А потом этот "ответственный" разработчик уйдет, а геморрой с его кодом останется.
обычно говорится "под твою ответственность"
Это типа тоталитарная демократия - предлагаешь свое решение, будь готов потом защищать его до конца.Ты такое в реальности наблюдаешь или чисто теоретические рассуждения? часто четко указать "конец" нельзя. У нас манагер с подобной философийе выступал, по прошествию нескольких лет, видно, что он начинает пересматривать эту философию.
Правильно. Поэтому обычно говорится "под твою ответственность". Это типа тоталитарная демократия - предлагаешь свое решение, будь готов потом защищать его до конца.он, говорит - хорошо.
а через год, до сих пор все работает через пень колоду, но при этом ты его еще и уволить не можешь (потому что в этом бардаке кроме него никто не хочет разбираться а вынужден даже повышать зарплату.
Мне мой руководитель говорил, что если навязывать правильные способы кодирования, то многие имеющиеся в наличии разработчики перестанут писать полезный код, а будут в основном заняты раздумьями на тему как писать правильно и все равно будут писать с бОльшим количеством ошибок, чем если бы писали как привыкли.
Мне мой руководитель говорил, что если навязывать правильные способы кодирования, то многие имеющиеся в наличии разработчики перестанут писать полезный кодчто-то бред какой-то.
с такими же аргументами, можно сказать, что русский язык учить не надо, или там ПДД.
Ты такое в реальности наблюдаешь или чисто теоретические рассуждения? часто четко указать "конец" нельзя.Это абсолютно реальная схема. Правда, речь идет о высоком уровне разработчиков.
Мне мой руководитель говорил...типичные рассуждения теоретиков
Что ты понимаешь под теоретиками? Не уверен, что по твоему определению окажется теоретиком.
типичные рассуждения теоретиковЕсли бы. Я все-таки попробовал. Попросил пару разработчиков провести серию семинаров. В результате один из разработчиков, к которому и претензий-то не было, вместо простого и понятного кода, такое нагородил в попытке использования новых для него технологий, что сам обнаружить и исправить ошибки не мог.
Я ограничиваюсь рекомендациями и поощрениями тех, кто по-моему пишет правильно. Настаиваю на правильных решениях только в критических случаях и с новичками.
Слава богу, кода нового мы пишем немного (всего ~20000 на проект в 30 человеко-месяцев, и во многом это простые операции над картинками и числами) и он хорошо разделен. По большому счету не очень важно, как разработчик пишет свою часть, если у нее простой интерфейс, есть регулярное тестирование и кода в ней не много (основное время тратится на придумывание и опробовыние разных версий алгоритмов, реализация конечного варианта может быть очень минимальной). А то бы с таким мягким подходом к дисциплине кодирования наша фирма бы не выжила.
но при этом ты его еще и уволить не можешь (потому что в этом бардаке кроме него никто не хочет разбираться)Не знаю о чем ты, увольняли таких без разговоров.
Принцип простой - если кого-то не устраивает качество кода, то пусть он его и переделывает. Такие вещи у нас поощрялись. Видишь чужие ошибки - тебя повышают. Все просто.
Привить человеку свои навыки нельзя. Можно в тоталитарном режиме бегать и каждого направлять, но это ИМХО нереально (у нас "поток" кода даже в среднем проекте такой, что один человек в нем просто утонет).
Что ты понимаешь под теоретиками?теоретик в данном контексте тот, кто управляет людьми, а не кодом. Кто о патернах читал в книжках, или не видел как они в реальности приносят пользу.
Но лично о -е по одному утверждению, я никаких выводов не делаю.
Терки о прекрасном коде - неизбежное зло. Делается очень просто - из команды выбираются наиболее адекватные люди, с ними ведутся эти терки. Если люди выбраны правильные, терки рано или поздно кончатся. Теперь с этими людьми можно писать базовые части приложения (персистенс модель/не дай бог кастом имплементейшен ОРМа/етц/етц).
Остальной код отдавать "обезьянкам", которые уже пусть пишут как хотят, в случае чего их странные техники будут боле мене локализованы, и большую часть времени в своем странном коде обезьянки будут копаться сами.
Главное смириться с тем, что никогда весь код не удастся (да и не нужно) сделать прекрасным, и начать искать компромиссы.
Остальной код отдавать "обезьянкам", которые уже пусть пишут как хотят, в случае чего их странные техники будут боле мене локализованы, и большую часть времени в своем странном коде обезьянки будут копаться сами.
Главное смириться с тем, что никогда весь код не удастся (да и не нужно) сделать прекрасным, и начать искать компромиссы.
Еще добавлю две вещи, которые помогают жить:
1. обязательный code review со стороны одного из членов "ядра команды". Без approval-а нельзя засабмитить в систему контроля версий
2. не апрувить код, который сделан в другой философии, нежели основная часть проекта. Аргументация простая: кодировать можно по-разному, но в рамках одного приложения код должен быть консистентным.
1. обязательный code review со стороны одного из членов "ядра команды". Без approval-а нельзя засабмитить в систему контроля версий
2. не апрувить код, который сделан в другой философии, нежели основная часть проекта. Аргументация простая: кодировать можно по-разному, но в рамках одного приложения код должен быть консистентным.
Мне кажется, для демонстрации преимуществ одной концепции над другой нужно заиметь два модуля в проекте, каждый из которых реализует свою концепцию (пусть даже они будут на разной логике а затем их сравнивать - как удобно здесь и как неудобно там.Как показывает практика, это не часто помогает. Вот пару примеров из моей текущей работы:
1. Споры с сишником по поводу удобности всяких С++-ных штук над С-шными.
Пример:
Весь его код выглядит примерно следующим образом (при этом может быть дохрена вызовов функций внутри одной функции):
status_t st = Func;
if (st == e_fail)
return st;
st = Func2;
if (st == e_fail)
return st;
Бросать исключения его фиг заставишь, хотя разница, по-моему, очевидна:
Func;
Func2;
2. Есть еще любитель COM-а. COM у нас не используется, но интерфейсы он пишет дерьмо-стиле COM'а. На мое предложение сделать для его библиотечки (это завертка для еще более дерьмового интерфейса
) из такого использования:
int res = 0;
CHECK(obj->GetInt(&res) == s_ok)
std::cout << res << std::endl;
На такое (для (может только?) меня гораздо более правильное и удобное):
std::cout << obj->GetInt << std::endl;
Аргументировались тем, что COM придумали крутые кексы, которые знают, как нужно программировать и что нужно делать именно так, а не по какому-то моему беспонтовому варианту, абсолютно не принимая убогость COM-ового варианта и тот факт, что COM у нас не используется и можно писать на нормальном C++.
их странные техники будут боле мене локализованывидимо у вас отличные от нас типы приложений. В случае заказного бизнес ПО требования заказчика реализуются как раз "остальным кодом". Локализована как раз реализация персистенс модели. А вот техники, которые применяются для реализации бизнес-логики и UI-я, размазаны по всему приложению, собственно это и есть суть приложения с точки зрения конечного пользователя. Поэтому качество приложения сильно зависит от этих техник.
Аргументировались тем, что COM придумали крутые кексы, которые знают, как нужно программировать и что нужно делать именно тактак объясни ему, что даже стандартный студийный генератор при вставке com-овской либы делает вызовы именно в твоем стиле, пряча всю эту фигню с HRESULT во внутрь.
так объясни емуЯ стока времени на это потратил, пытаясь объяснить всеми мне известными способами, потом понял, что это бесполезно и смирился, чтобы не тратить свои нервы
Если С-шник начнет использовать исключения, то ему придется избавиться от malloc'ов и освоить конструкторы/деструкторы. Требовать переходить на исключения - опасно. Пусть лучше постепенно отвыкает от использования указателей, чем привыкает к исключениям.
В результате один из разработчиков, к которому и претензий-то не было, вместо простого и понятного кода, такое нагородил в попытке использования новых для него технологий, что сам обнаружить и исправить ошибки не мог.дык, понятно, что первый блин часто бывает комом.
надо непросто рассказать про новые технологии, но и делать первое время плотный code review.
ps
очевидно, что C-ишнику рассказать про C++, то он на C++ будет стараться использовать старые приемы от C, и будет получаться что-то страшное
то же самое, например, при переходе допустим с C++ на C# и т.д.
Если С-шник начнет использовать исключения, то ему придется избавиться от malloc'ов и освоить конструкторы/деструкторы. Требовать переходить на исключения - опасно. Пусть лучше постепенно отвыкает от использования указателей, чем привыкает к исключениям.В том-то и дело, что там развитие остановилось на промежуточной стадии (хотя, я все равно это называю сишником). В данном случае, используется new. Он даже знает, что нужно использовать для его стиля использовать небросающий исключения new
Бросать исключения его фиг заставишь, хотя разница, по-моему, очевидна:Может быть, нужно дать ему задание написать аналогичный правильному варианту код (похожий модуль реализовать, например)? Может, он проникнется и станет писать иначе. Я так понимаю, что зачастую дело в незнании того, как устроен процесс. если это так, то человеку действительно трудно писать что-либо, когда он не знает, что именно происходит. В таких случаях нужно отправлять читать книжки.
В нашей фирме тоже наблюдается такая проблема, но она в основном потому, что, наверное, никто внимательно не читал книгу по плюсам и просто не умеет пользоваться инструментарием. Люди боятся писать наследование, потому что не знают из какого класса будет вызываться функция! Им понятнее написать огромный switch, после чего они считают, что все контролируют.
Если бы я был его начальником, я бы заставил так делать - пусть переучивается. Но я не его руководитель, да и руководителю приходится с ним повоевать часто, чтобы заставить что-то переделать: мой модуль работает и ниипет, а то, что система в связке нихрена не работает, из-за того, что связка эта хреновая, ему пофиг - подстраивайте свои модули под меня
>но и делать первое время плотный code review
Отсутствие регулярных обзоров кода - это моя серьезная (к счастью, не фатальная для нашей разработки) ошибка.
В любом случае, просто советовать и настаивать на правильном варианте нельзя. Нужно еще потом его и поддерживать самому пока разработчик в полной мере не научился. Честно говоря, проще следить за соответствием ТЗ и стабильностью, чем за реализацией. Хотя в долгосрочной перспективе от такого контроля выигрыш, верю, будет.
PS. Я пробовал пару раз делать обзоры кода (один раз своего и один раз чужого но до регулярного обсуждения не дошло. Раньше у меня (и вобще не было "правильного" программиста в моем подразделении) не было достаточного опыта (можно сказать, я из тех руководителей, которые недостаточно компетентны в программировании, а были назначены за неимением альтернативы). А сейчас уже руки не доходят. Привык, честно говоря, что каждый сам что-то там у себя ваяет. Надеюсь, буду исправляться.
Отсутствие регулярных обзоров кода - это моя серьезная (к счастью, не фатальная для нашей разработки) ошибка.
В любом случае, просто советовать и настаивать на правильном варианте нельзя. Нужно еще потом его и поддерживать самому пока разработчик в полной мере не научился. Честно говоря, проще следить за соответствием ТЗ и стабильностью, чем за реализацией. Хотя в долгосрочной перспективе от такого контроля выигрыш, верю, будет.
PS. Я пробовал пару раз делать обзоры кода (один раз своего и один раз чужого но до регулярного обсуждения не дошло. Раньше у меня (и вобще не было "правильного" программиста в моем подразделении) не было достаточного опыта (можно сказать, я из тех руководителей, которые недостаточно компетентны в программировании, а были назначены за неимением альтернативы). А сейчас уже руки не доходят. Привык, честно говоря, что каждый сам что-то там у себя ваяет. Надеюсь, буду исправляться.
Какой софтиной такую схему проще и удобнее организовать?
У нас на perforce система OWNERS на папки. Для code review используется внутренняя тулза mondrian. Некое (правда, жалкое) ее подобие ща работает на code.google.com
разработка тикета в отдельном бранче
ревью бранча или руками или любой софтиной (например crucible от atlassian)
права на мердж только у людей, делающих аппрув
ревью бранча или руками или любой софтиной (например crucible от atlassian)
права на мердж только у людей, делающих аппрув
Сложновато.
Тогда уж git можно юзать.
Тогда уж git можно юзать.
Можно и гит. Можно отказаться от бранчей.
Вообще лучший вариант здесь - переделывает код тот, кому он не нравится.Т.е. если мне не нравится, как пишут подчиненные, я должен за каждым переделывать? По-моему не в этом смысл моей работы.
Ты, кажется, не понял. Речь как раз о подчиненных. Пусть переделывают код друг друга.
Хорошо, если аттрактор у этого процесса - точка Иначе начальству придется вмешиваться.
Иначе начальству придется вмешиваться.Сначала несколько тезисов:
1. Для большинства задач существует несколько решений
2. Оценка качества решения существенно субъективна
3. Большинство возможных решений каждой конкретной задачи не являются "лучшими" с точки зрения каждого конкретного субъекта
Это значит, что практически всегда, на решение, предложенное другим, я могу предложить решение, которое, с моей субъективной точки зрения, лучше.
Если я буду на каждое чужое решение предлагать своё и потом доказывать, что оно лучше, то у окружающих сложится мнение, что: "что бы мы не предложили, ему всё равно не понравится". А если моя оценка чужого решения всегда негативная, то ценность такой оценки для других нулевая. Они и так, не спрашивая меня, знают, что решение мне не понравится, а поэтому и спрашивать не будут.
С другой стороны, если я буду доказывать, что моё решение лучше, только в тех случаях, когда (пункты связаны по "И", а не по "ИЛИ"):
1. Оно лучше чужого по всем параметрам. Именно по всем, а не по большинству
2. Оно существенно (в разы) лучше чужого решения
а во всех остальных случаях буду просто предлагать, но не продвигать (описал своё предложение в виде текста с картинками, послал по почте и забыл то у окружающих сложится мнение, что: "всё, что он предлагает, это айс!". И тогда даже к решениям, изложенным по принципу написал и забыл, будут прислушиваться.
Эта тактика опробована и на начальниках и на коллегах и на подчинённых и она работает.
1. Для большинства задач существует несколько решений
2. Оценка качества решения существенно субъективна
3. Большинство возможных решений каждой конкретной задачи не являются "лучшими" с точки зрения каждого конкретного субъекта
Это значит, что практически всегда, на решение, предложенное другим, я могу предложить решение, которое, с моей субъективной точки зрения, лучше.
Если я буду на каждое чужое решение предлагать своё и потом доказывать, что оно лучше, то у окружающих сложится мнение, что: "что бы мы не предложили, ему всё равно не понравится". А если моя оценка чужого решения всегда негативная, то ценность такой оценки для других нулевая. Они и так, не спрашивая меня, знают, что решение мне не понравится, а поэтому и спрашивать не будут.
С другой стороны, если я буду доказывать, что моё решение лучше, только в тех случаях, когда (пункты связаны по "И", а не по "ИЛИ"):
1. Оно лучше чужого по всем параметрам. Именно по всем, а не по большинству
2. Оно существенно (в разы) лучше чужого решения
а во всех остальных случаях буду просто предлагать, но не продвигать (описал своё предложение в виде текста с картинками, послал по почте и забыл то у окружающих сложится мнение, что: "всё, что он предлагает, это айс!". И тогда даже к решениям, изложенным по принципу написал и забыл, будут прислушиваться.
Эта тактика опробована и на начальниках и на коллегах и на подчинённых и она работает.
Спасибо за отклики. В общем, ситуация реально осложнена тем, что многие вещи придётся выкидывать из проекта или переделывать. Разработчики месят этот код уже три года, и очень ревностно относятся к критике. Пока что я убедил только директора по IT и старшего руководителя проектов. Разработчики реально считают, что GUI с табами снизу, сверху и вертикально слева - классный, надо только к нему привыкнуть.
Действительно, придётся зарабатывать авторитет. Но я пока что не могу найти точек соприкосновения, потому что вещи, за которые можно похвалить, найти обычно тяжелее, чем ляпы.
Действительно, придётся зарабатывать авторитет. Но я пока что не могу найти точек соприкосновения, потому что вещи, за которые можно похвалить, найти обычно тяжелее, чем ляпы.
А ты первое время никого не трогай.
Возьми какую-то небольшую часть, которая доставляет начальству проблемы и найди хотя бы одного из команды, который готов меняться. Сделай эту небольшую часть хорошо, устранив при этом проблемы. Существенно, если ты это будешь делать не один: можно будет не говорить "гля какой я крутой", а похвалить того, с кем ты работал.
Дальше продолжай потихоньку захватывать мозг людей.
Возьми какую-то небольшую часть, которая доставляет начальству проблемы и найди хотя бы одного из команды, который готов меняться. Сделай эту небольшую часть хорошо, устранив при этом проблемы. Существенно, если ты это будешь делать не один: можно будет не говорить "гля какой я крутой", а похвалить того, с кем ты работал.
Дальше продолжай потихоньку захватывать мозг людей.
GUI с табами снизу, сверху и вертикально слева - классныйМожет быть действительно классный. Смотря что за табы и что делают.
Сравни с тем же эклипсом или идеей, где некое подобие табов есть со всех четырех сторон.
Разработчики реально считают, что GUI с табами снизу, сверху и вертикально слева - классный, надо только к нему привыкнуть.Я тупой или вам нухно дизайнера интерфейса в проект к разработчикам добавить?
или вообще хоть какого-нибудь дизайнера, раз такие загоны.
Проектировщика интерфейсов. И желательно, чтобы он начал с основ. Ибо наверняка выяснится, что половина системы никому нафиг не нужна -)
Речь как раз о подчиненных. Пусть переделывают код друг друга.Это как-то грустно, сплоченную команду такими методами не получишь. И на проекте с жестким дедлайном огребешь срыв сроков. Да и команда будет на взводе и друг на друга огрызаться.
это как Джобс с Macintosh vs. everybody
Идеология Йордона мне больше нравится
Оставить комментарий
kokoc88
Как известно, даже на позиции team lead или руководителя проекта лучше договариваться с подчинёнными разработчиками. Административный overrideСамый неопровержимый аргумент, с которым приходится сталкиваться: "Всё, что ты предлагаешь сделать так, я могу сделать и эдак."
Саботаж сроков - второй аргумент, который мне очень не нравится: "Я уверен, что по-своему напишу код быстрее, чем по-твоему."
Ещё бывают бессмысленные абстракции: "Да, мы могли бы написать правильный код, но потеряли бы универсальность".
Плохо, когда в дело вступает откровенное враньё: "Когда-то я делал по-твоему, но получилось плохо, и я пришёл к выводу, что мой подход лучше."
Особенно тяжело, когда для человека не существует никаких авторитетов, даже написанное в книжке ставится под сомнение или отрицается как более сложное решение.
И самая большая проблема. Убедить разработчика в том, что его пусть падающий вот уже два года, но более-менее рабочий