Joel on Software

Joel on Software   Joel pri Softvaro

 

Aliaj "Joel on Software"-artikoloj en Esperanto

Aliaj "Joel on Software"-artikoloj en la angla

Retpoŝtu al la aŭtoro (nur angle)

 

La Joel-Testo: 12 Paŝoj al pli Bona Kodo


de Joel SPOLSKY
Tradukita de Russ Williams
merkredon, la 9-an de aŭgusto, 2000

Ĉu vi aŭdis pri SEMA? Ĝi estas iom esotera metodo por mezuri kiel bona estas softvarteamo. Ne, atendu! Ne klaku tiun ligilon! Postulos ĉirkaŭ ses jarojn nur por kompreni tiun materialon. Do mi kreis mian propran, tre malresponsan, kaĉan teston por mezuri la kvaliton de softvarteamo. La bonega afero pri ĝi estas ke ĝi postulas ĉirkaŭ tri minutojn. Per la tempo kiun vi ŝparas, vi povas doktoriĝi pri medicino.

La Joel-Testo

  1. Ĉu vi uzas versitenan sistemon?
  2. Ĉu vi povas munti per unu paŝo?
  3. Ĉu vi munti ĉiutage?
  4. Ĉu vi havas datumbazon de cimoj?
  5. Ĉu vi riparas cimojn antaŭ ol vi skribas novan kodon?
  6. Ĉu vi havas aktualan horaron?
  7. Ĉu vi havas specifon?
  8. Ĉu programistoj havas mallaŭtajn laborkondiĉojn?
  9. Ĉu vi uzas la plej bonajn ilojn, kiujn mono povas aĉeti?
  10. Ĉu vi havas testistojn?
  11. Ĉu novaj kandidatoj verkas kodon dum sia intervjuo?
  12. Ĉu vi uzas koridoran testadon de utileco?

La bona afero pri La Joel-Testo estas ke facilas diri rapide jesne por ĉiu demando. Vi ne bezonas kalkuli linioj-de-kodo-en-tago aŭ averaĝa-nombro-de-cimoj. Donu al via teamo unu poenton por ĉiu "jes". La malfeliĉa afero pri La Joel-Testo estas ke vi ege maldevas uzi ĝin por certigi ke via softvaro por nuklea centralo estas maldanĝera.

12 poentoj perfektas, 11 tolereblas, sed 10 aŭ malpli signifas gravajn problemojn. Fakte la plejmulto da softvarorganizoj agas kun 2 aŭ 3 poentojn, kaj ili bezonas grandan helpon, ĉar kompanioj kiel Microsoft agas je 12 ĉiam.

Kompreneble, ĉi tiuj ne estas la solaj faktoroj, kiuj decidas sukceson aŭ ne: precipe, se vi havas bonegan softvarteamon verkantan produkton kiun neniu deziras, nu, homoj ne deziros ĝin. Kaj eblas imagi teamon de "sikarioj" kiu ne faras iun ajn el ĉi tiu listo, kiu tamen efektive produktas nekredeblan softvaron, kiu ŝanĝas la mondon. Sed, kutime, se vi bonfaras ĉi tiujn 12 aferojn, vi havos disciplinan teamon, kiu povas konforme liveri.

1. Ĉu vi uzas versitenan sistemon?
Mi uzis komercajn versitenajn sistemojn, kaj mi uzis CVS, kiu senpagas, kaj permersu min diri ke CVS estas sufiĉe bona. Sed se vi ne havas versitenan sistemon, vi streĉiĝos multe provi kunlaborigi programistojn. Programistoj havas neniun metodon por scii kion faris la aliaj. Eraroj ne povas nuliĝi facile. La alia bona afero pri versitenaj sistemoj estas ke la fontkodo mem estas elŝutita sur ĉies komputiloj -- mi neniam aŭdis pri projekto uzanta versitenan sistemon, kiu perdis multan kodon.

2. Ĉu vi povas munti per unu paŝo?
Per ĉi tio, mi volas diri: kiom da paŝoj postulas fari livereblan muntaĵon el la plej lastatempa kapto de fontkodo? Kun bonaj teamoj, ekzistas unuopa skripto, kiun oni povas lanĉi kaj kiu elŝutas freŝan version, remuntas ĉiun kodlinion, faras la EXE-oj, je ĉiuj diversaj versioj, lingvoj, kaj #ifdef-kombinaĵoj, kreas la instalpakaĵon, kaj kreas la finan komunikilon: KD, elŝuta retpaĝo, ajn.

Se la procezo postulas pli ol unu paŝon, ĝi eraremas. Kaj kiam vi proksimiĝas al la fina liverado, vi volas havi tre rapidan ciklon ripari la "lastan" cimon, verki la finajn EXE-ojn, ktp. Se postulas 20 paŝojn por traduki la kodon, lanĉi la instalmuntilon, ktp, tial vi freneziĝos kaj vi faros stultajn erarojn.

Pro ĉi tiu kialo, la lasta kompanio, kie mi laboris, interŝanĝis WISE por InstallShield: ni postulis ke la instalprocezo eblas lanĉiĝi, per skripto, aŭtomate, tranokte, uzante la NT-vicigilon, kaj WISE ne povis lanĉiĝi de la vicigilo tranokte, do ni forĵetis ĝin. (La agrablaj uloj de WISE nun promesas al mi ke la plej lastatempa versio nun bontraktas notkajn muntadojn.)

3. Ĉu vi munti ĉiutage?
Kiam vi uzas versitenan sistemon, iam unu programisto akcidente enskribas ion, kiu fuŝas la muntaĵon. Ekzemple, ili enmetis novan fontdosieron, kaj ĉio tradukiĝas bone sur ilia maŝino, sed ili forgesis enskribi la fontdosieron al la kododeponejo. Do ili ŝlosas sian maŝinon kaj iras hejmen, nescia kaj feliĉa. Sed neniu alia povas labori, do ili devas iri hejmen ankaŭ, malfeliĉe.

Fuŝi la muntaĵon estas tiom malbone (kaj tiom ofte) ke helpas munti ĉiutage, por certigi ke neniu fuŝado restas nerimarkata. Kun grandaj teamoj, bona metodo por certigi ke fuŝoj tuj riparaĝas estas fari la tagan muntaĵon je, ekzemple, tagmanĝtempo. Ĉiuj faras tiom da enskriboj, kiom eblas antaŭ tagmanĝo. Kiam ili revenas, la muntaĵo finitas. Se sukcesas, bone! Ĉiuj akiras la nunan version de la fonto kaj daŭras labori. Se la muntaĵo fuŝitas, vi riparu ĝin, sed ĉiu alia povas daŭri kun la antaŭa nefuŝita versio de la fonto.

Por la Excel-teamo ni havis regulon ke kiu ajn fuŝis la muntaĵon, kiel ilia "puno", devas varti la muntaĵojn ĝis iu alia fuŝis ĝin. Ĉi tiu estis bona voligo por ne fuŝi la muntaĵon, kaj bona metodo por cikli ĉiujn tra la muntprocezo por ke ĉiu lernu kiel ĝi funkcias.

Legu plu pri tagaj muntaĵoj en mia artikolo Tagaj Muntaĵoj estas Via Amiko.

4. Ĉu vi havas datumbazon de cimoj?
Ne gravas al mi, kion vi diras. Se vi verkas kodon, eĉ en teamo de unu, sen organizita datumbazo listanta ĉiujn konatajn cimojn en la kodo, vi liveros malbonan kodon. Multaj programistoj pensas ke ili povas memori la cimoliston en siaj kapoj. Volapukaĵo. Mi ne povas memori pli ol du aŭ tri cimojn samtempe, kaj la sekvantan matenon, aŭ dum la urĝo de liverado, ili forgesiĝas. Vi absolute devas kontroladi cimojn formale.

Cimdatumbazoj povas malsimpli aŭ simpli. Minimume utila cimdatumbazo devas enhavi la jenan datumon pri ĉiu cimo:

  • ĉiuj paŝoj por reprodukti la cimon
  • atendata konduto
  • observita (cima) konduto
  • kiu respondecas pri ĝi
  • ĉu ĝi estas riparita aŭ ne

Se la malsimpleco de softvaro por kontroladi cimojn estas la sola kialo baranta vian kontroladon de viaj cimoj, nur verku simplan 5-kolumnan tabelon kun ĉi tiuj gravegaj kampoj kaj komencu uzi ĝin.

Por pli pri cimkontrolado, legu Sendolora Cimkontrolado.

5. Ĉu vi riparas cimojn antaŭ ol vi skribas novan kodon?
La unua versio de Microsoft Word por Windows estis dirata "mortmarŝa" projekto. Ĝi daŭris senfine. Ĝi daŭre malfruiĝis. La tuta teamo laboris absurdajn horojn, la projekto prokrastiĝis denove, kaj denove, kaj denove, kaj la streĉo nekredeblis. Kiam la damna aĵo finfine deliveriĝis, malfrua plurjare, Microsoft sendis la tutan teamon al Cancun, Meksikio por ferio, tiam sidiĝis por grava sinekzamenado.

Kion ili konstatis estis ke la projektdirekistoj insistis sekvi la "horaron" tiom, ke programistoj simple urĝis tra la kodprocezo, skribante ege malbonan kodon, ĉar la cimriparada fazo ne estis parto de la formala horaro. Ekzistis neniu peno konservi malaltan cimnombron. Tute male. Onidire iu programisto, kiu devis skribi kodon por kalkuli la altecon de tekstlinio, simple skribis return 12; kaj atendis la cimraporton dirantan ke lia funkcio ne ĉiam pravas. La horaro estis nura listo de ebloj atendantaj ŝanĝiĝi en cimojn. Dum la nekropsio, ĉi tio nomiĝis "metodaro de infinitaj difektoj".

Por korekti la problemon, Microsoft universale ekuzis ion nomitan "metodaro de nul difektoj". Multaj programistoj en la kompanio subridis, ĉar ĝi ŝajnis ke direkcio kredis ke ili povas malaltigi la cimnombron per direktora dekreto. Efektive, "nul difektoj" signifis ke ĉiam la ĉefa celo estas nuligi cimojn antaŭ ol skribi novan kodon. Jen la kialo.

Kutime, ju pli longe oni prokrastas antaŭ ripari cimon, des pli kostas (laŭ tempo kaj mono) ripari ĝin.

Ekzemple, kiam vi faras tajperaron aŭ sintakseraron, kiun la tradukilo kaptas, ripari ĝin bagatelas.

Kiam vi havas cimon en via kodo, kiun vi rimarkas kiam vi unue lanĉas ĝin, tiam vi povas ripari ĝin rapide, ĉar la tuta kodo estas ankoraŭ freŝa en via menso.

Se vi trovas cimon en iu kodo, kiun vi verkis antaŭ kelkaj tagoj, tial ĉasi ĝin postulos iom da tempo, sed kiam vi relegos la kodon, kiun vi skribis, vi memoros ĉion kaj vi povos ripari la cimon dum modera tempo.

Sed se vi trovas cimon en kodo, kiun vi skribis antaŭ kelkaj monatoj, vi probable forgesis multajn aferojn pri tiu kodo, kaj ripari pli malfacilas. Tiam vi eble riparas la kodon de iu alia, kaj ili eble feriumas en Arubo; tiukaze, la cimriparado estas kiel scienco: vi devas esti malrapida, metoda, kaj detalema, kaj vi ne povas certi kiom da tempo postuliĝos por trovi la solvon.

Kaj se vi trovas cimon en kodo jam liverita, la riparado nekredeble multkostas.

Tio estas unu kialo por ripari cimojn tuj: ĉar ĝi postulas malpli da tempo. Ekzistas alia kialo, kiu rilatas al la fakto ke pli facilas prognoski la tempon por skribi novan kodon ol por ripari nunan cimon. Ekzemple, se mi demandus al vi kiom longe por skribi kodon por ordigi liston, vi povus doni al mi sufiĉe bonan takson. Sed se mi demandus al vi kiom longe por ripari tiun cimon, kiu malfunkciigas vian kodon se Internet Explorer 5.5 estas instalita, vi ne povas eĉ konjekti, ĉar vi ne scias (laŭ difino) kio kaŭzas la cimon. Ĉasi ĝin povas postuli 3 tagojn, aŭ povas postuli 2 minutojn.

Ĉi tio signifas, ke se vi havas horaron kun multajn cimojn ankoraŭ riparendajn, tial la horaro ne fidindas. Sed se vi riparis ĉiujn konatajn cimojn, kaj la restaĵo estas nur nova kodo, tial via horaro estos mirfrapante pli akurata.

Alia bonega afero pri teni la cimnombron je nul estas ke vi povas reagi pli rapide al konkurenco. Iuj programistoj konsideras ĉi tiun kiel teni la produkton pretan por liveri ĉiam. Tiam, se via konkurenculo aperigas bonegan novan eblon, kiu ŝtelas viajn klientojn, vi povas realigi nur tiun eblon kaj liveri tuj, sen la postulo por ripari grandan amason de cimoj.

6. Ĉu vi havas aktualan horaron?
Nun temas pri horaroj. Se via kodo estas iel ajn grava al la negoco, ekzistas multaj kialoj, kial gravas al la negoco kiam la kodo finiĝos. Programistoj fifame koleremas pri horarofarado. "Ĝi estos finita kiam ĝi estos finita!" ili krias al la negoculoj.

Malbonŝance, tio ne sufiĉas. Ekzistas tro multaj plandecidoj, kiujn la negoco bezonas fari tre antaŭ la kodlivero: montroj, komercekspozicioj, reklamado, ktp. Kaj la sola metodo por fari ĉi tion estas havi horaron, kaj aktualigi ĝin.

La alia grava afero pri havi horaron estas ke ĝi igas vin decidi kiujn eblojn faros vi, kaj tiam ĝi igas vin elekti la plej malgravajn eblojn kaj eltranĉi ilin, anstataŭ iri en "eblomalsanon" (kreskado de tro multaj ebloj; en la angla oni diras "featuritis" aŭ "scope creep").

Prizorgado de horaroj ne necese malfacilas. Legu mian artikolon Sendoloraj Softvarhoraroj (Painless Software Schedules), kiu priskribas simplan metodon por fari bonegajn horarojn.

7. Ĉu vi havas specifon?
Specifoskribado estas kiel fadenpurigo de la dentojn: ĉiuj konsentas ke ĝi estas bona, sed neniu faras ĝin.

Mi ne scias la kialon, sed probable tio estas ĉar preskaŭ ĉiuj programistoj malamas skribi dokumentojn. Tial, kiam teamoj, konsistantaj nur el programistoj, atakas problemon, ili preferas prezenti sian solvon per kodo, anstataŭ per dokumentoj. Ili pli preferas tuj skribi kodon ol fari specifon unue.

Dum la projekta fazo, kiam vi malkovras problemojn, vi povas ripari ilin facile per redakti kelkajn linion de teksto. Post la kodo skribiĝis, la kosto de problemriparado estas ege pli alta, ambaŭ emocie (homoj malamas forĵeti kodon) kaj tempe, do estas kontraŭado al efektive ripari la problemojn. Softvaro, kiu ne konstruiĝis laŭ specifo, kutime malbone projektiĝas kaj la horaro ĥaosiĝas. Ĉi tio ŝajne estis la problemo ĉe Netscape, kie la unuaj kvar versioj iĝis tia miksamaso, ke direkcio stulte decidis forĵeti la kodon kaj rekomenci. Kaj tiam ili sameraris denove pri Mozilla, kreante monstron kiu neregebliĝis kaj postulis kelkajn jarojn por atingi fruan ("alfan") testadon.

Mia propra teorio estas ke ĉi tiu problemo ripareblas per instruo al programistoj esti malpli malvolantaj skribantoj, per sendi ilin al intensa kurso pri skribado. Alia solvo estas dungi inteligantajn program-administristojn kiuj krei la skribitan specifon. Ĉiuokaze, vi devas efikigi la simplan regulon "neniu kodo sen specifo".

Lernu ĉion pri skribado de specifoj per legado de mia 4-parta serio.

8. Ĉu programistoj havas mallaŭtajn laborkondiĉojn?
Ekzistas amplekse dokumentitaj produktivo-gainoj rezultantaj per dono al sciolaboristoj spacon, kvieton, kaj privatecon. La klasika libro pri softvar-administrado Peopleware montras ĉi tiujn produktivajn bonecojn amplekse.

Ĉi tie estas la problemo. Ni ĉiuj scias ke sciolaboristoj laboras plej bone per eniri "fluon", ankaŭ nomita kiel "esti en la zono", kie ili tute fokusas sur sian laboron kaj tute ignoras sian ĉirkaŭaĵon. Ili forgesas tempon kaj fari bonegaĵojn per absoluta sinkoncentrado. Ĉi tiam estas kiam ili faras ĉiun sian produktivan laboron. Skribistoj, programistoj, sciencistoj, kaj eĉ sportistoj diros al vi pri esteco en la zono.

La problemo estas ke eniri "la zonon" ne facilas. Kiam vi penas mezuri ĝin, ŝajnas ke postulas ĉirkaŭ 15 minutojn por eklabori je maksimuma produktivo. Iam, se vi lacas aŭ jam faris multan krean laboron je tiu tago, vi simple ne povas eniri la zonon, kaj vi pasigas la restaĵon de via labortago lantante, legante la ttt-on, ludante Tetris.

La alia problemo estas ke tiom facilas frapiĝi el la zono. Bruo, telefonoj, iri por tagmanĝi, veturi 5 minutojn al Starbucks por kafeo, kaj interrompoj de kolegoj — precipe interrompoj de kolegoj — ĉiuj frapas vin el la zono. Se kolego demandas ion al vi, kaŭzante 1-minutan interrompon, sed ĉi tio frapas vin el la zono sufiĉe forte, ke postulas duonan horon por produktiviĝi denove, via tuta produktivo ege rompiĝas. Se vi estas en laŭta komuna oficejo, kiel kafeinigitaj novkompanioj amas krei, kun merkatuloj kriante je la telefono apud la programistoj, via produktivo plonĝos dum sciolaboristoj interrompiĝas tempo post tempo kaj neniam eniras la zonon.

Kun programistoj, precipe malfacilas. Produktivo dependas de la povo ĵongli multajn etajn detalojn en tuja memoro samtempe. Ia interrompo povas faligi ĉi tiujn detalojn. Kiam vi rekomencas labori, vi ne povas memori iujn ajn el la detaloj (ekzemple nomojn de variabloj, aŭ kiom vi realigis de tiu ordigalgoritmo), kaj vi devas ankoraŭ reserĉi ĉi tiujn aferojn, kio ege malrapidigas vin ĝis vi reeniri la zonon.

Ĉi tie estas la simpla matematiko. Ni supozu (kiel la indico sugestas ŝajne), ke se ni interrompas programiston, eĉ dum nur unu minuto, ni efektive forĵetas 15 minutojn da produktivo. Dum ĉi tiu ekzemplo, ni metas du programistojn, Jeff kaj Mutt, en malfermaj ĉeloj apudaj en tipa Dilberteksa bovidaĵa bieno. Mutt ne povas memori la nomon de la unikoda versio de la funkcio strcpy. Li povus serĉi ĝin, kio postulas 30 sekundojn, aŭ li povus demandi al Jeff, kio postulas 15 sekundojn. Ĉar li sidas apud Jeff, li demandas al Jeff. Jeff distriĝas kaj perdas 15 minutojn da produktivo (por ŝpari 15 sekundojn por Mutt).

Nun ni translokigu ilin en apartajn oficejojn kun muroj kaj pordoj. Nun kiam Mutt ne povas memori la nomon de tiu funkcio, li povus serĉi ĝin, kio ankoraŭ postulas 30 sekundojn, aŭ li povus demandi al Jeff, kio nun postulas 45 sekundojn kaj postulas stariĝi (nefacila tasko, pro la tipa korpa sano de programistoj!). Do li serĉas ĝin. Do nun Mutt perdas 30 sekundojn da produktivo, sed ni ŝparas 15 minutojn por Jeff. Aha!

9. Ĉu vi uzas la plej bonajn ilojn, kiujn mono povas aĉeti?
Kodskribado je tradukita lingvo estas unu el la lastaj aferoj, kiujn ankoraŭ ne povas fariĝi tuj sur kutima doma komputilo. Se via traduka procezo postulas pli ol kelkaj sekundoj, akiri la plej novan kaj plej bonegan komputilon ŝparos tempon por vi. Se tradukado postulas eĉ 15 sekundojn, programistoj enuiĝos dum la tradukilo ruliĝas, kaj komencos legi Ĝangalo, kiu ensuĉos ilin kaj mortigos horojn da produktivo.

Erarserĉado de uzulinterfaca kodo kun unuopa ekrano doloros, se ne maleblas. Se vi verkas uzulinterfacon, du ekranoj tre helpegas.

La plejmulto de programistoj fine devas trakti rastrumojn por piktogramoj aŭ ilobretoj, kaj la plejmulto de programistoj ne havas bonan rastrumo-redaktilon. Peni uzi Microsoft Paint por trakti rastrumojn estas ŝerco, sed tio estas kion multaj programistoj devas fari.

Dum mia lasta dungo, la sistemestro daŭre sendemis mi aŭtomatan spamon, plendante ke mi uzis pli ol ... nekredeble ... 220 megabajtojn da diskspaco sur la servilo. Mi menciis ke, laŭ la prezo da diskoj nuntage, la kosto de ĉi tiu spaco estis ege malpli ol la kosto de la neceseja papero, kiun mi uzis. Pasigi eĉ 10 minutojn por purigi mian dosierujon estus mirinda malŝparo de produktivo.

La plej bonaj softvarteamoj ne torturas siajn programistojn. Eĉ malgrandaj frustroj kaŭzitaj de uzado de malfortaj iloj sumas, igante programistojn koleremi kaj malfeliĉi. Kaj kolerema programisto estas malproduktiva programisto.

Plue... programistoj facile subaĉetiĝas per doni al ili la plej novajn, bonegajn aĵojn. Ĉi tio estas pli malmultkosta metodo por laborigi ilin por vi, ol efektive pagi konkurencajn salajrojn!

10. Ĉu vi havas testistojn?
Se via teamo ne havas asignitajn testistojn, almenaŭ unu por ĉiuj du aŭ tri programistoj, vi aŭ liveras fuŝajn produktojn, aŭ malŝparas monon ĉar vi havas $100/horajn programistojn por fari taskojn, kiuj eblas de $30/horaj testistoj. Magrado pri testistoj estas tia absurda falsa ekonomio, ke mi simple miregas ke pli da homoj ne konstatas.

Legu Kvin Ĉefaj (Malĝustaj) Kialoj Kial Vi Ne Havas Testistojn, artikolo kiun mi skribis pri ĉi tiu temo.

11. Ĉu novaj kandidatoj verkas kodon dum sia intervjuo?
Ĉu vi dungus magiiston sen peto ke ili montri kelkajn magiojn? Kompreneble ne.

Ĉu vi dungus proviantisto por via nupto sen gustumo de ilia manĝo? Mi dubas. (Krom se ĝi estas Onklino Marĝa, kaj ŝi malamus vin senfine se vi ne permesus al ŝi kuiri ŝian "faman" hepataĵan kukon).

Tamen, ĉiutage, programistoj dungiĝas pro impona resumo, ĉar la intervjuisto ĝuis babili kun ili. Aŭ oni demandas al ili malgravaĵojn ("kiel diferencas CreateDialog() al DialogBox()?"), kiuj demandeblas per legado de la dokumentaro. Vi ne zorgas ĉu ili parkeris milojn da bagatelojn pri programado, vi zorgas ĉu ili povas verki kodon. Aŭ, eĉ pli malbone, oni demandas al ili "AHA!"-demandojn: el tiu tipo, kiu ŝajnas facila kiam vi scias la respondon, sed se vi ne scias la respondon, ili maleblas.

Bonvolu, simple ĉesi fari ĉi tion. Faru ion ajn, kion vi volas, dum intervjuoj, sed igu la kandidaton skribi iom da kodo. (Por plia sugestado, legu mian Gerila Gvido de Intervjuado.)

12. Ĉu vi uzas koridoran testadon de utileco?
Koridora utiltesto estas kiam vi prenas la sekvan homon kiu preterpasas en la koridoro kaj igas ilin uzi la kodon, kiun vi ĵus skribis. Se vi faras tiun al kvin homoj, vi lernos 95% de tio, kio lernindas pri uzadaj problemoj en via kodo.

Desegno de bona uzula interfaco ne tiom malfacilas, kiom vi pensus, kaj tio necesas se vi volas ke klientoj amos kaj aĉetos vian produkton. Vi povas legi mian senpagan retlibron pri UI-desegno, kiu estas mallonga manlibro por programistoj.

Sed la plej grava afero pri uzulaj interfacoj estas ke, se vi montras vian programon al kelkaj homoj (fakte, kvin aŭ ses sufiĉas), vi rapide malkovros la plej grandajn problemojn, kiuj ĝenas homojn. Legu la artikolon de Jakob NIELSEN, kiu klarigas kial. Eĉ se vi havas mankon de UI-desegnaj lertoj, se vi igas vin fari koridorajn testojn, kiuj senkostas, via UI estos pli pli bona.

Kvar Metodoj Por Uzi La Joel-Teston

  1. Gradu vian propran softvaran organizacion, kaj diru al mi kiel ĝi gradiĝas, por ke mi klaĉu.
  2. Se vi estras programteamon, uzu ĉi tiun kiel kontrolliston por certigi ke via teamo funkcias tiom bone, kiom eblas. Kiam vi ekgajnas 12, vi povas lasi viajn programistojn solaj kaj laboras plentempe por ĉesigi la komerculojn ĝeni ilin.
  3. Se vi penas decidi ĉu akcepti programistan oficon, demandu al via ebla dungisto kiel ili rangas je ĉi tiu testo. Se tro malaltas, certigu ke vi havos la aŭtoritaton por ripari ĉi tiujn aferojn. Alie vi frustriĝos kaj malproduktivos.
  4. Se vi estas investisto faranta esploradon por juĝi la valoron de programteamo, aŭ se via softvara kompanio pensas pri fuzio kun alia, ĉi tiu testo povas helpi.


Ĉi tiu artikolo unue aperis en la angla kun la titolo The Joel Test: 12 Steps to Better Code  

Joel SPOLSKY fondis Fog Creek Software, malgranda softvarkompanio en Novjorko. Li diplomiĝis ĉe la Universitato Yale, kaj li laboris kiel programisto kaj direktisto ĉe Microsoft, Viacom, kaj Juno.


La enhavo de ĉi tiuj paĝoj prezentas la opinioj de unu persono.
Ĉiu enhavo kopirajtita ©1999-2005 de Joel SPOLSKY. Ĉiuj rajtoj rezervitaj.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky