Что такое разработка программного обеспечения в вашей компании, как (методологии, инструменты,...)?

Ответ 1

• Test-Driven-Development. Ни в коем случае.
• Разработка домена. Какой дизайн?
• Модель-Driven-Design/Architecture. Какой дизайн? У нас есть команда архитектуры. За одним исключением (самый младший архитектор), они не могли прописать свой выход из бумажного мешка. Тем не менее, они уверены, что рисовали коробки с линиями! И установление дрянных, бесполезных, чрезмерно общих и совершенно бесполезных стандартов. (Старый материал OPC в порядке, но стандарт UA был "выполнен в следующем месяце" в течение последних 4 лет или около того.)
• Вы тестируете?. Да, у нас есть специальная команда для тестирования. Там около 1 тестера на каждые 10-12 разработчиков. Они полностью затоплены. Спросите меня, хорошо ли мы тестируем.
• Тестирование устройств - Полностью неформальный/до разработчика. Я делаю это, когда мне дается расписание.
• Тестирование интеграции - Да. Это необходимо, учитывая набор продуктов, которые мы разрабатываем и поддерживаем.
• Приемочное тестирование. Да, только для контрактной работы.
• Обзоры кодов. Всегда платите за слова, никогда не делайте этого.
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...). Взятие новых зависимостей сильно осуждается. Ускорение никогда не будет принято, например. Мы, как правило, получили удачу в более поздних версиях .Net, хотя обычно 2 года или около того за кривой.
• Agile. Нет. Руководство утверждает, что хочет "проворно", хотя они не демонстрируют более полного понимания того, что это такое. Недавно мы изменили наш процесс, чтобы задачи с более высоким приоритетом были реализованы и реализованы с... (дождаться) более высокого приоритета! Руководство говорит мне, что это наш новый "гибкий" процесс. Тем не менее, он все еще пахнет, идет, и шарлатанцы, как водопад.
• Pair Programming - Ни в коем случае! Платить двум людям, чтобы они работали? Затем вы будете предполагать, что разработчики должны тратить время на бессмыслицу, например, дизайн и обзоры кода. Собаки, кошки, живущие вместе!
• UML - Нет. У нас есть инструмент UML один раз, чтобы помочь нам понять устаревшую кодовую базу, которая сложилась. Лицо, отвечающее за оценку инструмента, любило его, оно обратило дизайн всего миллиона + строк С++ codebase менее чем за 30 секунд! После того, как они поговорили о покупке, и фактические разработчики попытались использовать его, мы обнаружили, что на самом деле им потребовались эти 30 секунд, чтобы не разобрать 95%% кодовой базы. Отчет об ошибках был настолько плохим, что оценщик даже не понял, что он потерпел неудачу. (Я смотрю на вас, малыш!). Нам потребовалось всего полтора года, чтобы обойти наши лицензии для этого, Видеть? Проворный!
• Языки, относящиеся к домену. Они, вероятно, используются где-то, но не сами.
• Спецификация требований (как?). Менеджер продукта выполняет некоторые вуду и изобретает их. Иногда они могут даже поговорить с клиентами о них! Если вам действительно повезло, они даже поймут разницу между вариантом использования и требованием. Не рассчитывайте на это. Мы действительно не используем случаи.
• Непрерывная интеграция. Ни в коем случае. Это гораздо более захватывающе, когда все ломается сразу.
• Инструменты для покрытия кода. Кто-то однажды поставил пустое место на сервере исходного хранилища в холодной, холодной серверной комнате. Это считается?
• Энемическая модель домена. Во всей серьезности я никогда не слышал об этом раньше.
• Связь (Wiki, Mail, IM, Списки рассылки, другие документы) - Заметки. Lotus Notes не выполняет "электронную почту". Букет новомодного мусора.
• Оценки усилий - Не совсем. В моей организации Оценки - это код для целей.. Срок выполнения проекта заперт в течение первого из 5 "быстрых" этапов проекта развития водопада. Эти сроки называются "оценка шаров", но на самом деле означают "даты отправки".
• Размер команды. Запускает гамму на основе продукта. У нас есть команды размером до четырех и до пятнадцати, если вы включаете менеджеров.
• Встречи. Неплохо, если вы относительно младшие и не работаете над более чем одним или двумя продуктами. Мне требуется только 2-3 часа в неделю.
• Показатели кода - Нет.
• Анализ статического кода. Теоретически для .Net b/c FxCop встроен, и он используется по нашему стандарту, но на самом деле нет. Никто не проверяет это b/c, никогда не просматривается код. Просто случайный аудит качества (например, проверка журналов/вины), чтобы убедиться, что мы не теряем сертификацию в этом году.
• Отслеживание ошибок. Да, но только для проблем с сообщением о клиентах. Разработчикам не разрешается отправлять обнаруженные ошибки в отношении продукта, который они работают на b/c, что не является "игроком команды". (Босс моего босса объяснил мне это очень подробно, когда я сделал эту ошибку. Теперь я дружу с конкретным клиентом, который хочет "обнаружить" ошибки, которые я мог бы "случайно" упомянуть в ходе другого связанного с поддержкой сообщения.)

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

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

Ответ 2

Я думаю, что знаменитый Big Ball of Mud описывает много рабочих сред и дает вам несколько хороших идей о том, как бороться с этим видом вещи.

Кстати, я понимаю, что я не отвечаю прямо на ваш вопрос, но Big Ball of Mud преобладает в удручающе большом проценте ситуаций развития. Вы можете спросить о разработке, основанном на тестировании и отслеживании дефектов, и о других вещах такого рода, но если истина будет рассказана из того, что я видел, я бы сказал, что Big Ball of Mud - это фактически де-факто способ, которым работают люди - они должны или не должны.

Ответ 3

• Test-Driven-Development - Почти там.
• Управление доменами - Нет
• Model-Driven-Design/Architecture - Нет
• Вы проверяете? - Да
• Тестирование модулей - Да
• Тестирование интеграции - Да
• Приемочное тестирование - Нет
• Обзоры кодов - Нет
• Инновационные/Новые технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - ASP.NET MVC? NHibernate? Да
• Agile - только что начал
• Программирование пар - Нет
• UML - ничего формального
• Языки, относящиеся к домену - нет
• Спецификация требований (как?) - Да. Захват требований к истории.
• Непрерывная интеграция - Да. TeamCity
• Инструменты покрытия кода - Да. NCover
• Aenemic Domain Model - Нет
• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - IM, Email
• Оценки усилий - 1,2,4,8
• Размер команды - 4
• Встречи - Ежедневная стойка.
• Метрики кода - Нет
• Анализ статического кода - Нет
• Отслеживание ошибок - существующее пользовательское задание

Мой отдел работает в процессе. За последние несколько месяцев я прилагал усилия к постоянному совершенствованию. Некоторым вещам трудно говорить. Однако, оглядываясь назад, они улучшились.

Ответ 4

• Test-Driven-Development: yes
• Управление доменом: да
• Model-Driven-Design/Architecture: yes
• Вы проверяете? да
• Тестирование устройств - да
• Тестирование интеграции - да
• Приемочное тестирование - да
• Обзоры кодов - да
• Инновационные технологии - да
• Agile - исключительно гибкий
• Pair Programming - yes
• UML - иногда для боев ddd для досок.
• Языки, относящиеся к домену - да
• Спецификация требований (как?) - в форме примеров и приемочных испытаний
• Непрерывная интеграция - да - TeamCity
• Инструменты покрытия кода - да - NCover
• Aenemic Domain Model - не уверен
• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - wiki, mail, msn
• Размер команды - 6+ в зависимости от проекта
• Встречи - каждое утро в 9:30 - SCRUM
• Метрики кода - dunno
• Анализ статического кода - dunno
• Отслеживание ошибок - Mantis

И самое главное...

• Каждый отправляется домой в 5:30: ДА

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

Ответ 5

• Test-Driven-Development: Нет. В лучшем случае, в очень маленьких частях. Мы все говорим, но не делаем этого.
• Управление доменом: Нет. Трудно узнать, что такое "домен", если вы разрабатываете техническую структуру. Не много опыта в DDD, чтобы знать, как это сделать.
• Model-Driven-Design/Architecture: Нет.
• Вы тестируете?: Да, но недостаточно. С каждым выпуском (мы пытаемся выпускать небольшие релизы каждые 8 ​​недель) всегда есть более двух релизов. Мы находимся в первом году разработки продукта, поэтому я думаю, что это все в порядке.
• Тестирование устройств: Да. Прибл. 30% охвата. Большинство разработчиков теперь знают, что они должны сами писать тесты. Каждый раз, когда им приходится исправлять критическую ошибку в своем собственном коде, они могут увидеть преимущество, если бы они написали простой тест, чтобы предотвратить ошибку в первую очередь.
• Тестирование интеграции: Да, используя Selenium и WebDriver.
• Тестирование производительности: Да, начиная с этого момента. Цель состоит в том, чтобы архивировать долгосрочные измерения производительности и сравнивать их с выпусками. Для этого используется JMeter и выделенный сервер тестирования производительности.
• Приемочное тестирование: Не очень, но наш продукт также используется внутри, и мы получаем обратную связь довольно быстро, прежде чем он будет выпущен. Я считаю, что это приемочное тестирование.
• Обзоры кода: Нет. Иногда кто-то смотрит на него в течение 30 минут, но это так.
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...): Из моего POV эти технологии уже не являются "инновационными". Сейчас они довольно старые. Кроме JSF, который умер пару лет назад. Был ли Spring + Hibernate в течение последних нескольких лет. Теперь Wicket + WS уже 2 года. Заменен Hibernate на iBatis SqlMaps.
• Agile: Нет.
• Программирование пар: Нет.
• UML: Немного, в основном для диаграмм развертывания. Классовые диаграммы слишком мелкозернистые и часто не синхронизируются с реальностью. Разработчики делают то, что они считают лучшим, а не то, что говорит им UML-диаграмма.
• Языки, относящиеся к домену: Да, мы используем технологию бизнес-правил home-brewn. Это визуальный DSL, который подходит для конечных пользователей. Подобно использованию решений Visio для моделирования.
• Спецификация требований (как?): Нет.
• Непрерывная интеграция: Да. На основе Хадсона и Мавена. Модульные тесты выполняются на каждой сборке. Дополнительные ночные сборки с более подробной отчетностью. Вся команда уведомляется о неудачных сборках (да, они жалуются на слишком много писем, если что-то нарушает цепочку, и все 30 подмодулей получают сбои сборки, например, когда репозиторий Maven недоступен).
• Инструменты покрытия кода: Да. Maven/Cobertura и Sonar.
• Энемическая модель домена: Не знаю, что это должно быть.
• Связь (Wiki, Mail, IM, Mailinglists, другие документы): Wiki, Mail, IM, ежедневные встречи с стойками, руководства Enduser и разработчика, написанные профессиональным/не разработчиком.
• Оценки усилий: Попытка сделать хорошие оценки. Но без reqs они просто грубые оценки. Достаточно хорошо для планирования ресурсов.
• Размер команды: 12
• Встречи: Ежедневный просмотр, ретро каждые 8 ​​недель после каждого младшего выпуска.
• Метрики кода: Сонар. Вы должны соблюдать большинство правил. Не успел переконфигурировать правила в соответствии с нашими потребностями.
• Анализ статического кода: Сонар.
• Отслеживание ошибок: JIRA

Примечания:

• Sonar - это сервер качества кода. Он сочетает в себе инструменты, такие как PMD, Findbugs, Checkstyle и т.д.

Ответ 6

• Test-Driven-Development - Нет
• Управление доменами - Нет
• Model-Driven-Design/Architecture - Нет
• Вы проверяете? - Почти никогда
• Тестирование устройств - почти никогда
• Тестирование интеграции - Нет
• Приемочное тестирование - Нет
• Обзоры кодов - Нет
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - Spring, Hibernate, Wicket
• Agile - Нет
• Программирование пар - Нет
• UML - просто эскизы
• Языки, относящиеся к домену - нет
• Спецификация требований (как?) - Мы получаем огромную спецификацию требований клиентов, и мы используем карты разума для извлечения фактических функций, которые затем оцениваются
• Непрерывная интеграция - Нет
• Инструменты покрытия кода - Нет
• Aenemic Domain Model - Да
• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - Карты разума, Почта
• Оценки усилий - FITA (Finger in the air, см. здесь)
• Размер команды - 2-6
• Встречи - 2-3 раза в неделю.
• Метрики кода - Нет
• Анализ статического кода - Нет (пробовали FindBugs и Checkstyle)
• Отслеживание ошибок - Да, Bugzilla

Ответ 7

Мне жаль вас:) Это не хорошая среда для работы, так как вам нужно постоянно практиковать практические практики, чтобы действительно понять и использовать их.

Я знаю несколько (моих включенных) компаний, которые могли бы пометить все "хорошие" поля в вашем списке.

Однако дьявол подробно и даже в некоторых компаниях с хорошими политиками SDP не каждый проект следует за ними.

Ответ 8

• Test-Driven-Development - Хотя это должно быть, поскольку это было предпринято, чтобы быть вовлеченным, но я не думаю, что это сняло, таким образом это все еще нет, но с более подробной информацией теперь.
• Управление доменами - Нет
• Model-Driven-Design/Architecture - Нет
• Вы проверяете? - Да, но не всесторонне. У нас есть некоторые модульные тесты, некоторые интеграционные тесты и некоторые тесты WatiN.
• Unit Testing - У нас есть некоторые для нашей новой разработки, но унаследованных нет.
• Тестирование интеграции - обычно, когда это применимо. Моя команда, являющаяся веб-командой, похоже, не слишком часто это делает.
• Приемочное тестирование. У нас есть несколько уровней. Во-первых, когда разрабатывается новая функция, и она должна получить первоначальное одобрение от кого-то из другой команды, которая будет вводить контент, который приходит до того, как он даже интегрируется с кодом. Во-вторых, когда функции демонстрируются в конце Sprint, чтобы получить больше отзывов о том, что не выглядит правильно или хорошо работает. Тогда есть третий уровень перед тем, как он выходит в производство в качестве финала: "Да, это не испортит то, что мы уже", что-то вроде.
• Обзоры кодов - они больше не выполняются, но, вероятно, это будет хорошо.
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - В нашем проекте используются некоторые идеи RESTful, и мы используем некоторые функции .Net framework, такие как лямбда-выражения.
• Agile - мы используем Scrum и имеем стойки ups, story board, Iteration Planning Meeting (это действительно для спринта, а не для итерации, которая является 2 спринтами, поскольку после каждой пары спринтов работа показана руководителям и другим отделам другая демонстрация предназначена для архитектора и руководителя команды, входящей в состав.)
• Pair Programming - У нас есть спаривание в большинстве новых разработок, которые не рассматриваются как ворчание. Поэтому для тех, кто хочет работать над частью обучения на сайте, пара будет делать это вместо одного разработчика.
• UML - Нет, и инструмент для UML был удален на наших новых машинах.
• Языки, специфичные для домена. Нет, но есть некоторая терминология, которая является собственными интерпретациями компании, поскольку некоторые имена внутренних продуктов сталкиваются с условиями, которые другие могут использовать для различных вещей.
• Спецификация требований (как?). Это может варьироваться от документа большого слова, описывающего, что нужно сделать для разговоров о том, что делать, а затем попробовать это и попробовать после этого.
• Непрерывная интеграция. У нас есть Cruise Control.Net для нашего CI, который используется, когда мы совершаем изменения кода.
• Инструменты покрытия кода - Нет.
• Aenemic Domain Model - В некоторой степени здесь нет большой модели домена.
• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - В порядке важности: электронная почта, чат, телефон, затем посещение кабины. Существует еженедельная встреча команды с менеджером приложений и ежедневными стендами по большому проекту.
• Оценки усилий - теперь это обычное явление в каждом спринте, хотя иногда это делается путем отправки рассылки для каждого, чтобы поместить в их оценки, что Scrum Master объединяет в себе все результаты, которые мы можем увидеть в конце.
• Размер команды - 5 разработчиков с лидером команды, бизнес-аналитик, который является Scrum Master, тестером для контроля над тем, что у нас есть, и другими вне команды, которые появляются по мере необходимости, включая авторов контента, чтобы фактически использовать систему.
• Встречи - до бизнеса, короткие, эффективные и, как правило, хорошие для общения, когда что-то в настоящее время.
• Метрики кода - Нет, что я знаю.
• Анализ статического кода - Нет.
• Отслеживание ошибок - Центр качества используется для отслеживания дефектов. * Source Control - теперь мы используем Subversion. Для любой функции или ошибки мы создаем новую ветку, чтобы мы могли работать независимо, а наши коммиты не разрушали сборку, поскольку мы над чем-то работаем. Тем не менее, у всех нас есть одна и та же БД для разработки, которая может быть интересной время от времени.
• IDE - Visual Studio 2008 на XP с использованием .Net 3.5 и Sitecore 6.1
• ...

Команда находится на третьем месте нашей команды в течение почти двух лет, когда я был здесь.

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

В течение года было много изменений, когда у нас был вице-президент IS. Производство больше заблокировано, и есть больше работы, чтобы получить выпуск, так как теперь есть процедура списка проверок и больше обручей, которые могут быть полезны.

Ответ 9

• Test-Driven-Development - если вы имеете в виду писать тесты перед кодом, не всегда
• Domain-Driven-Design - не чистый DDD
• Модель-Driven-Design/Architecture - никогда, но действительно НИКОГДА, снова
• Вы проверяете? - да, всегда
• Тестирование устройств - да, всегда
• Тестирование интеграции - это зависит, но мы стараемся избегать их, поскольку они обычно медленны.
• Приемочное тестирование - да, в идеале автоматизированное
• Обзоры кодов - да, это включено в определение done
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - не уверены, что упомянутые технологии новаторские, но да - Spring, Hibernate, WS
• Agile - да, это в моей ДНК
• Pair Programming - не всегда, но да (по новым темам, с новыми членами команды, если они явно заданы)
• UML - немного (т.е. класс или диаграмма последовательности на доске время от времени), только если полезно
• Языки, относящиеся к домену, до настоящего времени не используются.
• Спецификация требований (как?) - легкие спецификации (например, истории пользователей)
• Непрерывная интеграция - конечно (и, согласно нашему определению, код должен быть "интегрирован" )
• Инструменты покрытия кода - да (cobertura), это в определении done
• Aenemic Domain Model - нет, мы стараемся избегать этого
• Связь (Wiki, Mail, IM, Списки рассылки, другие документы) - лицом к лицу, wiki, IM, mail, список рассылки (но мы стараемся избегать текстовых документов)
• Оценки усилий - да, в сюжетных точках на уровне отставания, в часах на уровне итерации.
• Размер команды - 7 +/- 2
• Встречи - да, но только полезный и всегда время в коробке (планирование итераций, ежедневная встреча, демонстрация и ретроспектива).
• Метрики кода - да (циклическая сложность, охват кода, стандарты кодирования, собранные в сонаре).
• Анализ статического кода - да (findbugs, checkstyle)
• Отслеживание ошибок - да, конечно (но мы пытаемся исправить ошибки, как только обнаружим их).

Ответ 10

Я один из двух программистов в небольшой компании-разработчике программного обеспечения с ОЧЕНЬ нетехническими владельцами ( "какой" браузер ", - серьезно спросил на прошлой неделе).

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

Test-Driven-Development - у нашего владельца был плохой опыт или что-то в этом роде. Упоминать тестирование не так, и я бы поклялся, что она действует вне ПТСР.

Управление доменами - Yep.

Модель-Driven-Design/Architecture - Да.

Вы проверяете? - Неа. Тестирование распространяется на персонал по продажам и поддержке и владельцев. Таким образом, ничто не проверяется много раз, когда оно покидает мою машину dev.

Unit Testing - Если я поймаю это, меня могут уволить. И это серьезно - единственное, что могло меня уволить.

Тестирование интеграции - см. "Вы проверяете?"

Приемочное тестирование. Ну, нам нужно развернуть его когда-нибудь, правильно?

Обзоры кодов - никто другой не поймет это. Я видел всех elses. Жаль, что я этого не сделал.

Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - Да. Но я получаю за это. Я "ребенок", который не знает ничего, что не было изобретено за последние десять лет (несмотря на то, что у меня 30 лет и у меня есть "Чтения в системах баз данных" ).

Проворный - я не водопад. Но я тоже не против.

Pair Programming - вы не хотите пытаться поговорить с другим "программистом", который работает в нашей компании.

UML - Нет. Но я рисую на них квадраты с идентификаторами, иногда на моей доске. Боссы вроде этого. Хорошо, что они не более технически склонны, или я бы, вероятно, видел больше ящиков.

Языки, специфичные для домена - Нет.

Спецификация требований (как?) - Нет.

Непрерывная интеграция - Нет.

Инструменты покрытия кода - Нет.

Aenemic Domain Model - Да. Пробовал. Большинство моих ситуаций мне не нравятся и не используют.

Связь (Wiki, Mail, IM, Списки рассылки, другие документы) - Пробовал, не мог получить участие в колледже. У нашей установки MediaWiki все еще есть логотип логотипа по умолчанию.

Оценки усилий - мы должны оценить, как долго каждая работа будет занимать часы. Это то, что клиент получает по счетам. И это то, что мы ожидаем потратить на проект. Мы даже делаем это, когда мы смотрим на новых клиентов и разрабатываем новые приложения с нуля, а также когда исправляем ошибки (да, мы взимаем с клиентов за это), дополнения к функциям и т.д.

Размер команды - 1. И позвольте мне сказать, что это не очень хороший способ работать. Гораздо лучше иметь возможность отказываться от идей других способных программистов в режиме реального времени.

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

Метрики кода - Нет.

Анализ статического кода - Нет.

Отслеживание ошибок - не так много, как должно.

Ответ 11

Я работаю консультантом Ruby on Rails в Брисбене, Австралия.

• Test-Driven-Development. Это очень тяжело в нашем офисе. Не тестирование считается "невероятно глупым". Вы пишете код, как вы обеспечиваете посредством автоматизированного процесса, такого как CI, который он все еще работает? Тесты.

• Вы тестируете?. См. пункт 1.

• Тестирование устройств: все время, используя RSpec. Я "свободно" в Test:: Unit и Shoulda также.

• Тестирование интеграции: снова, все время, огурец.

• Приемочное тестирование. С нашими билетами мы "доставляем" их с Критерии приема. Затем клиент должен либо "Принять", либо "Отклонить" их, выполнив прыгающий шар. Критерии приема имеют бонус, также являющийся тем, на что написаны наши функции Огурца.

• Обзоры кодов и & Pair Progamming: мы пара. Это мгновенная версия обзора кода. Это потрясающе, потому что вы можете сидеть сложа руки и смотреть, как кто-то другой работает, они пишут тест, а затем вы пишете код, чтобы пройти этот тест. Если вы больны, тогда другой человек знает, к чему вы привыкли, и можете спариваться с кем-то другим.

• Инновационные технологии. Поскольку мы используем Rails, мы действительно любим REST.

• Agile. Мы работаем над двухнедельными итерациями, используя Pivotal Tracker.

• Спецификация требований (как?). Используя функции в Pivotal Tracker, клиент может указать, какие требования у них есть, а затем мы их излагаем (как правило, разговаривая с ними) в критерии приемлемости, и, в конечном счете, Real World.

• Непрерывная интеграция. Мы используем сервер CI, который я разработал, называемый construct. Это было построено с идеей быть как Integrity, но с фоновыми заданиями и лучшей поддержкой для веток. Теперь, когда Integrity имеет фоновое построение, все еще существует поддержка ветвления, которая удерживает нас "впереди".

• Инструменты для покрытия кода: RCov иногда. Мы не очень беспокоились о покрытии кода, когда мы тестируем ВСЕ, прежде чем писать. Если он существует, есть что-то, что его проверит.

• Связь (Wiki, Mail, IM, Mailinglists, другие документы). Мы общаемся с нашими клиентами, используя электронную почту в первую очередь, но у нас также есть "standups" с ними, используя Skype. Для этого мы также использовали Basecamp. Я хочу использовать Google Wave для нашего следующего проекта, как небольшой эксперимент. Я думаю, что это было бы очень полезно.

• Размер команды. У нас в нашей команде 4 человека, обычно 2 пары, если только кто-то не болен.

• Встречи. У нас есть "схватка" / "стойка" по утрам, длительностью около 15 минут. Идея этого заключается в том, что вы переходите на то, что вы делали накануне, какие-либо проблемы, с которыми вы столкнулись, что вы собираетесь делать сегодня и что-то "новое и блестящее" вы нашли. Это не должно превращаться в совещание проекта. Если это необходимо, то после завершения.
• Отслеживание ошибок: снова мы используем Pivotal Tracker. Клиент может подать ошибку здесь, а затем (в идеале) написать, как ее дублировать. Затем мы пишем тест, чтобы убедиться, что это никогда не повторится (aka: Regression Testing), и он проходит тот же процесс работы, что и наши функции, мы доставляем и клиент принимает.

Ответ 12

Я работаю на Chillisoft.co.za в Южной Африке

Test-Driven-Development. Мы используем методы разработки, основанные на тестах, поскольку первая книга Кента Бэка применяется во всем. Мы используем NUnit и R # в качестве тестового бегуна.

Вы тестируете?. В дополнение к TDD мы проводим ручное тестирование (Visual), и при необходимости это автоматизировано. Технологии, используемые для автоматизации, зависят от UI Technologies.

Тестирование устройств: см. TDD.

Тестирование интеграции: Да, но мы еще не использовали повсеместно.

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

Обзоры кодов: запланировано раз в два месяца для каждого проекта. Даже те, которые были запрограммированы по парам/пирам.

Pair Progamming. Мы выполняем большую часть нашего кодирования в парах, но есть определенные задачи и некоторые этапы проекта, где это менее эффективно. Что мы делаем, так это во время запуска проекта (первые несколько недель каждой фазы) мы спариваем программу. На заключительных этапах мы этого не делаем. У нас также есть определенное время (8 часов в неделю на одного разработчика), когда мы работаем над проектами с открытым исходным кодом, все они запрограммированы на пару. Все наши машины настроены с помощью нескольких клавиатур и мыши, чтобы обеспечить плавное взаимодействие между разработчиками.

Инновационные технологии. Мы провели большую работу над Habanero и используем эту структуру вдоль с контейнером DI Unity и RhinoMocks.

Agile. Мы используем гибкие философии в течение 8 лет и продолжаем экспериментировать с инструментами и философиями, поскольку мы продолжаем идти по этому пути.

Спецификация требований (как?). Мы записываем истории пользователей (используйте случаи) для следующих итераций в MSWord. Затем мы записываем их в Jeera с оценками усилий и т.д., Которые управляют графиками вытягивания и т.д.

Непрерывная интеграция. В настоящее время мы используем Hudson, который работает поверх SVN.

Инструменты покрытия кода. Мы запускаем покрытие кода для каждого проекта как часть нашей ночной сборки. Мы собрали итоговый отчет в отчеты Hudson, чтобы мы могли отслеживать их каждый день для каждого проекта.

Связь (Wiki, Mail, IM, Mailinglists, другие документы). Очевидно, что мы сообщаем разными способами, у нас есть внутренняя Wiki и т.д.

Размер команды. У нас есть 15 разработчиков программного обеспечения.

Встречи. У нас есть "схватка" каждые утро, продолжающийся около 10 минут.

Отслеживание ошибок. Мы используем разные системы для внутреннего отслеживания ошибок (т.е. во время разработки и внутреннего тестирования) и для внешнего отслеживания ошибок, т.е. ошибок от клиентов. Внутреннее отслеживание (т.е. Во время внутреннего тестирования и dev) используется redmine. Внешнее отслеживание (т.е. Для наших клиентов) мы используем Mantis.

Ответ 13

• Test-Driven-Development - Нет
• Управление доменами - Нет
• Model-Driven-Design/Architecture - Нет
• Вы проверяете? - Иногда
• Тестирование устройств - почти никогда
• Тестирование интеграции - Да
• Приемочное тестирование - иногда
• Обзоры кодов - Только изредка
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - Нет
• Agile - Нет
• Программирование пар - Нет
• UML - на моей панели маркеров, да.
• Языки, специфичные для домена. С++ - это домен, не так ли?
• Спецификация требований (как?) - Я думаю, мы встречаемся с ними.
• Непрерывная интеграция - Да
• Инструменты покрытия кода - Нет
• Aenemic Domain Model - модель домена
• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - электронная почта и Skype. Что такое wiki?
• Оценки усилий - 1-2 дня для любой заданной задачи.
• Размер команды - 2 программиста, 10 инженеров-технологов.
• Встречи - 2 раза в неделю.
• Метрики кода - Нет
• Анализ статического кода - Нет
• Отслеживание ошибок - Нет

Ответ 14

• Test-Driven-Development - Да
• Управление доменами - Нет
• Model-Driven-Design/Architecture - Нет
• Вы проверяете? - Да
• Тестирование модулей - Да
• Тестирование интеграции - Да
• Приемочное тестирование - начато
• Обзоры кодов - Нет
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - Нет?
• Agile - Да
• Pair Programming - Да почти все время
• UML - ничего более формального, чем строки и коробки на досках.
• Языки, относящиеся к домену - немного
• Спецификация требований (как?) - Нет, мы стараемся получать истории пользователей, если это возможно.
• Непрерывная интеграция - Да
• Инструменты покрытия кода - Нет
• Aenemic Domain Model -
• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - Wiki, IM, Email, Word Docs
• Оценки усилий. Мы используем комбинацию размеров футболки (S, M, L, XL и т.д.) и систему очков для спринта по скорости спринта.
• Размер команды - 6- > 8
• Встречи - Ежедневная стойка.
• Метрики кода - Нет
• Анализ статического кода - Нет
• Отслеживание ошибок - Bugzilla/Version One

Ответ 15

• Test-Driven-Development: очень редко кто-то может сделать это для компонента. Кроме того, реализация публичной спецификации, которая поставляется с проверками соответствия, предлагает некоторые из преимуществ TDD, и многие из них продолжаются.
• Управление доменом: нет
• Model-Driven-Design/Architecture: no
• Вы испытываете?: да
• Тестирование единиц: некоторые, хотя и не завершены. Множество компонентов - это библиотеки для использования пользователями. Там тонкая грань между модулем и функциональным тестированием реализации "strlen".
• Тестирование интеграции: на самом деле не так мало между модульными и системными тестами
• Приемочное тестирование: да и подмножества приемочных тестов, используемых в качестве системных тестов.
• Обзоры кода: нет формального процесса, но просматривается некоторый код.
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...): no
• Agile: no
• Программирование пар: no
• UML: no
• Языки, относящиеся к домену: очень редко
• Спецификация требований (как?): вид
• Непрерывная интеграция: нет, но ежедневная сборка и реверсия отказоустойчивых изменений по усмотрению тестирующей команды.
• Инструменты покрытия кода: никаких формальных требований, команда тестирования, как известно, не использует em.
• Aenemic Domain Model: Я даже не знаю, что это такое.
• Связь (Wiki, Mail, IM, Mailinglists, другие документы): все они выбраны ad hoc, за исключением того, что требования и документы дизайна должны быть HTML под контролем источника, а внутренняя документация по интерфейсу создается из комментариев Doxygen в заголовках.
• Оценки усилий: немного
• Размер команды: около 20 программистов, по-разному группируются в составные группы 1-4 человек. Практически никто не работает исключительно над компонентом, чью команду они принадлежат.
• Заседания: еженедельное полное собрание для обмена отчетами о проделанной работе и в противном случае делиться тем, что происходит. Никаких других регулярных встреч для разработчиков: обсуждения по мере необходимости.
• Метрики кода: no
• Анализ статического кода: нет, если вы не считаете -pedantic; -)
• Отслеживание ошибок: Bugzilla, несколько интегрированная с контролем источника

Ответ 16

• Test-Driven-Development - только начало сдаваться, очень доволен этим до сих пор

• Вы проверяете? - Конечно, все делают, кто хочет, чтобы QA смеялся над ними?

• Тестирование единиц измерения - вот уже около 2 лет помогает стабильность и тесты выполняются каждую сборку

• Обзоры кода - здесь и там, особенно с любыми поздними изменениями

• Agile - Love Agile и его repsonsiveness

• Программирование на парах - просто попробуйте в нескольких местах, ранние возвраты обещают

• Непрерывная интеграция - CruiseControl.NET для Win!!! Такая огромная помощь

• Инструменты покрытия кода - всегда во время каждого запуска unit test CC.NET публикует эту информацию в мире

• Связь (Wiki, Mail, IM, Mailinglists, другие документы) - WIKI, IM, Campfire

• Размер команды - маленький, когда команда продуктов становится большой, мы разбиваемся на функциональные команды.

• Встречи - короткие и не часто, с большей вероятностью получат прихожие.

• Метрики кода - только циклическая сложность

• Анализ статического кода - действительно попытка использования этого Больше использования FxCop и VSTS homegrown

• Отслеживание ошибок - TFS для Windows и Traq для Mac

Ответ 17

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

Что касается остальных, я не уверен, правильно ли я занимаюсь "доменами-специфическими языками" или нет, но я использую много автоматически сгенерированного кода для захвата повторяющихся вещей в своей работе - я считаю 9 Perl скрипты, генерирующие почти 100 000 строк кода.

В остальном размер команды всегда один. Я использую PC-Lint для анализа статического кода один раз в год. Я использую gprof и valgrind довольно сильно (вы, кажется, не упомянули об этом классе инструментов). Я уже много лет пытаюсь найти правильную систему отслеживания ошибок, но я все еще использую программное обеспечение для списка дел и электронную почту, чтобы справиться с этим в данный момент.

Ответ 18

• Test-Driven-Development: нет.
• Управление доменом: нет
• Model-Driven-Design/Architecture: мы начинаем с моделей для наших приложений.
• Вы проверяете? да. Иногда я единственный человек, который проверяет мои вещи. Я ненавижу это.
• Тестирование устройств - нет. Это недостающая область в моем наборе навыков, которую я считаю приоритетным для запоминания.
• Тестирование интеграции - нет
• Приемочное тестирование - иногда. Жесткий, чтобы пользователи могли пройти с ним, даже с угрозами от On High.
• Обзоры кодов - нет. Мы обсуждали это, но никогда этого не делаем. Я разочарован этим.
• Инновационные технологии - нет
• Agile - мы мягко подвижны, хотя не точно через предварительно медитированное усилие.
• Pair Programming - no
• UML - столько, сколько нам нужно, но мы делаем модель (мы более умышленно проворны здесь).
• Языки, специфичные для домена - нет
• Спецификация требований (как?) - мы делаем. Моя группа иногда несет основную ответственность за сбор требований. Обычно нам помогает Biz Analyst, но это не всегда так. Вид иногда вручает нам требования, которые исходят из того, что я не знаю, где. Иногда это старые вещи, которые никогда не делались, но планировались веками назад. обычно собранные требования помещаются в документ Word, рассмотренный основными пользователями, а также моей командой, Biz Analyst и Veep.
• Непрерывная интеграция - nope
• Инструменты покрытия кода - нет
• Aenemic Domain Model - Я не знаком с его, но нет.
• Связь (Wiki, Mail, IM, Списки рассылки, другие документы) - просто электронная почта и лицом к лицу. Я затронул эту тему недавно, потому что нам нужно сделать что-то большее, вики предпочтительнее. Он был помещен на задний план.
• Оценки усилий - да, но мы не пытаемся их действительно отслеживать. Это еще одна область, где мне не хватает.
• Размер команды - 3, включая меня (Director < - Leader Leader < - Me).
• Встречи - мы встречаемся раз в неделю, хотя и не всегда. Босс обычно проверяет, по крайней мере, несколько раз в неделю по отдельности. Большие групповые встречи проходят спорадически. И, конечно же, мы планируем встречи с необходимостью изложения требований проекта по мере необходимости.
• Показатели кода - нет
• Анализ статического кода - nope
• Отслеживание ошибок - мы регистрируем ошибки. что в значительной степени наше отслеживание ошибок.

Что это. У нас есть районы, в которых я чувствую, что мы можем улучшить.

Update:

Мы потеряли нашего бизнес-аналитика до большого увольнения через пару недель после того, как я опубликовал это (начало ноября 08). С тех пор я реализовал ELMAH в существующем приложении и недавно разработанный, чтобы помочь в отслеживании ошибок (мы также заходим в базу данных), и я люблю его для удобства использования, особенностей и способности улавливать исключения, которые мы имеем (t catch catch catch.............). Я все еще по-прежнему держусь за Unit Testing самостоятельно - мне действительно нужно поднять темп там (я также хочу изучить MVC, но я в основном тоже обманываю это).

Мы разрабатываем новое приложение прямо сейчас, и я делаю макетную схему БД (которая получит некоторые основные диаграммы) для 3 из 6 модулей (руководитель группы работает над другими 3). Я не с нетерпением жду этого, так как это будет развиваться в тандеме тремя из нас (по 2 модуля каждый) с помощью IronSpeed ​​Designer (6.1). Есть вещи, которые IronSpeed ​​будет делать для меня, что мне нравится, но это не единственный способ быстро сделать это, и он делает некоторые вещи, которые мне не нужны.

Ничего другого не изменилось.

Ответ 19

Моя компания перешла на большинство методологий "модного слова". Единичное тестирование, разработка, основанная на тестах, Scrum, Agile, непрерывная интеграция, анализ кода и т.д. Я нахожу, что мы прыгаем от продукта к продукту, так как размеры группы меняются с экономикой. После много увольнений мы перешли от Rally Dev/Scrum к Jira/Agile. Мы используем Selenium для автоматического тестирования, но теперь смотрим на Tellenium и Google WebDriver.

Что мы находим? Сайты, прошедшие каждый созданный для него тест (включая нагрузочное тестирование), могут быть невероятно неэффективными, когда они действительно проанализированы. После анализа производительности кода мы смогли сократить серверные ресурсы на 2/3 для одного из наших сайтов и все еще имели лучшую производительность. Он по-прежнему прошел те же тесты.

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

Я работал в крупных и малых компаниях, использующих много разных технологий. Включая простое "ковбойское кодирование". Было много ошибок, когда мы не применяли методологии планирования и тестирования, но мы продвигались намного быстрее. Мы отбросили изменения и исправления в часы, а не дни и неделю.

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

Ответ 20

• Test-Driven-Development - Нет, специально.
• Domain-Driven-Design - Нет, мы все еще выясняем домен.
• Model-Driven-Design/Architecture - Nope
• Вы проверяете? - Мы тестируем сборки и проверяем пользователей.
• Unit Testing - ничего формального (нет nUnit и т.д.)
• Тестирование интеграции - Нет
• Приемочное тестирование - Да
• Обзоры кода - Случайно.
• Инновационные технологии - случайные инструменты SharePoint.
• Agile - Да
• Программирование пар - Нет
• UML - Никогда
• Языки, специфичные для домена - Nope
• Спецификация требований (как?) - Мы сохраняем свет на этом и повторяем. У нас есть BA, который анализирует некоторые требования, но обычно мы просто приглашаем клиента на наши планы и ежедневные встречи, когда мы идем. Нет официальных документов.
• Непрерывная интеграция - Да (cruisecontrol.net)
• Инструменты покрытия кода - Нет (но мы используем анализ кода Visual Studio)
• Связь - Outlook
• Оценки усилий - приблизительный, удвоить его, затем снова удвоить.
• Размер команды - 2-4
• Встречи - каждый день в 9 утра (схватка!) плюс еженедельное совещание по планированию/обзору.
• Метрики кода - Нет
• Отслеживание ошибок - Bugzilla
• Контроль источника - SVN

Ответ 21

Вот мои наблюдения:

• Test-Driven-Development: No

• Домен-дизайн: Да

• Модель-Driven-Design/Architecture: Да

• Вы проверяете?: Да

• Тестирование модулей: Да

• Тестирование интеграции: Да

• Приемочное тестирование: Да

• Обзоры кодов: Нет

• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST, ...): Да

• Программирование Agile Pair: Нет

• UML: Да

• Языки, специфичные для домена: Да

• Спецификация требований (как?) Да

• Непрерывная интеграция: Да

• Инструменты покрытия кода: Нет

• Aenemic Domain Model: Нет (что мы подразумеваем под этим?)

• Связь (Wiki, Mail, IM, Mailinglists, другие документы): Wiki, Mail, IM, Mailinglists

• Оценки усилий: Да

• Размер команды: 2-4 участника

• Заседания: каждый понедельник фиксирует встречи и плавающие встречи на следующий день

• Метрики кода: Да

• Анализ статического кода: Нет

• Отслеживание ошибок: Да

Ответ 22

Вы посмотрели NDepend? Инструмент анализирует С# и .NET-код и предлагает множество интересных функций для просмотра результатов анализа. С NDepend вы можете писать правила по коду, вы можете сравнить 2 версии базы кода, и вы можете использовать более 80 кодовых показателей.

Кроме того, инструмент поставляется с несколькими замечательными функциями визуализации, такими как:

График зависимости:

Матрица зависимостей:

Кодовая метрическая визуализация с помощью treemaping:

Ответ 23

приятно слышать, что MDA, DDD и Pair Programming нигде не используются: D Мартин Фаулер не бог, просто парни с некоторыми странными идеями.

• Test-Driven-Development - если вы хотите
• Тестирование устройств - да
• Обзоры кодов - kindda
• Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST,...) - да, Seam
• UML - kindda
• Непрерывная интеграция - да и нет
• Инструменты покрытия кода - да и нет