Здравствуйте, Maxim S. Shatskih, Вы писали:
N>>И поддерживать документацию в актуальном состоянии.
MSS>
MSS>Есть такая компания — Microsoft. Они этого не делают. Не сказал бы, чтоб были не успешны.
Это потому что индусы не читатели — индусы писатели
))
Здравствуйте, Maxim S. Shatskih, Вы писали:
MVK>>Максим, позвольте спросить, а что это за хитрая цепочка рассуждений привела тебя от моего поста к твоему ответу?
MSS>Вами было предложено померять время исполнения задания джуниором и сениором.
MSS>Мне сразу пришло в голову, что мерять время исполнения _простых_ заданий сениором — глупо, ибо сениор не этим ценен. А мерять время исполнения сложных задач джуниром — невозможно, потому что джуниор "ниасилит".
MSS>Мой ответ был уже на основании вот этого понимания.
Надо читать внимательней. А то можно много чего еще домыслить.
Сделайте оценку сколько времени и на что тратит опытный девелопер и джуниор.
Где здесь про время исполнения заданий? Речь идет о структуре занятости сеньора и джуниора. Т.е. ответ на вопрос: кто и на что тратит время. Когда подобная статистика будет собрана — можно узнать очень много интересного. Пока такой статистики нет, пытаться оптимизировать процесс — все равно, что искать не там где потерял, а там где светло.
MSS>>Есть такая компания — Microsoft. Они этого не делают. Не сказал бы, чтоб были не успешны.
N>Это потому что индусы не читатели — индусы писатели
Ядро виндов писали не индусы (или по крайней мере очень продвинутые индусы). Там та же петрушка.
Например, документацию по ядру в MSDN пишет команда DDK support, которая отлична от команды самого ядра. Зачастую в документации огрехи. Их быстро правят, но факт этот говорит о многом — код первичен, MSDN вторичен.
S>>Есть вторая идея, прогнать джуниоров, и нанять вместо них опытных разработчиков, но проблемы, которые при это возникнут, понятны всем.
MSS>Мне не понятны. Что я тут вижу? налицо проект, где джуниоры вообще почти не нужны. Нужно меньшее количество и большее качество.
Проблемы в том, что я сочетаю в себе архитектора/тим лида, на набор людей повлиять могу слабо. Так мы представляем собой IT отдел в транспортной компании, то людей очень мало и основные цели у начальства лежат в иной плоскости. Поэтому, хоть оно понимает важность функционирования корпоративной информационной системы, но просьбы о том, что надо увеличить бюджет, воспринимает без энтузиазма
S>>Третья идея — ввести раздельное владение кодом, что позволит уменьшить затраты на "въезжание" в требующую модификации область системы.
MSS>Сколько кода? ИМХО больше, чем несколько мег исходников на одного человека — нереал, и тут надо вводить раздельное владение кодом так, чтобы один вообще просто не занимал ресурсы своего мозга, вникая в implementation details другого.
Всего получается порядка 3-4 мб *.cs на разработчика, (*.Designer.cs я выкинул) + ХП в БД,+ разные маленькие проекты на С++, PHP, J2ME, VBScript, VBA.
Честно говоря, многовато. Да и чувствуешь себя этаким многостаночником, когда с утра написал какой-нибдуб отчет на SQL, потом скрипты поковырял на VBA, а под вечер реализовал новую фичу на Java. Самая большая проблема — комментарии
S>>Но это мне нравится еще меньше, так как в данном случае уменьшается контроль друг за другом (в случае совместного владения один человек не напишет "кривой" код,
MSS>Состоявшийся спец вообще практически не пишет кривой код
Ну.. в любом случае стоит, чтобы код видело как минимум два человека. Хотя конечно, понять что хотел написать сениор, смотря на его код, гораздо проще, чем в случае с джуниором.
S>>ЗЫ. Сорри за длинное вступление, надеюсь что кто-то дочитает это до конца
MSS>Я дочитал.
Спасибо )
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, VGn, Вы писали:
S>>Есть какие-нибудь мысли по данному поводу? Кто как решает у себя данную задачу?
VGn>У нас всё просто: если я встречаю не верные на мой взгляд конструкции или проектные решения и думаю, что человек справится с переделкой в заданном мной ключе, говорю — "На **я до**я *****чили? Рас***чивай на***!" и работа кипит.
А если я встречаю такие конструкции, и в общем понимаю, что надо сделать, но куда и что нужно написать сказать не могу — надо потратить часа 2, только на то чтобы разобраться что к чему. Других людей способных на это нет. Что остается? Только делать самому.
Наверно, все-таки нужно попытатся изменить кадровую политику....
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
И не нужна почти нигде. Диаграммы — это костыли для мозга. Дидактический материал.
Профессионал ходит без костылей (ну или почти без ).
Человек, наверное не видел БОЛЬШИХ проектов, где схемы — и те на 3-4 уровнях абстракции.
Поддержка существующего кода — почти всегда задача для сениора.
Это как же надо код писать, чтоб поддерживать его смог только сеньор?
Для начала выкинуть RUP в помойку как оторванную от реальности башню из слоновой кости.
И строить свои собственные башни, которые "конечно же лучше".
Следом — понять, что такие модификации есть дело практически только для сениоров.
Ой не цените вы ведущих программистов!
S>Зачастую получается, что надо потратить день на то чтобы разобраться, что и как, и потом написать 3 строчки кода. (это я утрирую, соотношение "въезжание"/"решение задачи" может быть разным, от 0 до бесконечности
Да, все так.
А может что-то не так в консерватории? При правильном проектировании функционал хорошо инкапсулируется в довольно небольших объёмах.
Потому вывод — гоните такого кодера и возложите его обязанности на все того же архитектора, благо там 3 строчки кода писать (главное — понять, как).
Хотя правильно объяснить всё кодеру и делегировать это дело ему получается дешевле.
Это практически не выполняется при доработках существующего кода. Только при написании с нуля.
Если считать, что рефакторинг — это зло.
Нет. Поддержание ее в постоянно актуальном состоянии — это оверхед навсегда.
Если упомянутая документация не понадобится для других задач формализации разработки.
Мне не понятны. Что я тут вижу? налицо проект, где джуниоры вообще почти не нужны. Нужно меньшее количество и большее качество.
Много потраченного бабла и большая текучка сениоров на рутинной работе.
S>Но это мне нравится еще меньше, так как в данном случае уменьшается контроль друг за другом (в случае совместного владения один человек не напишет "кривой" код,
Состоявшийся спец вообще практически не пишет кривой код
3 ха-ха.
А почему бы не владеть кодом небольшими группами программистов? 1-3 Сениора + необходимое кол-во джуниоров на одну подсистему.
При этом некоторые части вполне могут допускать совместное владение 2-мя командами.
S>, трения в смежных модулях, когда причину ошибки два разработчика валят друг на друга,
Ну с этим вообще элементарно разобраться. Эта ситуация как правило означает, что 2 девелопера по-разному поняли контракт между своими 2 модулями. Выслушиваете их, потом решаете, каков должен быть _правильный_ контракт, и доводите до сведения.
S>Наверно, все-таки нужно попытатся изменить кадровую политику....
Или обратить больше внимания на аналитику и проектирование.
Тогда сложности могут исчезнуть практически сами собой.
А могут и не исчезнуть — всё зависит от проекта.
Здравствуйте, VGn, Вы писали:
S>>Наверно, все-таки нужно попытатся изменить кадровую политику....
VGn>Или обратить больше внимания на аналитику и проектирование. VGn>Тогда сложности могут исчезнуть практически сами собой. VGn>А могут и не исчезнуть — всё зависит от проекта.
Может быть. А может и нет Это искусство, написать такую систему, чтобы её можно было понять одним взглядом, и легко внести любые изменения. Мне бы хотелось свести дело к технологии..
Один новичек спросил мастера боевых искусств: Как победить в бою? Мастер ответил, это очень просто: надо попадать по противнику и не дать ему попасть в тебя.
Вот так и здесь — ответы типа "хорошо спроектировать", "написать хорошую документацию" итд, безусловно точны, но бесполезны...
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
