четверг, 9 мая 2013 г.

Рост инфраструктуры проектов (по нарастанию потребностей)


  1. Еженедельные архивы исходного кода.
  2. "Бумажные" диаграммы.
  3. Ручное тестирование выпусков.
  4. Соглашение об оформлении кода.
  5. Подсчёт ссылок на объекты.
  6. Тестовые наборы "на коленке" и их ручное "протыкивание".
  7. Code Review.
  8. CVS
  9. Инструкция программирования и оформления исходного кода.
  10. Списки ToDo.
  11. Логирование ошибок с выводом стека.
  12. Учимся пользоваться Araxis Merge или его аналогами (jfc, tfc, afc, на худой конец - fc).
  13. Clear Quest или любая другая "плоская" база ошибок.
  14. Проверка утечек (в частности через подсчёт ссылок).
  15. "Ручные" ежедневные отчёты в почте.
  16. Usecase'ы.
  17. Документирование исправленных ошибок прямо в коде.
  18. High Level Test Cases.
  19. Ночные сборки на bat-файлах.
  20. "MVC".
  21. Рефакторинг.
  22. Сбор логов от пользователей.
  23. wiki-подобная база знаний и база ошибок.
  24. "Код у нас общий".
  25. Code Review в wiki с использованием обсуждений в электронном виде.
  26. Документирование исправленных ошибок со ссылками на wiki.
  27. Ночные сборки на продвинутых "скриптах" (например ant) с публикацией отчётов в wiki.
  28. Автоматизированные ежедневные отчёты в wiki.
  29. Автоматизированное тестирование чёрного ящика, через GUI (например Test Complete или разные другие роботы).
  30. Детализация требований.
  31. Применение шаблонов проектирования от GoF (и не только).
  32. UML.
  33. Кодогенерация из UML.
  34. Соглашения об унифицированной настройке среды.
  35. Нагрузочное тестирование.
  36. Проектнозависимые стереотипы для кодогенерации.
  37. Рефакторинг под влиянием UML.
  38. Тесты библиотек.
  39. Стереотипы для тестов.
  40. Расставлены определённые технологические точки над i с отделом маркетинга.
  41. Механизм контрольных точек.
  42. Ежедневные прогоны тестов.
  43. Рефакторинг при наличии тестов.
  44. Механизм "эталонов" для тестов.
  45. Механизм размножения тестов относительно тестовых наборов.
  46. GUI-тесты.
  47. Скриптованные тесты.
  48. Специализированные стереотипы для шаблонов проектирования (например GoF).
  49. Ежедневные прогоны тестов и их разбор специально выделенными людьми.
  50. Написание тестов по результатам УЖЕ найденных ошибок, специально выделенными людьми.
  51. Unit-тестирование.
  52. Выделение аспектов в примеси.
  53. Интеграционное тестирование.
  54. Трассировка требований в тесты.
  55. Автоматическая публикация новых ошибок и "возрождение" старых вследствие ежедневного прогона тестов после ночной сборки.


Автор: на
Ярлыки: , ,

3 комментария:

  1. Алексей Тимохин8 сентября 2013 г. в 04:28

    Откуда список?
    Вы всё это у себя используете? =)

    ОтветитьУдалить
  2. Алексей Тимохин8 сентября 2013 г. в 04:47

    as. ниже по тексту слово Redmine можно заменить на Jira+confluence+fisheye или любой другой аналогичный продукт.

    > Подсчёт ссылок на объекты.
    Зачем? Свой сборщик мусора?

    > Проверка утечек (в частности через подсчёт ссылок).
    FastMM в помощь. Помощнее будет. Заодно умеет отслеживать и обращения к несуществующим объектам и проверять целостность кучи (кучи ли ?)

    > Инструкция программирования и оформления исходного кода.
    А ещё лучше для оформления использовать автоформаттер, если возможно. И/или pre-commit валидатор.

    > Учимся пользоваться Araxis Merge или его аналогами (jfc, tfc, afc, на худой конец - fc).
    Такими как WinMerge, Beyond compare.

    > Clear Quest или любая другая "плоская" база ошибок.
    Clear Quest? Жирновато будет. Мой выбор - Redmine. Заодно и разбиение по проектам, встроенная Wiki, а главное - связывание багов с коммитами. А заодно и такие плюшки как учёт времени и кое-какое планирование. А также там вроде дакже есть плагины для code review.

    > "Ручные" ежедневные отчёты в почте.
    жесть. Зачем? Лучше 10 минутный stand-up из Agile.

    > Usecase'ы.
    Без них лучше и не начинать.

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

    > High Level Test Cases.
    Use cases же уже есть.

    > Ночные сборки на bat-файлах.
    Зачем на .bat? Есть want, есть Lazy Delphi Builder.

    > Рефакторинг.
    Это то, что начинается сразу же после создания нового проекта в Delphi. :D

    > wiki-подобная база знаний и база ошибок.
    Redmine + FAQ plugin

    > Code Review в wiki с использованием обсуждений в электронном виде.
    Неужели так удобней, чем использовать специализированные инструменты для code review?

    > Документирование исправленных ошибок со ссылками на wiki.
    Redmine + привязка ошибок к версиям.


    > Автоматизированные ежедневные отчёты в wiki.
    Зачем? В любом мало-мальски разумном трекере есть раздел activity где можно посмотреть, что и когда происходило.

    > Автоматизированное тестирование чёрного ящика, через GUI (например Test Complete или разные другие роботы).
    + олтдельная команда на поддержание в актуальном виде скриптов для тестирования.

    > Соглашения об унифицированной настройке среды.
    Это должно следовать сразу за инструкцией для написания кода.

    > Ежедневные прогоны тестов и их разбор специально выделенными людьми.
    > Автоматическая публикация новых ошибок и "возрождение" старых вследствие ежедневного прогона тестов после ночной сборки.
    Continuous integration. Jenkins в помощь.
    Юнит тесты желательно гонять перед каждым коммитом (локально) и после коммита (на билд сервере).

    ОтветитьУдалить
  3. Alex W. Lulin8 сентября 2013 г. в 22:17

    Я написал всё как было

    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)