U Silicijumskoj dolini, ako slučajno zaustavite programera na ulici i pitate: „Pre početka projekta, šta bi trebalo da uradite?“ Devet od deset ljudi će verovatno odgovoriti: „Napravi dizajn dokument“. А је заједничка датотека међу инжењерима која описује функцију која треба имплементирати пре него што се напише било који код, као у Dokumenti dizajna često se sastoje od više odeljaka: design document (design doc) Овај пример Овај пример Преглед: Неколико једноставних реченица које описују функцију која се имплементира. Мотивација: Зашто примењујемо ову функцију? Преглед: Како ће функција изгледати након што буде имплементирана? Технички избори: Које техничке опције морамо да имплементирамо ову функцију? Које су предности и мане сваког? Који смо изабрали и зашто? Неопходни детаљи имплементације: Листе шаблона кода, како тестирати, како писати дневнике, итд Важно је напоменути да документ дизајна треба да остане на високом нивоу; специфична имплементација је посао кода. Примарни аутор саставља дизајнерски документ, а њихови колеге комуницирају са аутором коментаром на документ. Овај цео процес комуникације често траје неколико дана или чак недеља. Када се аутор и колеге сложе о садржају документа, може се спојити у базу кода. Ово такође означава почетак пројекта описаног у дизајнерском документу. Овај процес укључивања дизајнерских докумената у пројекте нуди бројне предности. Ако можете да формулишете своје идеје на концизном, логички јасном језику, то указује на дубоко разумевање имплементације функције. Напротив, ако не можете чак ни да изразите оно што намеравате да напишете, онда ће имплементација функције бити још тежа. Ваши колеге, коментаришући ваш дизајнерски документ, такође ће вам помоћи да прегледате своје идеје, откријете проблеме унапред, истакнете логичке недостатке и чак предложите боље методе имплементације (Ја сам више пута открио да колеге око мене доследно долазе са бољим решењима и идентификују логичке празнине у мом размишљању). First, design documents help you clarify your thoughts. Они чине свако техничко размишљање транспарентним, а база кода постаје одрживија.Ако сви одобре дизајнерски документ, онда ће сви имати више власништва над читавим пројектом и бити више вољни да помогну у побољшању квалитета кода, што доводи до високог укупног инжењерског квалитета за пројекат. Second, design documents help the entire team reach a consensus. Novi članovi tima i kolege iz drugih timova lako mogu da steknu visok nivo razumevanja celokupne kodne baze kroz dokumentaciju o dizajnu.Kada neko želi da razume status projekta, nema ništa zadovoljavajuće nego da im pošalje vezu. Third, design documents are an excellent supplement to code. У поређењу са дугим састанцима, дизајнерски документи омогућавају колегама (у различитим временским зонама) да мирно размишљају независно у своје одговарајуће вријеме, усавршавају своје мисли и пружају повратне информације аутору. Пре-развојне дискусије међу колегама могу ефикасно прегледати читав приступ дизајну, значајно смањујући ризик од дефектних дизајна (верујте ми, више пута сам био лењ и директно написао код, само да бих нашао дане мог развоја које су се показале бескорисним). Током развоја, пошто колеге већ разумеју концепт дизајна, прегледи кода постају једноставнији. Ако се проблеми јављају током пре-развоја, програмери такође могу лакше добити помоћ Fourth, design documents help teams save time. Колеги који учествују у дискусијама су често они који су заинтересовани за проблем који дизајн документ има за циљ да реши. Кроз дизајн докумената, они могу брзо формирати мале тимове и ефикасно завршити задатке са довољно страсти. Fifth, design documents are excellent for organizing teams. Документи дизајна често одражавају ауторску инжењерску писменост, јасноћу размишљања у решавању проблема и способност решавања важних проблема. Sixth, design documents are excellent material for promotion. Пошто писање дизајнерских докумената доноси толико користи тиму, зашто не сви прате ову праксу? "Писање дизајнерских докумената је превише проблема, можда ћу тек почети да кодирам прво?" Ако нађете дизајнерске документе тешко написати, то указује на то да аутор не разуме проблем довољно темељно, а њихов изабрани начин имплементације је вероватно погрешан. "Ако прескочим писање документа, већ бих завршио код." Све у умерености. Да ли је потребан дизајнерски документ зависи од дугорочног квалитета кода и одржавања пројекта. Ако је функција лако имплементирати и његова логика је једноставна, можда би било довољно само да се створи проблем да би се описала функција, а одржавање кода и усклађивање тима могу се постићи кроз прегледе кода. "Ја сам добар у овоме, гледајте ме да га имплементирам директно и импресионирам моје колеге." Док је поседовање области стручности плус, комуникација унутар тима је једнако важна. С једне стране, ако колеге не разумеју приступ аутора, тешко им је да спроведу ревизију кода; с друге стране, одржавач кода и аутор често нису иста особа. Покушајте да промените ове перцепције, изађете из своје зоне удобности, покушајте да почнете да пишете дизајнерске документе и активно учествујете у коментарисању других дизајнерских докумената. Anekdota: Jednom sam se žalio kolegi: „Zaista ne mogu da razumem kod drugih ljudi, posebno u jezicima kao što je Python, koji su lak za pisanje, ali teško za čitanje.“ Kolega je odgovorio: „Ne brini, oni ne mogu da razumeju ni tvoj.“ Tada sam se smejao i pomislio: ako ne bi bilo dokumenata za dizajn kako bi svi bili usklađeni na visokom nivou, a svi bi komunicirali samo čitajući kod drugog, koliko bi neefikasno bilo funkcionisanje tima?
