Визначення потрібного обсягу документації


10

Де я зараз працюю, загальний підхід -

уникайте документації якомога більше

Документуйте лише, якщо це потребуватиме інша команда

просто для уточнення, я не маю на увазі кодову документацію - це ми робимо, я маю на увазі всю документацію, що стосується процесу проектування - якщо це схеми UML або DB, схеми класів та текстові документи зі специфікаціями та подібними.

Я перелічу причину мого Боса, щоб не документувати:

  1. це забирає багато часу - зосередьтеся на впровадженні
  2. якщо дизайн зміниться - то документація повинна змінитися, подвійні клопоти
  3. врешті-решт, ви просто отримуєте сотні сторінок, які ніхто не хоче читати, і ніхто насправді не редагує, щоб з часом вона застаріла
  4. Це біль - ніхто не хоче цього робити

Тепер я розумію, що ми працюємо швидше, але я також пам’ятаю час, що потрапляв сюди і пірнав прямо до якогось старого коду, нічого не розуміючи.

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

Я дійсно думаю, що відсутність документування сприяє подібному виправленню та відсутності розуміння системи в широкому розумінні.

моє запитання:

Як можна збалансувати документацію, щоб ми просували постійні знання серед колективу та залишалися швидкими та ефективними?


У мене така ж проблема у мене - хіба що моя команда навіть не пише коментарі до коду!
MattDavey

1
Вони хоча б документують мінімальні вимоги та характеристики? Якщо ні, то як ви знаєте, що правильно зашифрували, якщо немає ніяких вимог порівняти готовий продукт?
FrustratedWithFormsDesigner

особливо з сучасними мовами, технічна документація набагато важливіша, ніж документування коду. код повинен бути роз'яснювальним.
AK_

Хоча це справді гарна ідея уникати занадто багато документації, ваш начальник просто робить це з усіх неправильних причин.
Крістіан Рау

Чи можете ви дати уявлення про галузь, у якій працює ваша компанія? Деякі галузі мають юридичну вимогу щодо необхідності мінімального рівня документації.
техніт

Відповіді:


5

Я знайшов, що БУДЬ-яка документація краща, ніж НЕ. Відповідна сума зазвичай визначається кількістю часу, який ми маємо це зробити, або від того, наскільки ми ненавидимо телефонні дзвінки та електронні листи підтримки.

Здається, що члени вашої нинішньої команди мають певні нереалістичні сподівання на свої спогади, або вони соромляться своїх навичок письма та не бажають практикувати.

Я усвідомлюю, що перебуваю в меншості (англійський майор, який в аспірантурі потрапив до інженерії програмного забезпечення), тому що я не вважаю документацію справжнім завданням. Це цінний професійний інструмент. Можливо, мені не здається писати так важко, як деяким моїм колегам, але це здебільшого тому, що я маю більше практики. Я не вважаю проект закінченим, якщо в ньому немає документації, і я зазвичай пишу його з чисто егоїстичних причин: тому я можу дати людям щось читати замість того, щоб телефонувати на дзвінки та електронні листи, або я можу пригадати, про що ми говорили в минулому місяць або близько того, я можу посилатися на те, як я щось робив, якщо мені потрібно підтримати це посеред ночі.

Найкращий спосіб наблизитись до документації - це написати її ЯКЩО ВИ ЙДЕ, точно так само, як писати тестовий код. Дивно, як кілька попередньо написаних шаблонів (із заголовками, заглушками коду тощо) можуть зробити документацію простішою та швидшою. Таким чином ви можете зафіксувати зміни, як це відбувається, і у вас менше часу для покриття. Ви є більш ефективними таким чином, оскільки можете звертатися до документації так, як вам потрібно, і ви змінюєте її по ходу. Наприклад, у вікі, наприклад, полегшується оновлення, і ви можете уникнути проблем з версією документа, якщо найновіші та найбільші завжди в Інтернеті в тому самому місці, і ви можете просто надсилати посилання людям, яким потрібно їх прочитати.

Якщо ви витратите трохи часу на документування, ви ВСІ будете працювати швидше, особливо коли хтось новий приєднується до команди, оскільки їм не доведеться витрачати весь цей час на роздумування всього. Виявлення речей - це цікава частина наших завдань, але це не весело, коли вам доведеться це робити, поспішаючи налагодити виробництво. Ми всі заощадили б багато часу, якби всі написали ще пару заміток.

Чи є у вашої команди однакові проблеми з тестуванням чи написанням тестового коду? Якщо ні, то це буде простіше продати.

Ваша документація корисна багатьма способами:
1) Вам, прямо зараз, і вашим колегам, коли ви працюєте над проектом.

2) Вашим клієнтам. Наявність документації (включаючи схеми), яку можна показувати користувачам, полегшує обговорення на засіданнях, особливо якщо ви обговорюєте складні системи. Навіть якщо документація неповна, це місце, з якого слід почати.

3) людям, які успадкують вашу роботу (яка може бути навіть ви, через три роки). Багато моїх молодших колег думають, що запам'ятають речі назавжди. Я знаю, що не згадаю його минулого цього тижня, якщо не запишу його. Наявність документації позбавляє вас від необхідності витратити півдня, щоб запам'ятати, як ви щось структурували, і вам доведеться все це з'ясувати.

4) Вам та іншим, якщо ситуація стає політичною чи суперечливою. Як хтось, хто веде нотатки на зустрічах, щоб пробудити себе і боротися з нудьгою, я часто був єдиним із письмовою версією рішення. Людина, яка її записала, виграє суперечку. Згадайте це наступного разу, коли хтось скаже: "Згадайте, що ми зустрічалися минулої зими в конференц-залі 4, коли ми переходили через X? Фред був там, а хто той хлопець із бухгалтерії?"


1
+1 для пункту №3. Моя особиста документація багато разів врятувала мене.
Брендон

Я кидаю шахту в той же git repo, що і код, як правило, у Markdown (зрідка в LaTeX, коли є трохи математики).
TRiG

4

У моїх останніх кількох роботодавців у нас була вікі "для розвитку". Значні фрагменти функціональності (новий канал імпорту / експорту, як працює підсистема безпеки, де система зберігає завантажені документи тощо). Зазвичай це обов'язковий елемент, який слід заповнити перед кроком перегляду коду. На початку, як правило, трохи опір цьому, але колись комусь потрібно заглядати трохи інформації, і це вже там, у вас є ще один перетворювач.

Приємно в тому, щоб мати його у форматі вікі, це те, що ви набагато менше схильні робити все гарне форматування Word і таке, а просто виписуйте реальну інформацію, яку потрібно зберегти. Більшість (якщо не всі) пакети вікі дозволять завантажувати документи або зображення (наприклад, діаграми Visio UML або каркаси інтерфейсу користувача), тож ви також можете мати візуальні фрагменти.

Як і більшість речей, я думаю, що ви повинні прагнути зробити мінімальну суму, яка могла б спрацювати. Це не те саме, що жодне.


Це чудова пропозиція. Деякі вікі дозволяють експортувати вміст у документ .rtf. Майже ідеально підходить для PHB.
техніт

Ми використовуємо XWiki, спеціально для його здатності створювати документи у форматі PDF, RTF та HTML. Злий добро.
Jennifer S

2

Ви не можете уникнути виділення часу для написання належної документації. Збалансуйте це, проте ви хочете, залежно від того, скільки роботи вам належить, але залиште хороші 15-20% свого часу, щоб документувати зроблене. Усі в колективі повинні мати справу з цим, включаючи вашого керівника, інакше ви будете документувати лише на користь інших і нічого не отримаєте взамін. Документування повинно бути невід'ємною частиною вашого процесу розробки.


1

Документація повинна сказати, ЧОМУ ви щось робили, поки ви залишаєте HOW частину фактичного коду, а ЩО частину для одиничних тестів. Все більше - це біль. Зазвичай це досить добре для розумних людей, які просто хочуть старту.

Крім того, не забувайте підтримувати загальну архітектуру високого рівня кожного великого компонента кодової бази. Це дуже легко запроваджувати нових членів команди.

Нарешті, щоразу, коли ви додаєте невдале виправлення, посилання на базу даних помилок із коментаря - дуже корисно.


1

Ваш начальник правий, не друкуйте жодної документації UML, яку ніхто не прочитає. Ми працюємо в нашій команді - орієнтуватися в реальній моделі за допомогою представлень класових схем. Принцип полягає в тому, щоб завжди оновлювати MOF, модель UML жити з коду, і діаграма класів не лише переглядає модель, але не сама модель.

Це працює дуже добре, тому що вся складність виконується в результаті роботи на рівні моделі. Я можу відновити свій проект, написати java doc або написати uml-документацію в моделі. Це свого роду натискання і рух. Після натискання ви отримуєте живу документацію. Якщо щось не зрозуміло, я відкриваю схему класів і починаю грати з нею. Видалити з класифікаторів діаграм, додати нові класифікатори, збільшити масштаб та зменшити масштаб, показати асоціацію, видалити асоціацію тощо. Модель не змінюється, оскільки я не створюю нової інформації про модель, я просто їх використовую.

Дійсно важливо відкрити схему пакета і мати можливість прочитати на діаграмі класів коментар про те, яким повинен бути цей клас. Що цей метод повинен робити і який потік тощо.

UML є чудовим, дуже корисним, але нам слід припинити використовувати модельований розробку, щоб надати більше гнучкості та більшої ітерації на етапах моделювання / розробки. Діаграма класу оновлюється в реальному часі з коду, а документація завжди точна та доступна лише одним клацанням миші. Я не згадаю про інструмент, але якщо ви використовуєте Java та Eclipse, легко знайти, який інструмент я використовую :-)

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.