50% на комментарии, 35% на имена методов и переменных, остальное на написание кода. Но еще раньше, в 5-10 раз больше времени и куча исписанных тетрадок на продумывание архитектуры.
Вменяемую документацию можно создать только после окончания писания кода. И это будет инициирован отдельный проект написания документации, ну или не будет, если это никому не нужно.
Комментирование в коде я за документацию не считаю, хотя когда комментирование есть — это несомненная помощь тому, кто будет далее разбираться с этим кодом. Но конечному пользователю вообще ни холодно ни жарко, что кто-то там что-то откомментировал в коде.
Краткие записки «о том как оно тут» по 15 минут на каждые 100 часов писания кода я тоже не считаю полноценной документацией. Ну и по времени это тоже займёт ~~0% времени от написания кода.
90% времени - это обдумывание, что и как написать. написание кода - процентов 10 времени. документирование - вообще меньше процента. можно сразу в коде писать и потом натравить doxygen, если очень охота документацию в полном виде. но комментарии в коде и так есть, так что документация генерится очень быстро. а написать README.md - тоже недолго.
Я думаю немного иначе. Действительно, исходный код может являться документаций. Но этот код в таком случае должен быть оформлен согласно некоторым правилам, довольно суровым, как и любая документация. Щтобы проверящий не строил из себя хакира (ему это и не с руки), а работал свою работу. Не любой текст - документ, не любой исходник может быть документом. Да, положить, действительно.
TDD всегда нужно. я перед тем, как писать код, пишу много разных мелких тестов. чтобы выяснить, как будет работать быстрее, или чтобы проверить работоспособность каких-то схем работы. у меня к каждому проекту получается ещё целый каталог тестов. но всё равно исследование вопроса и постановка задачи занимают намного больше времени, чем написание кода. а потом ещё есть отладка. если её включить в разработку, то она отъест процентов 20-30 времени.
Не. Обычно ведь TDD не про скорость. Просто пишем КАК мы будем юзать нашу систему, а потом пишем саму систему (либу, бэкэнд и т.д.) Ну я думаю вы в курсе.
ну, это один из методов планирования. но обычно всплывает больше чисто технических вопросов. «как будем юзать» - это очень маленький вопрос, на самой поверхности. а под ним тонны архитектурных сложностей.
Некоторые хаскели умеют это из коробки, чем некоторые авторы успешно злоупотребляют.
Мне почти удавалось засунуть всю конфигурацию в блоки кода внутри markdown-файлов, её описывающих + мелкий скрипт для вытягивания полезного из этой каши. Формально - 100%.
Но народ не оценил. Правда, там были ещё пара отягчающих, т.ч. не факт, что именно эта идея не хороша.
По опыту работы в ооо_роги_копыта, когда меня нагнули на вэб разработку... в чижолый жыжзненный период, когда я не мог соскочить.
Писалось спецом так, чтобы невозможно было вдуплить... %-) Причём не отдупляя в графах и построении каких-то вложенных списков/каталогов, задача решалась настолько брутально-ламерски, что комменты не писались в принципе, с таким прицелом что следующая жертва обстоятельств будет радоваться и бежать, бежать и радоваться %-)
Другой деятель, взявшийся писать какой-то кусок, писал так, чтобы я упал в обморок, мешая код в циклах с разметкой хтмл.
Это я про то, что млекие энтерпрайзы типа ООО на 10чел, должны соображать что получат, сколько потратят, будущие прибыли от софтинки... полученной за сущие копейки.