@IVKD

Можно ли написать программу, не имея никакой документации и техзадания?

Весь август потратил на написание программы так, как мне нравится. До этого был опыт в других областях(печальный), есть подозрение, что нужна документация, соответствующая по размерам и сложности написанному софту. Вот есть статьи на Хабре, в Википедии, рассчитаны на проектирование командой специалистов(бездельников от разработки?), для меня бесполезны. У меня сейчас 11000 строк кода. Раньше рассчитывал взять UML-редактор и спроектировать всё, что нужно, сейчас терзают сомнения. Вопросы:
1. Нужна документация сразу в UML или сначала требования на уровне страницы текста в Word?
2. Если я сейчас не напишу требований вовсе, чем это грозит?
3. А вот я возьму и напишу всё так, как вижу. А спустя полгода выяснится, что нужно было по-другому, а написано неэффективно, и коду это помогло на уровне статистической погрешности. Это уважительная причина, чтобы дальше писать без требований?
  • Вопрос задан
  • 190 просмотров
Пригласить эксперта
Ответы на вопрос 3
  • @kn0ckn0ck
    Продюсер
    Спрашиваешь... так делают процентов 90. Другое дело - правильно ли они поступают при этом? Часто документацию путают с проектированием. Это разные вещи и у них разные цели.

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

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

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

    1. Зависит от сложности/объема задачи. Если все помещается в голове, то для чего тогда документация? Любая, UML или текст, не важно. Если что-то нужно продумать, то можно записать на доске/бумаге, сфоткать, потом выбросить.

    2. Без требований мы не знаем что должно было получиться. Для начальной стадии продукта это вполне приемлемо. Основной риск - в регрессе функциональности. Смотрим код и не понимаем для чего он тут нужен и как оно должно работать, меняем как-то и в итоге ломаем ранее реализованную функциональность. Такие риски необязательно решаются документированием требований в форме ТЗ, можно обходиться и автоматизированным тестированием.

    3. Уважительной причиной чего-то не делать будет четкое понимание того, как связанные с этим риски минимизируются. Долой догмы. Если в среднесрочной перспективе мы четко осознаем, что фиксация/документирование требований не принесет пользы, то зачем тратить на это время/ресурсы?
    Ответ написан
  • @lxsmkv
    Test automation developer
    Если все что вы знаете о программе, вы и дальше собираетесь держать у себя в голове, и никогда и ни с кем этим знанием не делиться, то можно не писать никаких документов.
    Ответ написан
  • eduardtibet
    @eduardtibet
    Technical Writer / Documentation Engineer
    Наверное, сначала вам надо задать себе главный вопрос: "А зачем мне документация"?

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

    Если у вас нет подобных мыслей на текущий момент - вам не нужна документация.
    Если есть - составьте список текущих проблем.
    Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы
Вакансии с Моего Круга Все вакансии
Заказы с Фрилансим Все заказы