Привет, All!

Есть большая система (дотнет, С#), в которой периодически требуется чего-то дорабатывать. Документации в виде диаграмм классов на 90% нет (прописаны только Xml-комменты для классов, методов). Есть (грубо говоря) один опытный разработчик, и несколько "джуниоров". Владение кодом совместное. То есть теоретически любой человек разбирается в любом месте системы (на деле не разбирается )

Сейчас работа делается так — то, что требует вмешательства в архитектуру, опытный разработчик делает сам, а все доработки по мелочам — джуниоры. Не устраивает то, что количество работы непропорционально имеющимся ресурсам — джуниорам чаще отдыхать приходится, хотя дел — вагон. Плюс, хотелось бы чтобы опытный разработчик выполнял в данной системе роль архитектора, т.е. определял, каким именно образом нужно вносить изменения в существующую архитекуту, а джуниоры — кодеров, т.е. просто выполняли бы его предписания.

Так вот какой вопрос. Если мы возьмем для примера стандартный RUP, то там вне зависимости от сложности задач дела найдутся всем — инженеры собирают требования, аналитики анализируют, архитекторы рисуют архитектуру, кодеры её реализуют, тестеры — тестируют. Все при деле, загружены задачами, соотвествующими их уровню, и никто не простаивает.

В нашем случае, если разрабатывается новый функционал, то вопросов нет, опытный разработчик нарисует диаграмму классов, отдаст её джуниору, тот её реализует. (остальные звенья цепи я не рассматриваю). А как быть, когда функционал уже существуетт и его надо модифицировать? Работы по переделке не так много, но главное сделать это ПРАВИЛЬНО. Зачастую получается, что надо потратить день на то чтобы разобраться, что и как, и потом написать 3 строчки кода. (это я утрирую, соотношение "въезжание"/"решение задачи" может быть разным, от 0 до бесконечности Джуниор, естественно, правильно решить, в какое место вносить изменения, не может. Что ему делать, должен сказать опытный разработчик. Но это сводится к постоянному контролю, что снижает производительность пары архитектор(в лице опытного разработчика)-кодер(в лице джуниора) до уровня кодера, хотя один проектировщик должен давать работу как минимум нескольким кодерам

У меня пока только одна более-менее реальная идея — нарисовать более-менее полную диаграмму классов, и на них отмечать, какие методы надо добавить, какие убрать итд. Минус в том, что при поддержке актуальной документации для постоянно развивающегося проекта потери от оверхеда будет не факт, что меньше, чем от простоев разработчиков. Плюс — что после того как вся документация будет написана, оверхед уменьшится.

Есть вторая идея, прогнать джуниоров, и нанять вместо них опытных разработчиков, но проблемы, которые при это возникнут, понятны всем. К тому же, даже если это получится, все равно будут задачи, для которых "взрослого" разработчика слишком много — опять потери в эффективности.

Третья идея — ввести раздельное владение кодом, что позволит уменьшить затраты на "въезжание" в требующую модификации область системы. Но это мне нравится еще меньше, так как в данном случае уменьшается контроль друг за другом (в случае совместного владения один человек не напишет "кривой" код, зная, что это может потом дорабатывать другой, который выскажет все, что он думает по поводу плохого стиля программирования), появляются проблемы при увольнении сотрудников, трения в смежных модулях, когда причину ошибки два разработчика валят друг на друга, итд



Есть какие-нибудь мысли по данному поводу? Кто как решает у себя данную задачу?

ЗЫ. Сорри за длинное вступление, надеюсь что кто-то дочитает это до конца

Здравствуйте, Sshur, Вы писали:

Создается впечатление, что у вас просто очень сильная диспропорция между джуниорами и сильными программистами. А возможно, просто недостаток документации и фактически документацией выступает ваши опытные разработчики. И время опытных разработчиков тратиться очень неэффективно.
Сделайте оценку сколько времени и на что тратит опытный девелопер и джуниор. Прямо по часам и по минутам. Только объясните для чего это делается. А то толку никакого не будет, более того, воспримут все в штыки. Это поможет вам выявить слабые места. После этого можно думать о мерах по устранению этих слабых мест.

Здравствуйте, Sshur, Вы писали:

выгоните нафиг всех ждуниоров кроме 1-2, на которых сваливать всю грязную и скучную работу.
вместо выгнанных джуниоров наймите необходимое количество синиоров.

У нас в отделе разработки примерно такая же проблема. Остался один разработчик из создателей софта, документации ноль, и необходимо вести доработку. Пока склоняемся попробывать парное кодирование по XP. Кроме того дали задание разработчику в разумном виде разложить схему базы данных(там просто мрак) и основные компоненты (объекты) и взаимодействие между ними...Сложно пока этот процесс идет.

Здравствуйте, MaximVK, Вы писали:

MVK>Здравствуйте, Sshur, Вы писали:

MVK>Создается впечатление, что у вас просто очень сильная диспропорция между джуниорами и сильными программистами. А возможно, просто недостаток документации и фактически документацией выступает ваши опытные разработчики. И время опытных разработчиков тратиться очень неэффективно.

Ну да, проблема в недостатке опыта у джуниоров. Хотелось бы максимально использовать возможности сениора по принятию ключевых для архитектуры решений. Даже если джуниор прекрасно понимает как работает существующая версия системы,то он просто не поймет как и что нужно изменить, чтобы реализовать новые требования, а даже если найдет какой-то способ, то с вероятностью 90% это будет ужасно с точки зрения архитектуры.

MVK>Сделайте оценку сколько времени и на что тратит опытный девелопер и джуниор. Прямо по часам и по минутам. Только объясните для чего это делается.

Учитывая, что я и есть тот самый сениор, то с этим проблем не будет. И кто на что свое время тратит, мне тоже более-менее видно. Ситуация такая- если дать джуниору конкретное задание в пределах его компетенции, то все делается быстро и настолько качественно, насколько позволяет его уровень.
А если этот уровень превысить, то тут уже начинаются тормоза,связанные с непониманием того что надо сделать и как. Кончается все тем, что я сажусь рядом и "вытаскиваю" его, говоря что делать и где. Эта "планка" известна для каждого человека, и проблема в том, что найти задания, подходящие каждому, не всегда получается Если нанять одних опытных разработчиков, то, возможно, такой проблемы не будет, но это не в моей компетенции

Как процесс разработки должен выглядеть в идеале для моего случая? По разделению обязанностей понятно, что сениор должен принимать принципиальные решения по поводу внесения изменений, а джуниоры — их непосредственно реализовывать,но вот как это формализовать?

Хотя, я уже начитаю склоняться к мысли, что в задаче поддержки сложной системы джуниорам вообще не место...

Здравствуйте, pvnic, Вы писали:

P>Здравствуйте, Sshur, Вы писали:

P>выгоните нафиг всех ждуниоров кроме 1-2, на которых сваливать всю грязную и скучную работу.
P>вместо выгнанных джуниоров наймите необходимое количество синиоров.


Это конечно решит проблему Но хотелось бы построить такой процесс разработки, в котором внесение изменений укладывалось в цикл анализ-проектирование-разработка-тестирование, где на этапе разработки джуниор вполне уместен. Под джуниором я имею в виду не начинающего студента, а просто разработчика, уровень знаний которого недостаточен для принятия решений об архитктуре системы.

S>Есть большая система (дотнет, С#), в которой периодически требуется чего-то дорабатывать. Документации в виде диаграмм классов на 90% нет (прописаны только Xml-комменты для классов, методов). Есть (грубо говоря) один опытный разработчик, и несколько "джуниоров". Владение кодом совместное. То есть теоретически любой человек разбирается в любом месте системы (на деле не разбирается )

S> Сейчас работа делается так — то, что требует вмешательства в архитектуру, опытный разработчик делает сам, а все доработки по мелочам — джуниоры. Не устраивает то, что количество работы непропорционально имеющимся ресурсам — джуниорам чаще отдыхать приходится, хотя дел — вагон. Плюс, хотелось бы чтобы опытный разработчик выполнял в данной системе роль архитектора, т.е. определял, каким именно образом нужно вносить изменения в существующую архитекуту, а джуниоры — кодеров, т.е. просто выполняли бы его предписания.

Pair Programming пробовали? У нас оно не применяется особо часто, но именно в подобных ситуациях pairing на час-два в день помогает очень быстро передавать информацию. Разумеется, только при условии что оба участника пары не против попробовать. Pair programming из под палки может превратиться в "один пишет код, второй тупо в него смотрит"

Здравствуйте, _doctor, Вы писали:

_>Pair Programming пробовали? У нас оно не применяется особо часто, но именно в подобных ситуациях pairing на час-два в день помогает очень быстро передавать информацию. Разумеется, только при условии что оба участника пары не против попробовать. Pair programming из под палки может превратиться в "один пишет код, второй тупо в него смотрит"

Парное программирование дает эффект, если есть сложная задача и два более-менее равных по уровню программиста. В моем же случае более опытный будет писать весь код, а новичек тупо смотреть.

Правда, когда новичек заходит в ступор, парным программированием все и заканчивается, но этого как раз я и хотел бы избежать

Здравствуйте, Sshur, Вы писали:

S>Парное программирование дает эффект, если есть сложная задача и два более-менее равных по уровню программиста. В моем же случае более опытный будет писать весь код, а новичек тупо смотреть.

Наш опыт прямо противоположен — парность помогает очень быстро перекачивать знания в новичка. "Один пишет, второй тупо смотрит" — вообще не очень о парном программировании. Такие впечатления я тоже встречал, но чаще всего в тех случаях, когда "просто" велели заняться "pair programming", не объясняя, что это такое.

S>Есть большая система (дотнет, С#), в которой периодически требуется чего-то дорабатывать. Документации в виде диаграмм классов на 90% нет (прописаны только Xml-комменты для классов, методов).

И не нужна почти нигде. Диаграммы — это костыли для мозга. Дидактический материал.

Профессионал ходит без костылей (ну или почти без ).

S> Сейчас работа делается так — то, что требует вмешательства в архитектуру, опытный разработчик делает сам, а все доработки по мелочам — джуниоры. Не устраивает то, что количество работы непропорционально имеющимся ресурсам — джуниорам чаще отдыхать приходится, хотя дел — вагон.

У меня возникло впечатление, что у вас неправильно подобран персонал в вопросе соотношения количества джуниоров и сениоров. Нужно больше сениоров и меньше джуниоров. Растите джуниоров, а тех, что не растут — гоните.

Поддержка существующего кода — почти всегда задача для сениора.

S>В нашем случае, если разрабатывается новый функционал, то вопросов нет, опытный разработчик нарисует диаграмму классов, отдаст её джуниору, тот её реализует. (остальные звенья цепи я не рассматриваю). А как быть, когда функционал уже существуетт и его надо модифицировать?

Для начала выкинуть RUP в помойку как оторванную от реальности башню из слоновой кости.

Следом — понять, что такие модификации есть дело практически только для сениоров.

S>Работы по переделке не так много, но главное сделать это ПРАВИЛЬНО.

Конечно. Все очень, очень знакомо.

S>Зачастую получается, что надо потратить день на то чтобы разобраться, что и как, и потом написать 3 строчки кода. (это я утрирую, соотношение "въезжание"/"решение задачи" может быть разным, от 0 до бесконечности

Да, все так.

S>Джуниор, естественно, правильно решить, в какое место вносить изменения, не может. Что ему делать, должен сказать опытный разработчик.

Да. Еще раз да.

S>Но это сводится к постоянному контролю, что снижает производительность пары архитектор(в лице опытного разработчика)-кодер(в лице джуниора) до уровня кодера

Потому вывод — гоните такого кодера и возложите его обязанности на все того же архитектора, благо там 3 строчки кода писать (главное — понять, как).

S>, хотя один проектировщик должен давать работу как минимум нескольким кодерам

Это практически не выполняется при доработках существующего кода. Только при написании с нуля.

S>У меня пока только одна более-менее реальная идея — нарисовать более-менее полную диаграмму классов, и на них отмечать, какие методы надо добавить, какие убрать итд. Минус в том, что при поддержке актуальной документации для постоянно развивающегося проекта потери от оверхеда будет не факт, что меньше, чем от простоев разработчиков.

Совершенно верно.

S>Плюс — что после того как вся документация будет написана, оверхед уменьшится.

Нет. Поддержание ее в постоянно актуальном состоянии — это оверхед навсегда.

S>Есть вторая идея, прогнать джуниоров, и нанять вместо них опытных разработчиков, но проблемы, которые при это возникнут, понятны всем.

Мне не понятны. Что я тут вижу? налицо проект, где джуниоры вообще почти не нужны. Нужно меньшее количество и большее качество.

S>К тому же, даже если это получится, все равно будут задачи, для которых "взрослого" разработчика слишком много — опять потери в эффективности.

Вот и поставьте на них последних из неизгнанных джуниоров

S>Третья идея — ввести раздельное владение кодом, что позволит уменьшить затраты на "въезжание" в требующую модификации область системы.

Сколько кода? ИМХО больше, чем несколько мег исходников на одного человека — нереал, и тут надо вводить раздельное владение кодом так, чтобы один вообще просто не занимал ресурсы своего мозга, вникая в implementation details другого.

S>Но это мне нравится еще меньше, так как в данном случае уменьшается контроль друг за другом (в случае совместного владения один человек не напишет "кривой" код,

Состоявшийся спец вообще практически не пишет кривой код

S>появляются проблемы при увольнении сотрудников

Увольте одну сотрудницу — HRку, замените ее нормальной профессионалкой. После этого нужда в увольнениях девелоперов плавно сойдет на нет

S>, трения в смежных модулях, когда причину ошибки два разработчика валят друг на друга,

Ну с этим вообще элементарно разобраться. Эта ситуация как правило означает, что 2 девелопера по-разному поняли контракт между своими 2 модулями. Выслушиваете их, потом решаете, каков должен быть _правильный_ контракт, и доводите до сведения.

В случаях, когда баг, скорее всего, не связан с неверным пониманием контракта — оттестируйте хотя бы 1 из 2 компонентов на тестбеде, и сразу станет ясно, где баг (а если повезет — то и как его править).

S>ЗЫ. Сорри за длинное вступление, надеюсь что кто-то дочитает это до конца

Я дочитал.

MVK>Сделайте оценку сколько времени и на что тратит опытный девелопер и джуниор. Прямо по часам и по минутам.

Категорически не согласен.

Разница джуниора и сениора в том, что джуниор зачастую _в принципе не способен_ правильно решить некоторые задачи (а если способен — то он кандидат на рост в сениоры), а не в темпах бацанья по клавиатуре.

S>А если этот уровень превысить, то тут уже начинаются тормоза,связанные с непониманием того что надо сделать и как. Кончается все тем, что я сажусь рядом и "вытаскиваю" его, говоря что делать и где.

Совершенно верно. На самом деле паттерн вида "сениор, бегающий от джуниора к джуниору, помогающий им не упираться в особо сложные моменты, проволакивающий через них и тратящий на это львиную долю своего времени" — эдакий паттерн сениора-визитора — тоже вполне работоспособен.

S>возможно, такой проблемы не будет, но это не в моей компетенции

Аааа.. ну ясно.

S>Как процесс разработки должен выглядеть в идеале для моего случая?

См. первый абзац. Паттерн "сениор-визитор". Но тут придется смириться с тем, что у сениора почти не останется времени на свой собственный код.

S>Хотя, я уже начитаю склоняться к мысли, что в задаче поддержки сложной системы джуниорам вообще не место...

Ну в общем да. На самом деле человек, который способен с ходу взять почти любой код, быстро в нем разобраться и исправить его для соответствия новым требованиям минимально кровавым образом — это третий этап профессионального роста после кодера и архитектора.

S>Это конечно решит проблему Но хотелось бы построить такой процесс разработки, в котором внесение изменений укладывалось в цикл анализ-проектирование-разработка-тестирование,

А не приходило в голову, что этот цикл — только один из возможных паттернов, а есть и другие?

Скажем, при правке особо сложного бага этап "проектирование" вообще не существует, а этап "разработка" зачастую сводится к одной правке одной строчки.

S>Под джуниором я имею в виду не начинающего студента, а просто разработчика, уровень знаний которого недостаточен для принятия решений об архитктуре системы.

Ну да. Это и есть определение понятия "джуниор". Это может быть студентик, а может — и нет.

Здравствуйте, Sshur, Вы писали:

Условие:
Есть сеньоры в количестве X штук.(X=1)
Есть джуниоры в количестве Y штук.
Каждый джуниор требует T процентов времени сеньора(выделение и формализация задачи, разъяснение, контроль). Для успешной работы нужно, чтобы выполнялось условие: 100*X/T <= Y. Сейчас это условие ложно, работа неэффективна.

Что делать?
Варианта три.
1. Уменьшать T
2. Уменьшать Y
3. Увеличивать X

Я бы на твоем месте выбрал наиболее талантливого джуниора и взялся бы его интенсивное обучение. Таким образом, через некоторое время количество сеньоров увеличится в два раза, а количество джуниоров на одного уменьшится.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Категорически не согласен.
MSS>Разница джуниора и сениора в том, что джуниор зачастую _в принципе не способен_ правильно решить некоторые задачи (а если способен — то он кандидат на рост в сениоры), а не в темпах бацанья по клавиатуре.

Максим, позвольте спросить, а что это за хитрая цепочка рассуждений привела тебя от моего поста к твоему ответу?

S>Есть какие-нибудь мысли по данному поводу? Кто как решает у себя данную задачу?

У нас всё просто: если я встречаю не верные на мой взгляд конструкции или проектные решения и думаю, что человек справится с переделкой в заданном мной ключе, говорю — "На **я до**я *****чили? Рас***чивай на***!" и работа кипит.

Хорошие джуниоры имеют тенденцию быстрого профессионального роста.
Плохих — под зад ногой.

В корне не согласен с 90% суждений.
Сам в шоке

MVK>Максим, позвольте спросить, а что это за хитрая цепочка рассуждений привела тебя от моего поста к твоему ответу?

Вами было предложено померять время исполнения задания джуниором и сениором.

Мне сразу пришло в голову, что мерять время исполнения _простых_ заданий сениором — глупо, ибо сениор не этим ценен. А мерять время исполнения сложных задач джуниром — невозможно, потому что джуниор "ниасилит".

Мой ответ был уже на основании вот этого понимания.

Здравствуйте, Sshur, Вы писали:


S>Есть какие-нибудь мысли по данному поводу? Кто как решает у себя данную задачу?

Классическое решение:
Разбить систему на компоненты и нанять больше опытных девелоперов, каждому поручить компонент.
И поддерживать документацию в актуальном состоянии.