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

Question

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

Я изменил ваш код, добавив свойство margin для настройки позиции кнопки и комментируя свойство transform. но если бы вы могли использовать библиотеку стилей, такую как начальная загрузка или дизайн материала, вы могли бы быстрее сортировать форму

h2 {
    margin: 0;
    padding: 0;
	margin-bottom: 2.3rem;
}

form {
  float: left;
  display: inline-block;
  padding: .5rem;
  height: 205px;
  width: 168px;
  border: 2px solid black;
  font-family: Sans-Serif;
  font-size: 12px;
}

.input-wrapper {
  margin-bottom: .5rem;
}

label {
  width: 50px;
  display: inline-block;
  text-align: left;
 font-family: Sans-Serif;
font-size: 14px;
}

input {
  width: 90px;
  padding: .5rem;
  height: 3px;
  border: 2px solid black;
  text-align: left;
}

button {						
  padding: .5rem;
  display: block;
  width: 55%;	
  background: lightgrey;
  color: black;
  border: 2px solid black;
  text-align: center;
  border-radius: 5px;
  font-size: inherit;
  /* transform: translate(50%, 50%); */
  margin: 60px auto;
  
}

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <link rel="stylesheet" href="style.css">
  <title></title>
</head>

<body>
  <form action="#">

    <h2>xyz xyz</h2>
    <div class="input-wrapper">
      <label for="name">Name:</label>
      <input type="text" name="Name" placeholder="Name...." id="name">
    </div>

    <div class="input-wrapper">
      <label for="email">Epost:</label>
      <input type="text" name="Epost" placeholder="Epost...." id="epost">
    </div>

    <button type="submit">Senden</button>
  </form>
</body>

</html>

22

survey

задан Maxime Rouiller 23 October 2008 в 12:34

22 ответа

Разработка через тестирование - Никакой
Domain-Driven-Design - Никакой
Model-Driven-Design/Architecture - Никакой
Вы тестируете? - Иногда
Поблочное тестирование - Почти никогда
Интеграционное тестирование - Да
Приемочные испытания - Иногда
Обзоры Кода - Только иногда
Innovative Technologies (Spring, Будьте в спящем режиме, Калитка, JSF, WS, REST...) - Никакой
Гибкий - Никакой
Программирование Пары - Никакой
UML - на моей плате маркера, да.
Проблемно-ориентированные языки - C++ является зависящим от домена, правильно?
Спецификация требований (Как?) - я думаю, что мы встречаем их.
Интеграция Continous - Да
Инструменты Покрытия кода - Никакой
Модель предметной области Aenemic - Что является Коммуникацией модели предметной области
(Wiki, Почта, IM, Mailinglists, другие документы) - электронная почта & Skype. Что такое Wiki?
оценки Усилия - 1-2 дня для любого данного размера Команды задачи
- 2 разработчика программного обеспечения, 10 инженеров аппаратного обеспечения
Встречи - 2 раза в неделю
метрики Кода - Никакой
Статический анализ кода - Никакой
Отслеживание ошибок - Никакой

0

ответ дан 29 November 2019 в 04:37

Разработка через тестирование - Да
Domain-Driven-Design - Никакой
Model-Driven-Design/Architecture - Никакой
Вы тестируете? - Да
Поблочное тестирование - Да
Интеграционное тестирование - Да
Приемочные испытания - Запустились
Обзоры Кода - Никакой
Innovative Technologies (Spring, Будьте в спящем режиме, Калитка, JSF, WS, REST...) - Нет?
Гибкий - Да
Программирование Пары - Да почти все время
UML - Ничто более формальное, чем строки и поля на электронных досках.
Проблемно-ориентированные языки - Немного
Спецификация требований (Как?) - нет, мы пытаемся получить пользовательские истории, если возможный
Интеграция Continous - Да
Инструменты Покрытия кода - Никакой
Модель предметной области Aenemic -
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы) - Wiki, IM, электронное письмо, документы в формате Word
оценки Усилия - Мы используем комбинацию размера Футболки (S, M, L, XL и т.д.) и система точек для спринта скоростью спринта.
размер Команды - 6-> 8
Встречи - Ежедневно встают
метрики Кода - Никакой
Статический анализ кода - Никакой
Отслеживание ошибок - Bugzilla / Версия Одна

0

ответ дан 29 November 2019 в 04:37

Разработка через тестирование: нет.
Domain-Driven-Design: никакой
Model-Driven-Design/Architecture: мы действительно запускаем с моделей для наших приложений
, Вы тестируете? да. Иногда я - единственный человек, который тестирует мой материал. Я ненавижу это.
Поблочное тестирование - нет. Это - недостающая область в моем наборе навыков, я рассматриваю высокий приоритет к rememdy.
Интеграционное тестирование - никакой
Приемочные испытания - иногда. Жесткий, чтобы заставить пользователей доводить его до конца, даже с угрозами со стороны На Высоко.
Обзоры Кода - нет. Мы обсудили выполнение его, но никогда не делаем в конце. Я расстроен об этом.
Innovative Technologies - никакой
Гибкий - мы являемся мягко гибкими, хотя не точно через предумышленное усилие
Программирование Пары - никакой
UML - так мало, как мы должны, но мы действительно моделируем (мы являемся более сознательно гибкими здесь).
Проблемно-ориентированные языки - никакой
Спецификация требований (Как?) - мы делаем. Моя группа иногда, прежде всего, ответственна за сбор требований. Нам обычно помогает Аналитик Бизнеса теперь, но это было не всегда так. Вице-президент иногда вручает нам требования, которые прибывают от, я не знаю где. Иногда они - старые вещи, которые никогда не делались, но были запланированы давным-давно. обычно собранные требования помещаются в документ Word, рассмотренный основными пользователями, а также моей командой, Аналитиком Бизнеса и Вице-президентом.
Интеграция Continous - нет
Инструменты Покрытия кода - никакой
Модель предметной области Aenemic - я не знаком с его, но нет.
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы) - просто электронная почта и лицом к лицу. Я недавно начал обсуждение этой темы, потому что мы должны сделать что-то больше, Wiki предпочтительно. Это было помещено во второе место.
оценки Усилия - да, но мы не предпринимаем попытки действительно отследить их. Это - другая область, где мне недостает.
размер Команды - 3, самостоятельно включенный (директор < - Руководитель группы < - Я).
Встречи - мы встречаемся один раз в неделю, хотя не всегда. Босс обычно регистрируется, по крайней мере, несколько раз в неделе индивидуально. Более крупные встречи группы проходят эпизодически. И конечно мы планируем встречи, чтобы долго обсудить проектные требования по мере необходимости.
метрики Кода - нет
Статический анализ кода - нет
Отслеживание ошибок - мы регистрируем ошибки. это - в значительной степени наше отслеживание ошибок.

Вот именно. У нас есть области, я чувствую, что мы могли изменить к лучшему.

Обновление:

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

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

Ничто иное не изменилось.

0

ответ дан 29 November 2019 в 04:37

Разработка через тестирование: достаточно редко кто-то мог бы сделать это для компонента. Кроме того, реализация общедоступной спецификации, которая идет с тестами соответствия, предлагает некоторые преимущества TDD, и многое из этого продолжается.
Domain-Driven-Design: никакой
Model-Driven-Design/Architecture: никакой
Вы тестируете?: да
Поблочное тестирование: некоторые, хотя не завершенный. Много компонентов является библиотеками для потребительского использования. Существует тонкая грань между поблочным и функциональным тестированием "strlen" реализации.
Интеграционное тестирование: не действительно, существует мало между модульными тестами и тестированием системы
Приемочные испытания: да, и подмножества приемочных испытаний, используемых в качестве тестирования системы
Обзоры Кода: никакой формальный процесс, но некоторый код не становится рассмотренным
Innovative Technologies (Spring, Будьте в спящем режиме, Калитка, JSF, WS, REST...): никакой
Гибкий: никакой
Парное Программирование: никакой
UML: никакой
Проблемно-ориентированные языки: достаточно редко
Спецификация требований (Как?): вид [1 113]
Интеграция Continous: нет, но ежедневно создает и возвращение вызывающих отказ изменений по усмотрению тестовой команды
Инструменты Покрытия кода: никакое формальное требование, тестовые команды, как было известно, использовали them
Модель предметной области Aenemic: Я даже не знаю то, что это
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы): все они, выбранные для данного случая за исключением того, что требование и документы дизайна должны быть HTML при управлении исходным кодом и внутренней интерфейсной документацией, сгенерированы из комментариев Doxygen в заголовках.
оценки Усилия: немного
размер Команды: приблизительно 20 программистов, по-разному сгруппированных в команды компонента 1-4 человек. В значительной степени никто не работает исключительно над компонентом, команде которого они принадлежат.
Встречи: еженедельная полная встреча, чтобы обмениваться отчетами о выполнении работ и иначе совместно использовать, что продолжается. Никакие другие регулярно запланированные встречи для разработчиков: обсуждения расположены как требуется.
метрики Кода: никакой
Статический анализ кода: не, если Вы не рассчитываете - педантичный;-)
Отслеживание ошибок: Bugzilla, несколько интегрированное с управлением исходным кодом

0

ответ дан 29 November 2019 в 04:37

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

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

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

0

ответ дан 29 November 2019 в 04:37

вЂўTest-Driven-Development - Только начинающий вступать во владение, очень довольный им до сих пор

вЂўDo Вы тестируете? - Конечно, все делают, кто хочет QA, смеющийся над ними?

Тестирование вЂўUnit - В течение приблизительно 2 лет теперь, помог с устойчивостью, и тесты запущены каждая сборка

, Обзоры вЂўCode - Тут и там, особенно с любыми последними изменениями

вЂўAgile - Гибкая Любовь и ее скорость отклика

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

Интеграция вЂўContinous - CruiseControl.NET для Победы!!! Такая огромная справка

Инструменты вЂўCode-покрытия - Всегда во время каждого выполненного модульного теста, CC.NET публикует эту информацию к миру

вЂўCommunication (Wiki, Почта, IM, Mailinglists, другие документы) - WIKI, IM, Походный костер

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

, вЂўMeetings - короткий и не часто, более вероятно для получения прихожей получают метрики togethers

вЂўCode - Только цикломатическую сложность

анализ кода вЂўStatic - Действительно пробующий это Больше использования FxCop и VSTS's, собственной разработки

отслеживание вЂўBug - TFS для окон и Traq для Mac

0

ответ дан 29 November 2019 в 04:37

Разработка через тестирование - Хотя это должно быть, поскольку это было предпринято, чтобы быть введенным, но я не думаю, что это взлетело, таким образом, это все еще не, но с большим количеством деталей теперь.
Domain-Driven-Design - Никакой
Model-Driven-Design/Architecture - Никакой
Вы тестируете? - Да, но не всесторонне. У нас действительно есть некоторые модульные тесты, некоторые интеграционные тесты и некоторые тесты WatiN.
Поблочное тестирование - у Нас есть некоторые для нашей новой разработки, но прежней версии не делают.
Интеграционное тестирование - Обычно, когда это применимо. У моей команды, являющейся веб-командой, кажется слишком часто еще, нет этого.
Приемочные испытания - у Нас есть несколько уровней этого. Первое - когда новая возможность разрабатывается и должна получить начальное одобрение от кого-то в другой команде, которая будет вводить содержание, которое прибывает, прежде чем в этом даже интегрируют с кодом. Второе - когда функции продемонстрированы в конце Sprint для получения большего количества обратной связи о том, что не выглядит правильным или работает хорошо. Тогда существует третий уровень непосредственно перед тем, как он входит в производство как в финал, "Да, это не портит то, что мы уже имеем", вид вещи.
Обзоры Кода - Они больше не делаются, но вероятно были бы хорошей вещью сделать.
Innovative Technologies (Spring, Будьте в спящем режиме, Калитка, JSF, WS, REST...) - существуют некоторые УСПОКОИТЕЛЬНЫЕ идеи, применяемые в нашем проекте, и мы используем некоторые функции.Net платформы как лямбда-выражения.
Гибкий - Мы используем Толпу и имеем, выдерживают взлеты, плату истории, Итеративная Встреча Планирования (Который является действительно для спринта и не повторения, которое является 2 спринтами как после каждой пары спринтов, которые работу показывают руководителям и другим отделам, в то время как другая демонстрация является для архитектора и главы довольного командой ввода.)
Программирование Пары - у Нас действительно есть соединение на большей части новой разработки, которая не рассматривается как трудная работа. Таким образом для того, кто бы ни хочет работать над Учебной частью сайта, пара сделает это вместо всего одного разработчика.
UML - нет, и инструмент для UML был удален в наших новых машинах
Проблемно-ориентированные языки - нет, но существует некоторая терминология, которая является собственными интерпретациями компанией вещей, поскольку некоторые названия внутреннего удара продуктов против других условий могут использовать для различных вещей.
Спецификация требований (Как?) - Это может колебаться от документа хвастовства, обстоятельно объясняющего, какие потребности быть сделанным к переговорам того, что сделать и затем попробовать это и попытку это позже.
Интеграция Continous - у Нас есть Круиз-контроль. Сетевое выполнение для нашего CI, который используется, когда мы фиксируем изменения кода.
Инструменты Покрытия кода - Нет.
Модель предметной области Aenemic - Несколько, в котором нет действительно большой модели предметной области здесь.
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы) - В порядке важности: электронная почта, IM, телефон, затем посещая кабину. Существует еженедельное обсуждение в команде с менеджером приложений и ежедневного standups на большом проекте.
оценки Усилия - Это теперь распространено в каждом спринте, хотя иногда это сделано путем отсылки электронной таблицы для всех, чтобы вставить их оценки, что Ведущее устройство Толпы комбинирует все результаты для нас видеть в конце.
размер Команды - 5 разработчиков с руководителем группы, бизнес-аналитик, кто Ведущее устройство Толпы, тестер для наблюдения за тем, что мы имеем и другие вне команд, которые открываются по мере необходимости включая авторов содержания для фактического использования системы.
Встречи - Вниз к бизнесу, короткому, эффективному и обычно хорошему для передачи, где вещи в настоящее время.
метрики Кода - Ни один, что я знаю.
Статический анализ кода - Нет.
Отслеживание ошибок - Качественный Центр используется для отслеживания дефектов. * Управление исходным кодом - Мы используем Подрывную деятельность теперь. Для любой функции или ошибки мы создаем новое ответвление, таким образом, мы можем работать независимо и не иметь наше повреждение фиксаций сборка, как мы работаем над чем-то. Однако все мы совместно используем тот же DB для разработки, которая может время от времени быть интересной.
IDE - Visual Studio 2008 на XP с помощью.Net 3.5 и Sitecore 6.1
...

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

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

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

1

ответ дан 29 November 2019 в 04:37

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

я знаю несколько (включенная шахта) компании, которые были бы в состоянии отсчитать весь' хороший ', окружает Ваш список.

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

1

ответ дан 29 November 2019 в 04:37

Разработка через тестирование - Никакой
Domain-Driven-Design - Никакой
Model-Driven-Design/Architecture - Никакой
Вы тестируете? - Почти никогда
Поблочное тестирование - Почти никогда
Интеграционное тестирование - Никакой
Приемочные испытания - Никакой
Обзоры Кода - Никакой
Innovative Technologies (Spring, Не Будьте в спящем режиме, Калитка, JSF, WS, REST...) - Spring, Будьте в спящем режиме, Калитка
Гибкий - Никакой
Программирование Пары - Никакой
UML - просто эскизы
Проблемно-ориентированные языки - Никакой
Спецификация требований (Как?) - Мы получаем огромную потребительскую спецификацию требований, и мы используем интеллект-карты для извлечения фактических функций, которые тогда оцениваются
Интеграция Continous - Никакой
Инструменты Покрытия кода - Никакой
Модель предметной области Aenemic - Да
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы) - Интеллект-карты, Почта
оценки Усилия - FITA (Палец в воздухе, посмотрите здесь )
размер Команды - 2-6
Встречи - 2-3 раза в неделю
метрики Кода - Никакой
Статический анализ кода - Нет (Попробованный FindBugs и Checkstyle)
Отслеживание ошибок - Да, Bugzilla

1

ответ дан 29 November 2019 в 04:37

Разработка через тестирование: да
Domain-Driven-Design: да
Model-Driven-Design/Architecture: да
Вы тестируете? да
Поблочное тестирование - да
Интеграционное тестирование - да
Приемочные испытания - да
Обзоры Кода - да
Innovative Technologies - да
Гибкий - только гибкий
Программирование Пары - да
UML - иногда для ddd поединков электронной доски
Проблемно-ориентированные языки - да
Спецификация требований (Как?) - в форме примеров и приемочных испытаний
Интеграция Continous - да - инструментов TeamCity
Покрытия кода - да - модель предметной области NCover
Aenemic - не уверенный
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы) - Wiki, почта, размер msn
Команды - 6 + зависящий от проекта
Встречи - каждое утро в 9:30 - ТОЛПА
метрики Кода - не делают know
, Статический анализ кода - не делает know
Отслеживание ошибок - Богомол

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

Все идут домой в 5:30: ДА

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

2

ответ дан 29 November 2019 в 04:37

Разработка через тестирование - Почти там.
Domain-Driven-Design - Никакой
Model-Driven-Design/Architecture - Никакой
Вы тестируете? - Да
Поблочное тестирование - Да
Интеграционное тестирование - Да
Приемочные испытания - Никакой
Обзоры Кода - Никакой
Innovative/New Technologies (Spring, Будьте в спящем режиме, Калитка, JSF, WS, REST...) - ASP.NET MVC? NHibernate? Да
Гибкий - Только что запустился
Программирование Пары - Никакой
UML - Ничто формальное
Проблемно-ориентированные языки - Никакой
Спецификация требований (Как?) - Да. Получение требований истории.
Интеграция Continous - Да. Инструменты TeamCity
Покрытия кода - Да. Модель предметной области NCover
Aenemic - Никакой
Коммуникация (Wiki, Почта, IM, Mailinglists, другие документы) - IM, электронная почта
оценки Усилия - 1,2,4,8
размер Команды - 4
Встречи - Ежедневно встают
метрики Кода - Никакой
Статический анализ кода - Никакой
Отслеживание ошибок - Существующее пользовательское задание

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

2

ответ дан 29 November 2019 в 04:37

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

<час>

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

5

ответ дан 29 November 2019 в 04:37

его хорошее, чтобы услышать, что MDA, DDD и Парное Программирование не используются нигде: D Martin Fowler не бог, просто парни с некоторыми странными идеями.

Разработка через тестирование - если Вы хотите к
Поблочное тестирование - да
Обзоры Кода - kindda
Innovative Technologies (Spring, Будьте в спящем режиме, Калитка, JSF, WS, REST...) - да, Шов
UML - интеграция kindda
Continous - да и никакой
Инструменты Покрытия кода - да и никакой

-1

ответ дан 29 November 2019 в 04:37

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

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

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

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

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

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

0

ответ дан 29 November 2019 в 04:37

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

0

ответ дан 29 November 2019 в 04:37

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

Разработка на основе тестирования: Нет
Дизайн на основе предметной области: Да
Дизайн на основе модели / Архитектура: Да
Вы тестируете? : Да
Модульное тестирование: Да
Интеграционное тестирование: Да
Приемочное тестирование: Да
Проверка кода: Нет
Инновационные технологии (Spring, Hibernate, Wicket, JSF, WS, REST, ...): Да
Agile Pair Programming: Нет
UML: Да
Доменные языки: Да
Спецификация требований (Как?) Да
Непрерывная интеграция: Да
Код -Инструменты покрытия: Нет
Модель анемического домена: Нет (Что мы подразумеваем под этим?)
Связь (Wiki, Mail, IM, Списки рассылки, другие документы): Wiki, Mail, IM, списки рассылки
Оценка трудозатрат: Да
Размер команды: 2-4 члена
Встречи: каждый понедельник фиксированные собрания и плавающие собрания через день
Показатели кода : Да
Статический анализ кода: Нет
Отслеживание ошибок: Да

0

ответ дан 29 November 2019 в 04:37

Разработка, управляемая тестированием - если под этим вы имеете в виду написание тестов до кода, не всегда
Дизайн, управляемый доменом - не чистый DDD
Дизайн / архитектура на основе модели - никогда, но на самом деле НИКОГДА снова
Вы тестируете? - да, всегда
Модульное тестирование - да, всегда
Интеграционное тестирование - это зависит от обстоятельств, но мы стараемся их избегать, поскольку они обычно медленные
Приемочное тестирование - да, в идеале автоматизировано
Проверки кода - да, это включено в определение done
инновационных технологий (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - не уверен, что упомянутые технологии являются инновационными, но да для Spring, Hibernate, WS
Agile - да, это в моей ДНК
Парное программирование - не всегда, но да (по новым предметам, с новыми членами команды, если явно просят)
UML - немного (т.е. ежедневная встреча, демонстрация и ретроспектива)
Метрики кода - да (цикломатическая сложность, покрытие кода, стандарты кодирования, собранные в сонаре)
Статический анализ кода - да (поиск ошибок, проверка стиля)
Отслеживание ошибок - да, конечно (но мы стараемся исправлять ошибки, как только обнаруживаем их)

1

ответ дан 29 November 2019 в 04:37

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

Примечания:

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

2

ответ дан 29 November 2019 в 04:37

I work for a Ruby on Rails consultancy in Brisbane, Australia.

Test-Driven-Development: This is pushed very, very hard in our office. Not testing is viewed as "incredibly stupid". You write the code, how do you ensure by way of an automated process such as CI, that it still works? Tests.
Do you test?: See point one.
Unit Testing: All the time, using RSpec. I'm "fluent" in Test::Unit and Shoulda also.
Integration Testing: Again, all the time, Cucumber.
Acceptance Testing: With our tickets we "deliver" them with an Acceptance Criteria. Then the client has to either "Accept" or "Reject" them by following the bouncing ball. The Acceptance Criteria has the bonus of also being what our Cucumber features are written in.
Code Reviews && Pair Progamming: We pair. It's the instant version of code review. It's awesome because you can sit back and watch someone else work, they write the test and then you write the code to make that test pass. If you're sick then the other person knows what you were up to and can pair with somebody else.
Innovative Technologies: Because we use Rails, we're really fond of REST.
Agile: We work on 2 week iterations using Pivotal Tracker.
Requirement Specification (How?): Using features in Pivotal Tracker the client can specify what requirements they have and then we flesh them out (usually by talking with them) into acceptance criteria, and eventually Real World features.
Continous Integration: We use a CI server I developed called construct. This was built with the idea of being like Integrity, but with background jobs and better support for branches. Now that Integrity has background building, there's still the branching support keeping us "ahead".
Code-Coverage Tools: RCov sometimes. We're not really fussed with code coverage as we test EVERYTHING before we write it. If it exists, there's something that will test it.
Communication (Wiki, Mail, IM, Mailinglists, other documents): We communicate with our clients using Email primarily, but we also have "standups" with them using Skype. We've also used Basecamp for this. I'm wanting to use Google Wave for our next project, just as a little experiment. I think it'd be really helpful.
Team size: We have 4 people in our team, usually 2 pairs unless someone's sick.
Meetings: We have a "scrum"/"standup" in the mornings lasting about 15 minutes. The idea of this is that you go over what you did the previous day, any problems you encountered, what you're going to do today and something "new and shiny" you found. This should not turn into a project meeting. Those are for after the standup if required.
Bug tracking: Again we use Pivotal Tracker. The client can file a bug here and then (ideally) write how to duplicate it. Then we write a test to ensure that this should never happen again (aka: Regression Testing) and it goes through the same work process as our features, we deliver and the client accepts.

1

ответ дан 29 November 2019 в 04:37

I am one of two programmers at a small software firm with VERY non-technical owners ("what's a 'browser'" - seriously asked last week).

The advantage is that I can choose for myself on most of these points.

Test-Driven-Development - Our owner had a bad experience or something. Mention testing in the wrong way and I'd swear she's acting out of PTSD.

Domain-Driven-Design - Yep.

Model-Driven-Design/Architecture - Yep.

Do you test? - Nope. Testing falls on the sales & support staff and the owners. So nothing gets tested much once it leaves my dev machine.

Unit Testing - If I got caught doing it I might get fired. And its seriously the only thing that could get me fired.

Integration Testing - See "Do you test?"

Acceptance Testing - Well, we have to deploy it sometime, right?

Code Reviews - No one else would understand it. I've seen everyone elses. Wish I hadn't.

Innovative Technologies (Spring, Hibernate, Wicket, JSF, WS, REST, ...) - Yep. But I get flak for it. I'm the "kid" who doesn't know anything that wasn't invented in the last ten years (despite being 30 and having "Readings in Database Systems" on my desk).

Agile - I don't waterfall. But I don't really Agile, either.

Pair Programming - You don't want to try to talk to the other "programmer" that works at our company.

UML - Nope. But I draw boxes with identifiers in them sometimes on my whiteboard. The bosses like that. Good thing they're not more technically inclined, or I'd probably see more boxes.

Domain-specific languages - Nope.

Requirement Specification (How?) - Nope.

Continous Integration - Nope.

Code-Coverage Tools - Nope.

Aenemic Domain Model - Yep. Tried it. Most of my situations I don't like it for and don't use it.

Communication (Wiki, Mail, IM, Mailinglists, other documents) - Tried, couldn't get coworker buy-in. Our MediaWiki install still has the default logo graphic.

Effort estimates - We have to estimate how long every job will take in hours. That is what the client gets billed. And that is what we are expected to spend on the project. We even do this when we are looking at new clients and developing new apps from scratch, as well as when we do bug fixes (yeah, we charge clients for that), feature additions, etc.

Team size - 1. And let me say this is not a good way to work. It is much better to be able to bounce ideas of other capable programmers in real time.

Meetings - few hours worth a week, sometimes double that and rarely less than that. Half the meetings I do are with clients, have are totally internal.

Code metrics - Nope.

Static code analysis - Nope.

Bug tracking - Not as much as I should.

1

ответ дан 29 November 2019 в 04:37

I Work for Chillisoft.co.za in South Africa

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

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

Unit Testing : См. TDD.

Integration Testing: Да, но мы пока не используем их повсеместно.

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

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

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

Innovative Technologies: Мы проделали большой объем работы над Habanero и используем этот фреймворк вместе с контейнером DI Unity и RhinoMocks.

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

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

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

Code-Coverage Tools: Мы запускаем кодовое покрытие для каждого проекта как часть нашей ночной сборки. Мы объединили полученный отчет с отчетами Хадсон, чтобы отслеживать его ежедневно для каждого проекта.

Коммуникация (Вики, Почта, IM, Почтовые индексы, другие документы):Очевидно, что мы общаемся во многих различных манерах, у нас есть внутренняя Вики и т.д.

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

Meetings: У нас "схватка" каждое утро длится около 10 минут.

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

1

ответ дан 29 November 2019 в 04:37

Другие вопросы по тегам:

survey

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

22 ответа

Похожие вопросы: