Arĥitekturaj Principoj por Programadaj Teamoj
Ne diru al mi kiel laboreme vi laboras. Diru al mi kiom da laboro vi faris.
—James J. LING
Enhavotabelo
- Deveno
- Enkonduko
- Ĉiu ŝanĝo devas esti serioze ekzamenita
- Ŝanĝo ne devas postuli pli ol unu teamo
- Kapablas malpligrandiĝi viaj teamoj kaj ankaŭ grandiĝi
- Kresku kulturon, ne vivi ekster la lando
- Elektu programlingvon kiu skalas
- Ne igu homojn fari la laborojn de maŝino
- Uzu malfermitan kodon ĉie oni povas
- Disponigo devas esti aŭtomata per premo de butono
- Minimumigu agordon
- Ruleblas testoj sen aldona kosto
- Uzu monotonajn datenbazajn semantikojn
- Inkluzivu altgradigeblecon en via dinamika apa modelo
- Estroj estas planantoj, ne prokurantoj
- Malsukcesi plani estas plano por malsukceso
- Arĥitekturo ne estas opcia
- Gravas motivoj
- Igu retrokuplajn iteraciojn mallonga
- Mezurado ne estas anstataŭigo de juĝo
Deveno
Kun eksplicita permeso, la jena artikolo estas reafiŝo de bloga afiŝo de sinjoro François-René Rideau (Faré) en la 29-an de majo 2013. La ideoj de Fare kiel programado devas esti farita, staris tra la tempo.
Enkonduko
Multaj programadaj organizoj malsukcesas sekvi ĉi tiujn principojn kaj pagi la punon, kiu kondukas al malsukceso. Guglo ne faras la erarojn pri iri kontraŭ ili, sed kelkaj projektoj ĉe ITA faris antaŭe.
Ĉiu ŝanĝo devas esti serioze ekzamenita
Kodrevuoj ne nur plibonigas kodan kvaliton per havi pli da okuloj por trovi cimojn, sed pli grave ili kreas la reciprokan scion de la kodbazo, kaj transpolenan menson de la teamanoj. Ĉi tio aspektas ke ĝi malrapidigas onin en la mallonga tempo, sed ĝi estas esenca en la longa tempo. Se oni bezonas havi kritikan riparon, nun, interropu kolegon kaj nur prenu la kritikan revuon tuj nun. Se estas urge ke oni bezonas revuon nun kaj ne haveblas kolegon ĉi-momente (en la mezo de la nokto, aŭ ili estas malsana, en ferio, aŭ en retiriĝo), do igu ĝin revuita poste, sed ankoraŭ igu ĝin revuita (kaj kompreneble rulu aŭtomatajn testojn — via infrastrakturo ne permesas onin kaj disponigi sen tiuj testoj, ĉu ne?); sed tiaj retroefikaj revuoj estas simptomoj de paneo kaj devas ekzisti kiel esceptoj. Ĉiom da kodo devas esti traktita al samaj normoj de kvalito, revuado, kaj testado. Ne estas esceptoj. Ĉi tio bezonas, ke por ĉiom da kodo kiun vi skribas, oni devas krei lingvon kaj taŭgan muntadan kaj testadan infrastrukton kiuj estas parto de la kulturo kiun oni estas aktive kreskigas. Ajna «skripto» skribita en maniero kiu malobservas ĉi tiujn normojn estas paneo, kiom ajn necesa ili estas unue, aŭ simptomo de pli granda paneo. Pli da tio malsupre.
Ŝanĝo ne devas postuli pli ol unu teamo
Ĉiu ŝanĝo postulas almenaŭ unu teamon ĉar ĉiom da kodo devas esti revuita. Sed ĉiufoje du aŭ pli teamoj estas engaĝita por realigi kaj disponigi solan ŝanĝon, ĉi tiu implicas pli da kosto kaj tempo por sinkronigi ĉi tiujn teamojn al unu aŭ pluraj interfacoj, kiu faras pli malrapidan, retrokulpan iteracion. Pli malbone, ĉi tiuj interfacoj kreas konfliktojn de intereso kaj iĝas la lokuso de cikatra histo dum ĉiu teamo kreas tavolojn de nedezirata programada kodaĵo por protekti sin el la ŝanĝoj de aliaj teamoj. Pro la «investo» de ĉiu teamo en ĝi, ĉi tiuj interfacoj travivi longe post ia ajn valideco kiun ili havis antaŭe, kiu signifas ke oni iras senfine uzi la interfacojn oni forĵetis sen ia ajn desegno antaŭe kiam oni ne havis sperton. Ne dividu viajn teamojn al horizontalaj nivelo de funkciado. Eblus escepto kiam la pli malsupra nivelo sekvas krudan interfacon, kaj estas facile eksperimenti sen ĝi kaj forŝalti de ĝi kiam bezonata, module ŝanĝo en prezo kaj kvalito. Notu ke homoj kun similaj roloj (e.g. ĉiom da testaj inĝenieroj) tendencas kunhavigi komunajn koncernojn kaj kunvenas, interŝanĝas informojn kaj kreas ilojn kune; tio bonas kaj devas esti kuraĝigita, ne malebligita; sed tio ne devas preni utilan eron de decidiĝo kaj havi respondecon, kaj ne davas esti traktita kiel «teamo».
Kapablas malpligrandiĝi viaj teamoj kaj ankaŭ grandiĝi
Aldoni homajn risurcojn ne bezonas multe da pensado, sed ĝi bezonas pensadon por aldoni ilin efike.