Здравствуйте, Tom, Вы писали:
Tom>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>И вообще если есть идеи — то велкам.
Personal Software Process... будь он неладен.
Лучший дар, который мы получили от природы и который лишает нас всякого права жаловаться – это возможность сбежать. /М.Монтень/
Здравствуйте, Tom, Вы писали:
Tom>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>И вообще если есть идеи — то велкам.
— code review.
— unit test тоже хорошо работает в этом направлении.
— Можно метрики разные считать, если есть кому этим серьезно заниматься.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Tom, Вы писали:
Tom>>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>>И вообще если есть идеи — то велкам.
B>- code review. B>- unit test тоже хорошо работает в этом направлении. B>- Можно метрики разные считать, если есть кому этим серьезно заниматься.
допустим core review есть
так же допустим unit test-ы тоже есть
ещё идеи? Особенно интересна мотивация людей на написание кач. кода, а не "главное что бы отстали". Когда есть мотивация, то и ревью делать можно реже... Да и юнит тесты человек будет сам нормальные писать
Здравствуйте, Tom, Вы писали:
Tom>ещё идеи? Особенно интересна мотивация людей на написание кач. кода, а не "главное что бы отстали". Когда есть мотивация, то и ревью делать можно реже... Да и юнит тесты человек будет сам нормальные писать
Мотивация — штука сложная. Тулами и процессом (PSP?) ее не поднимешь.
Тут надо просто работать с коллективом.
Один знакомый руководитель как-то сказал,
что ну нету у него идей, как сделать так,
чтобы у людей заблестели глаза.
На что другой предложил просто налить водки
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, Tom, Вы писали:
Tom>>ещё идеи? Особенно интересна мотивация людей на написание кач. кода, а не "главное что бы отстали". Когда есть мотивация, то и ревью делать можно реже... Да и юнит тесты человек будет сам нормальные писать
B>Мотивация — штука сложная. Тулами и процессом (PSP?) ее не поднимешь. B>Тут надо просто работать с коллективом. B>Один знакомый руководитель как-то сказал, B>что ну нету у него идей, как сделать так, B>чтобы у людей заблестели глаза. B>На что другой предложил просто налить водки
Этот вариант рассматривается (это не шутка) — бесплатное пиво по пятницам, по окончании проекта так же...
Здравствуйте, Tom, Вы писали:
T>>Personal Software Process... будь он неладен. Tom>Можно по подробнее?
Watts Humphrey, Carnegie-Mellon, PSP.
Если интересно — можешь найти в инете по этим ключевым словам(да и на рсдн-е где-то было обсуждение). На английском информация есть, на русском не встречал.
Кратко — следуя PSP(если модифицировать "под себя") можно:
1) довольно точно оценивать размер/время на разработку
2) оценивать количество дефектов, уменьшать их общее количество, убирать на ранних фазах
Всё это — основываясь на некоторой исторической базе (своего рода твоей истории как разработчика) и чёткому разграничению процесса разработки по фазам.
Процесс довольно нормально применяется не только к имплементации, но и к написанию требований, дизайна и т.п.
Но PSP — тяжеловесный процесс. Довольно много времени будет уходить на поддержку самого процесса.
И необходимо ПО для него.
Лучший дар, который мы получили от природы и который лишает нас всякого права жаловаться – это возможность сбежать. /М.Монтень/
Здравствуйте, _-_, Вы писали:
_-_>Здравствуйте, bkat, Вы писали:
B>>На что другой предложил просто налить водки
_-_>Лучше дать процент с прибыли компании. Маленький — но дать. Интерес сразу появится, и безо всякой водки.
Здравствуйте, Tom, Вы писали:
Tom>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>И вообще если есть идеи — то велкам.
Как один из вариантов, когда твой код смотрят еще несколько человек , то появляется мотивация не ударить в грязь лицом , повыпендриваться. В любом случае откровенную лажу писать не хоцеца !
Здравствуйте, Tom, Вы писали:
Tom>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>И вообще если есть идеи — то велкам.
Здравствуйте, _-_, Вы писали:
_-_>Здравствуйте, bkat, Вы писали:
B>>На что другой предложил просто налить водки
_-_>Лучше дать процент с прибыли компании. Маленький — но дать. Интерес сразу появится, и безо всякой водки.
Акции? Вроде в некоторых забугорных компаниях это практикуется.
Только тут такой момент.
Если интерес будет существенным, то я лучше устранюсь от программинга,
найму на эти деньги другого, а сам буду заниматься чем-то другим
В целом я не верю, что деньги могут долго стимулировать программера.
Опять же, уровень доходов компании увы не зависит на прямую от качества кода.
Иначе програмеров повсеместно перевели бы на процент от прибыли,
как это часто делают с теми кто продает и заключает контракты.
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, Tom, Вы писали:
Tom>>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>>И вообще если есть идеи — то велкам.
M>Как один из вариантов, когда твой код смотрят еще несколько человек , то появляется мотивация не ударить в грязь лицом , повыпендриваться. В любом случае откровенную лажу писать не хоцеца !
Здравствуйте, Tom, Вы писали:
Tom>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>И вообще если есть идеи — то велкам.
1. Code Review
2. На всю компанию работает централизованная система bug tracking. Соответственно баги могут находить совершенно разные люди, которые даже случайно воспользовались нашими компонентами. А раз баг учтён, то его сразу и надолго видно. Хошь не хошь, а приходится исправлять. Напрямую это на качество кода не влияет, но как только в каком-то компоненте появляется много критических багов, появляется повод обратить внимание на причины
3. Довольно заметная часть премии зависит от результатов сдачи проекта
4. Довольно заметная часть премии зависит от финансовых результатов фирмы. Так как практически все наши компоненты долго живут внутри компании, это заставляет писать "на перспективу" — если поторопиться и тяп-ляп сдать текущий проект, в будущем это может обернуться не очень.. выгодно.
5. Code conventions — код документирован и написан более-менее одинаково
6. Biweekly builds всего-всего с приложенным исходным кодом. В результате иногда баг-репортеры указывают что пошло не так и советуют как исправить. Не напрямую связано с качественным кодом, но всё-таки ещё один уровень контроля.
7. Документация выдаваемая "наверх" прочитывается специальным отделом на соответствие если не смыслу, то правильности/стандартности структуры — облегчает чтение документации. Необходимость писать её заставляет немного хоть разбираться с кодом
8. Возможность посоветоваться с соседом
9. Что-то ещё..
Ну а если выделять главное, то: чудесный коллектив, code review, централизованный баг-tracking
Здравствуйте, Tom, Вы писали:
Tom>Скажите какие в вашей компании предпрениваются меры для повышения качества самого кода. Tom>И вообще если есть идеи — то велкам.
Наиболее исчерпывающий ответ, на мой взгляд, дал _doctor. Некоторые добавления по моему опыту:
Юнит-тестирование, безусловно, вещь хорошая, но себестоимость такого тестирования достаточно высока. Я не рекомендовал бы юнит-тестирование для краткосрочных проектов.
А вот баг-трекер и специально выделенные тестеры зарекомендовали себя превосходно в проектах любого типа. Разработчик, сам тестирующий свой собственный код — плохой тестер. Доказано статистикой.
Очень часто требования к единообразию кода в проектах опускаются. И зря. Если девелоперы пишут в слишком разном стиле, то наладить совместное владение кодом будет очень сложно и процент багов будет выше.
Лично я практиковал такой подход: в начале проекта несколько наиболее опытных программистов реализуют небольшую часть системы, в которой стараются предусмотреть все, что понадобится (грамотное разделение приложения на слои, структуру библиотек, систему именования переменных, технику обработки и логгирования системных ошибок, технику применения сторонник библиотек и т.п.) Результат выносится на всеобщее обсуждение. Любой член команды обязан исследовать результат и может внести свои предложения и замечания, решение будет принято коллективно. Таким образом, даже молодые программисты могут повлиять на проект. Психологически для них это очень важно. Плюс молодые сразу учатся писать грамотно, изучая примеры более опытных. Когда все согласовано (и, желательно, зафиксировано в спецификациях), то уже никто не имеет право пороть отсебятину. Если кто-то хочет что-то поменять в спецификациях, архитектурном каркасе, стилевом оформлении — только через PM-а и, возможно, всеобщее обсуждение. Кто-то (PM, сеньор, тестер) должен контролировать качество кода. Несканционированный отход от спецификаций — по шапке.
Таким образом, в разрабатываемой системе получается поддерживать очень высокий уровень единообразия. Приложение имеет хорошо продуманную архитектуру. Любой член команды может практически моментально сориентироваться в чужом коде, поскольку этот код похож на его собственный. Девелопер может фиксить чужие баги с более высокой скоростью, избегая наведенных ошибок. Потеря члена команды проходит без особого ущерба.
Вообще говоря, такая стратегия разрабатывалась как альтернатива парному программированию в XP. Парное программирование, как и юнит-тестирование, стоит дороговато, хотя и дает более качественный результат.
Недостаток подхода — на начальном этапе (неделя-две) прогресс по проекту бывает очень вялым, это напрягает, если cроки проекта сжатые. Вероятно, подход не очень подходит для больших команд.
Ну да, и ещё unit tests
Уж не знаю к сожалению или к счастью, они используются не очень широко. Природа разрабатываемых конкретно нами компонентов такова, что часть функциональности практически невозможно проверить тестами, а часть сложно (читай "некогда"). Тесты в основном используются.. теми, кому это удобно То есть поддержка по их использованию есть, поощрение со стороны руководства тоже, а реально пишут их те, кто пишет "utility-like" модули.
И ещё вспомнил. PC-Lint очень поощряется. Благо он неплохо встроен в среду и начать им пользоваться очень легко. Реально пользуются.. те, кто хочет, но это практически все
