Здравствуйте, sunshine, Вы писали:
S>Вот есть у тебя сложный проект. Наняли нового сотрудника для доработки функционала и поддержки. Пришел он, сел за комп. Ты ему показываешь, откуда загрузить проект, он его загружает, и... Дальше что?
Дальше ему дается несложное задание, основная цель которого — посмотреть, что сотрудник собой представляет и дать ему возможность разобраться в проекте.
S> Он сидит и молча смотрит код проекта в студии? Или все-таки задает вопросы по ходу?
Если молча — скорее всего испытательный срок он не пройдет.
S> Если все-таки задает вопросы, то не обращал-ли ты внимание — сколько примерно времени уходит в общей сложности на устные объяснения, прежде чем он овладеет кодом настолько, что будет способен делать сколько-нибудь значительные доработки?
Обращал. Зависит от кучи факторов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1137 on Windows Vista 6.0.6001.65536>>
Здравствуйте, sunshine, Вы писали:
MNN>>Ежедневные митинги, на которых обсуждается вопросы "что делать", "как делать", "как уже сделано" по аналогии, с участием ветеранов и новичков. S>Ежедневные, имхо, как-то уж чересчур, но судить не берусь.
Митиег — это не обязательно многочасовое мероприятие. Он может и 5 минут длиться.
S>Хочу подчеркнуть, что я такой док не позиционирую как необходимость. Я просто предпочитаю его иметь, чем не иметь. И как разработчик проекта, и как новичок на новом месте.
Все предпочитают иметь, а вот тратить время на его написание — уже не все.
Re: какую документацию вы пишете на разрабатываемое ПО ?
Здравствуйте, Саша Равный, Вы писали:
СР>Интересуют два вопроса:
СР>1. какого рода документацию вы пишете на разрабатываемое ПО ? (uml-диаграммы, справочник по функциям, руководство пользователя...)
Пишу doxygen'овые коментарии, в которых со скрупулезностью Капитана Очевидность описываю все функции и методы, все их параметры, все другие члены классов — по требованию заказчика.
Настоящей документации нет, т.к. она не только не требуется, но и время на её написание не выделяется
Недавно был поставлен вопрос "мы таки пишем комментарии для доксигена или как ?", поэтому я хотел бы услышать мнения, кому такая документация помогла/не помогла, как извлечь от неё пользу, когда надо документировать параметры, исключения, когда предусловия, постусловия. Я считаю что описание всех параметров и всех методов — пустая трата времени, и доксиген скорее полезен для библиотек, чем для программ. Намного обльше пользы от обычных коментариев, в свободной форме, там, где они реально нужны.
СР>2. какими программами пользуетесь при ее оформлении ? (West Wind HTML Help Builder и т.д.)
Проход doxygen'ом включен как отдельный мейкфайл проект, чтобы собирать комментарии при каждой сборке, иметь документацию up-to-date документацию, и не допускать синтаксических ошибок и непонятного для доксигена синтаксиса. Этот мейкфайл почти не увеличивает время сборки из-за её распараллеливания, однако, иногда с ним бывают проблемы
СР>Интересуют два вопроса:
СР>1. какого рода документацию вы пишете на разрабатываемое ПО ? (uml-диаграммы, справочник по функциям, руководство пользователя...)
СР>2. какими программами пользуетесь при ее оформлении ? (West Wind HTML Help Builder и т.д.)
СР>3. какой вид документации чаще используется ?
СР>4. Есть ли где-нибудь статья, где бы научно-популярно объяснялись разные виды документации и где они применяются.
СР>Я так как недавний выпускник с этой областью пока мало сталкивался, то почитаю любые ваши комментарии на эту тему
Как все запущено в нашем образовании в том числе. Все зависит от назначения ПО. Если для внутренних нужд — кому как на душу положит, если начальник не наедет. Если для сдачи заказчику в лице отечественного концерна или еще кого-то — существует ГОСТ (номера не помню — давно это было). В нем табличка с перечнем документов — обязательный документ — черный кружочек, не обязательной (по усмотрению заказчика) — наполовину черный, опция — незакрашеный. Далее эти документы сдаются в нормоконтроль, где их тщательно выверяют на формальные признаки (по сути — на соответствие требованиям оформления). После этого — отдают заказчику как продукция и он оплачивает. По крайней мере все НИИ так работали.
В ВПК свои ведомственные требования:
— альбом алгоритмов с диаграммами и текстовым описанием переменных и используемых внешних процедур (альбом А3 формата)
— временная диаграмма взаимодействия (UML-овскую напоминает, только временная ось не сверху вниз, а слева направо)
— ПОП — "Программа отработка программ" — по сути методика отладки и проверки на соответствие функционирования — альбом А3 Формата. За каждый выполненый на стенде при испытаниях пункт военпред расписывался.
— Результат- исходники и исполняемые модули на носителе в двух экземплярах.
Re: какую документацию вы пишете на разрабатываемое ПО ?
Здравствуйте, Саша Равный, Вы писали:
СР>1. какого рода документацию вы пишете на разрабатываемое ПО ? (uml-диаграммы, справочник по функциям, руководство пользователя...)
1. Functional specification (use-cases, business rules, software/hardware requirements, UI mockups)
2. Software design document (UML, implementation details, used technologies)
3. Иногда Installation guide.
СР>2. какими программами пользуетесь при ее оформлении ? (West Wind HTML Help Builder и т.д.)
MS Office
СР>3. какой вид документации чаще используется ?
Смотря для чего. Для QA — FS, для вовлечения новых девелоперов — SDD, для кастомера FS и IG.
Повреждение мозга после ректальной биопсии — редкая штука (с) Хаус
