adva писал(а):
Не совсем по теме:
Хотел бы узнать, кто какие методологии разработки использует? И какие плюсы/минусы видите.
До сих пор работал в не очень крупных конторах, в которых как таковых методологий никаких не использовалось (ну или я не увидел чего). Т.к. в основном задачи были сравнительно мелкие и более по сопровождению, а не по разработке, то вполне без них обходились. Но сейчас хотел бы выйти в этом вопросе на новый уровень (для чего возможно и место работы попробую сменить, чтобы было где опыта набраться, ну или еще какое решение придумаю). Как успел пообщаться с одной вроде бы серьезной в этом плане конторой, они используют гибкую методологию (конкретно скрам, или как он там). Ранее я как-то ненадолго сталкивался с такой системой (не скрам вроде бы, но какая-то из гибких методологий), но мне показалось, что в таком методологии производятся скорее некачественные решения, которые также достаточно сложно поддерживать. Кто что может сказать по этому поводу?
Вы говорите про методологии психологического давления/развития на/для подчинённых.
А если говорить про анализ качества кода то:
Одним статическим анализатором не обойтись, нужен динамический.
Так же для скриптовых языков JS, Python, Ruby, Perl есть статические анализаторы кода и стиля.
Сейчас даже компиляцию люди запускают в облоках, а заодно и тесты.
https://travis-ci.org/OpenBazaar/OpenBa ... s/35491781Klocwork - кажется давно в облаке.
ncc (бесплатно, строит Call граф),
Coverity prevent,
pmccabe (бесплатно),
klocwork (то что нужно, но за деньги),
Rhapsody (это модель, это правильно но надо делать с начала проекта)
http://docs.pylint.org/run.html (статический анализатор кода для Python)
http://alternativeto.net/software/resharper/Memory Test (DUMA/DML/VALGRIND)
А так же специальные тесты которые делает программист заказчика. Обычно их сотни, и фактически они и задают ТЗ.
Так же есть методология работы корпорации Самсунг Электроникс, за которой следит группа Проект Проджект Менеджеров в SMRC и HQ (я являюсь экспертом (4 ранг в SE) этой группы, а так же группы по Тайзен/Андроид) , основанная на строгой последовательности в работе над проектом с очередными этапами, полным документированием и отчётами. Информация об этой технологии не является открытой. Но то что указано выше - открытые инструменты, которые используются в процессе выпуска промышленного кода.
В последнее время входит в моду формальная верификация на основании модели.
1. Модель это по сути формальное описание активности всей программы. Вот на этот аргумент и надо напирать при спорах о достоинствах Актив Оберона.
2. Юнит-тестирование ( Модульное тестирование встронно в Aктив Оберон - пример:
http://lists.inf.ethz.ch/pipermail/ober ... 07998.html )