Silīcija ielejā, ja jūs nejauši apstāties programmētājs uz ielas un jautāt, "Pirms uzsākt projektu, ko jums vajadzētu darīt?" deviņi no desmit, iespējams, atbildēs, "Rakstīt dizaina dokuments." A ir kopīgs fails starp inženieriem, kas apraksta funkciju, kas jāīsteno pirms jebkura koda rakstīšanas, piemēram, Dizaina dokumenti bieži sastāv no vairākām sadaļām: design document (design doc) Šis piemērs Šis piemērs Pārskats: Dažas vienkāršas frāzes, kas apraksta iestatīto funkciju. Motivācija: kāpēc mēs izmantojam šo funkciju? Preview: Kā izskatīsies funkcija pēc tās ieviešanas? Tehniskās izvēles: Kādas tehniskās iespējas mums ir, lai īstenotu šo funkciju? Kādi ir katra priekšrocības un trūkumi? Nepieciešamās īstenošanas detaļas: saraksts ar koda veidnēm, kā pārbaudīt, kā rakstīt žurnālus utt. Ir svarīgi atzīmēt, ka dizaina dokumentam jābūt augsta līmeņa; konkrētā īstenošana ir koda darbs. Galvenais autors sagatavo dizaina dokumentu, un viņu kolēģi sazinās ar autoru, komentējot dokumentu. Šis viss komunikācijas process bieži vien ilgst vairākas dienas vai pat nedēļas.Kad autors un kolēģi vienojas par dokumenta saturu, to var apvienot koda bāzē. Šis process, kas ietver dizaina dokumentus projektos, piedāvā daudzas priekšrocības. Ja jūs varat formulēt savas idejas īsā, loģiski skaidrā valodā, tas norāda uz dziļu izpratni par funkcijas īstenošanu. Pretēji, ja jūs pat nevarat izteikt to, ko jūs plānojat rakstīt, tad funkcijas īstenošana būs vēl grūtāka. Jūsu kolēģi, komentējot jūsu dizaina dokumentu, arī palīdzēs jums pārskatīt savas idejas, atklāt problēmas iepriekš, norādīt uz loģiskām nepilnībām un pat ieteikt labākas īstenošanas metodes (esmu atkārtoti konstatējis, ka kolēģi ap mani konsekventi nāk klajā ar labākiem risinājumiem un identificē loģiskās nepilnības manā domāšanā). Īpaši pieredzējuši programmētāji komandā var ietaupīt jums ievērojamu attīstības laiku vēlāk ar vienkāršiem ieteikumiem. First, design documents help you clarify your thoughts. Tie padara ikviena tehnisko domāšanu pārredzamu, un koda bāze kļūst vairāk uzturējama.Ja dizaina dokumentu apstiprina visi, tad ikvienam būs lielāka īpašumtiesības uz visu projektu un būs vairāk gatavi palīdzēt uzlabot koda kvalitāti, kas novedīs pie augstas kopējās inženierijas kvalitātes projektam. Second, design documents help the entire team reach a consensus. Jaunie komandas locekļi un kolēģi no citām komandām var viegli iegūt augsta līmeņa izpratni par visu kodu bāzi, izmantojot dizaina dokumentus. Third, design documents are an excellent supplement to code. Salīdzinot ar garām sanāksmēm, dizaina dokumenti ļauj kolēģiem (atšķirīgās laika zonās) mierīgi domāt neatkarīgi savā piemērotā laikā, izsmalcināt savas domas un sniegt atgriezenisko saiti autoram. Kolēģu pirmsizstrādes diskusijas var efektīvi pārskatīt visu dizaina pieeju, ievērojami samazinot defektu risku (tic man, es vairāk nekā reizi esmu bijis slinks un tieši uzrakstījis kodu, tikai lai atrastu dienas, kad mana attīstība izrādījās bezjēdzīga). Attīstības laikā, jo kolēģi jau saprot dizaina koncepciju, koda pārskati kļūst vienkāršāki. Ja problēmas rodas pirmsizstrādes laikā, izstrādātāji var arī vieglāk saņemt palīdzību no kolēģiem. Pēc attīstības, dizaina dokumenti arī nodrošina pamatu Fourth, design documents help teams save time. Kolēģi, kas piedalās diskusijās, bieži vien ir tie, kas interesējas par problēmu, ko projektēšanas dokuments vēlas atrisināt. Fifth, design documents are excellent for organizing teams. Dizaina dokumenti bieži atspoguļo autora inženierzinātni, domāšanas skaidrību problēmu risināšanā un spēju atrisināt svarīgas problēmas. Sixth, design documents are excellent material for promotion. Tā kā dizaina dokumentu rakstīšana rada tik daudz priekšrocību komandai, kāpēc ne visi seko šai praksei? "Dizaina dokumentu rakstīšana ir pārāk daudz nepatikšanas, varbūt es tikai sākšu kodēt vispirms?" Ja jūs atradīsiet dizaina dokumentus grūti rakstīt, tas norāda, ka autors nesaprot problēmu pietiekami rūpīgi, un viņu izvēlētais īstenošanas veids, iespējams, ir nepareizs. "Ja es izlaistu rakstīt dokumentu, es jau būtu pabeidzis kodu." Viss mērenībā. Vai dizaina dokuments ir nepieciešams, ir atkarīgs no projekta ilgtermiņa koda kvalitātes un uzturam. Ja funkciju ir viegli īstenot un tās loģika ir vienkārša, varbūt vienkārši radot problēmu, lai aprakstītu funkciju, būtu pietiekami, un kodu uzturēšanu un komandas saskaņošanu var panākt, izmantojot koda pārskatus. Tomēr sarežģītām funkcijām joprojām ir ieteicams rakstīt dizaina dokumentu. "Es esmu labs šajā jomā, skatiet mani īstenot to tieši un iespaidot savus kolēģus." Kamēr ir jomas zināšanas ir plus, komunikācija komandā ir tikpat svarīga. no vienas puses, ja kolēģi nesaprot autora pieeju, viņiem ir grūti veikt koda pārskatus; no otras puses, koda uzturētājs un autors bieži vien nav viena un tā pati persona. Centieties mainīt šīs uztveres, iziet no savas komforta zonas, mēģiniet sākt rakstīt dizaina dokumentus un aktīvi piedalīties komentējot citu dizaina dokumentus. Anekdote: Es reiz sūdzējos kolēģim: "Es tiešām nevaru saprast citu cilvēku kodu, it īpaši tādās valodās kā Python, kuras ir viegli rakstīt, bet grūti lasīt." Kolēģis atbildēja: "Neuztraucieties, viņi nevar saprast arī tavu."
