Joel on Software

Joel on Software   Joel ukol sa Software

 

Ibang artikulong "Joel On Software" na nasa Filipino

Ibang artikulong "Joel On Software" na nasa Ingles

Iemail ang may akda (sa Ingles lamang)

 

Ang Joel Test: 12 Hakbang Para Sa Mas Maayos na Code


Ni Joel Spolsky
Isinalin nina Glenn Gamboa at Cathy Victor
Inedit ni Val J. Gonzales
Ika-9 ng Agosto, 2000

Narinig mo na ba ang SEMA? Ito ay medyo mahiwagang sistema para sukatin kung gaano kahusay ang isang software team. Teka, sandali! Huwag mo munang sundan ang link na iyan! Aabutin ka ng mga anim na taon para lang maintindihan iyan, kaya gumawa ako ng aking sariling test, na sobrang iresponsable at di perpekto, upang mai-rate ang kalidad ng isang software team. Ang magandang bagay dito ay aabutin lamang ito ng 3 minuto. Sa dami ng oras na maiipon mo, makakapasok ka pa sa medical school.

Ang Joel Test

  1. Gumagamit ka ba ng source control?
  2. Makakagawa ka ba ng build sa isang hakbang?
  3. Gumagawa ka ba ng mga builds araw-araw?
  4. Mayroon ka bang bug database?
  5. Nag-aayos ka ba ng bug bago gumawa ulit ng bagong code?
  6. Mayroon ba bang iskedyul na up-to-date?
  7. Mayroon ka bang spec?
  8. Tahimik ba ang lugar na pinagtatrabahuan ng mga programmers?
  9. Gumagamit ka ba ng mga pinakamagandang kagamitan na mabibili ng pera?
  10. Mayroon ka bang mga taga-test?
  11. Ang mga bagong kandidato ba ay nagsusulat ng code habang iniinterview?
  12. Gumagawa ka ba ng hallway usability testing?  

Ang maganda sa Joel Test ay madaling masagot ng oo o hindi ang bawat tanong. Di mo na kailangang pag-isipan ang lines-of-code-per-day o ang average-bugs-per-inflection-point. Bigyan mo ang iyong team ng 1 punto sa bawat sagot na "oo". Ang hindi lang maganda sa Joel Test ay hindi mo dapat itong gamitin para makasiguro na ang nuclear power plant software mo ay ligtas.

Ang score na 12 ay perpekto; ang 11 ay puwede na, pero pag 10 pababa, may malaki kang problema. Sa totoo lang, karamihan sa mga software organizations ay mayroong score na 2 o 3, at kailangan nila ng seryosong tulong, dahil ang mga kumpanyang kagaya ng Microsoft ay parating tumatakbo sa 12.

Hindi lang naman ito ang mga factors upang malaman kung tagumpay o hindi ang isang software organization: halimbawa, kung mayroon ka ngang mahusay na software team na gumagawa ng produktong wala namang may gusto, balewala rin ito. Posibleng mangyari na ang isang grupo ng "gunslingers" na hindi gumagawa ng mga ganitong bagay na makagawa ng napakagandang software na makapagpapabago ng mundo. Pero, kung titingnang pantay-pantay ang lahat, kung makuha mo itong 12 bagay nang tama, magkakaroon ka ng isang disiplanadong pangkat na palaging makakadeliver.

1. Gumagamit ka ba ng source control?

Nakagamit na ako ng mga komersyal na produktong pang-source control, at nakagamit na ako ng CVS, na libre at masasabi ko namang maayos. Ngunit kung wala kang source control, magkakaproblema ka lang kung paano mo mapagtatrabahong magkakasama ang mga programmers. Wala silang paraan para malaman kung ano ang ginawa nung iba. Ang mga pagkakamali ay di madaling maibabalik sa huling ayos. Ang isa pang maayos sa mga sistema ng source control ay yung mga source code mismo ay naichecheck-out sa hard drive ng bawat programmer -- wala pa akong narinig na proyektong gumagamit ng soure control na nawalan ng maraming code.

2. Makakagawa ka ba ng build sa isang hakbang?

Ang ibig kong sabihin dito ay: ilang hakbang ang kakailanganin para makagawa ng shipping build mula sa pinakahuling source snapshot? Para sa mga magagaling na grupo, may isang script kang mapapatakbo na gumagawa na ng full checkout mula sa simula, muling bumubuo ng bawat linya ng code, gumagawa ng mga EXEs, sa lahat ng kanyang sari-saring bersyon, wika, at kombinasyon ng #ifdef , lumilikha ng installation package, at gumagawa ng huling media -- CDROM layout, download website, at kung anu-ano pa.

Kung ang proseso ay humihigit pa sa isang hakbang, ito'y nagiging takaw-mali. At kapag papalapit na ang shipping, siyempre gusto mong mayroong mabilis na cycle sa pagaayos ng huling bug, pagbubuo ng panghuling EXE, at iba pa. Kung umaabot ng 20 hakbang ang pag-compile ng code, pagpapatakbo ng installation builder, at iba pa, ikaw ay masisirain lang ng bait at makakagawa ng mga katangahan.

Dahil sa mga ganitong pangyayari, yung kumpanyang huli kong pinagtrabahuan ay lumipat mula sa WISE papunta sa InstallShield: ginawa naming rikisito na ang proseso ng instalasyon ay automatik na tumatakbo mula sa script tuwing magdamag sa pamamagitan ng paggamit ng NT Scheduler. Hindi nagawang tumakbo ng WISE sa pamamagitan ng scheduler ng magdamag kaya ito'y binasura. (Ang mga mababait na tauhan naman ng WISE ay sinigurado sa akin na ang kanilang pinakabagong bersyon ay nakakasuporta ng magdamagang builds.)

3. Gumagawa ka ba ng mga builds araw-araw?
Kapag gumagamit ka ng source control, minsan mayroong isang programmer na nagchecheck-in ng gawa niya na nakakasira ng kabuuang build. Halimbawa, mayroong naidagdag na bagong file ang isang programmer at nai-co-compile niya ito ng maayos sa kanyang lokal na makina, pero nakalimutan niyang idagdag ito sa code repository. Pagkatapos nito ay isasarado ang kanyang makina at uuwi na walang kamalay-malay at masaya. Dahil sa pagkakalimot niya, di makagawa ang iba, kaya't mapipilitan na rin silang umuwi, pero malungkot.

Ang ganitong eksena ay napakasama (at madalas mangyari) kaya't malaking tulong ang gumawa ng pangaraw-araw na build para walang pagkasirang di napapansin. Sa malalaking grupo, isang mabuting paraan para maiwasan ang ganitong eksena ay gumawa ng build araw araw tuwing tanghali para lahat ay mag-che-check-in ng kani-kanilang source codes bago mananghalian. Pagbalik nila galing ng pananghalian, tapos na ang build. Kung ito ay gumana, eh di masaya! Ngayon, lahat ay puwedeng mag-checkout ulit ng mga source codes para tuloy ang trabaho. Kung ito ay pumalya, kinakailangang ayusin ang problema pero ang lahat ay puwedeng magpatuloy ng trabaho na ang gamit ay yung maayos na codes bago mag-build nung tanghali.

Sa grupo namin sa Excel, mayroon kaming patakaran na kung sino ang sumira ng build, siya ang mag-aayos at magbabantay ng lahat ng mga builds, bilang parusa, hanggang mayroon ibang sumira ulit. Naging maganda itong kasunduan para maiwasan ang pagkakasira ng build at isang magandang paraan para lahat ay makaranas at matuto kung ano ang proseso ng pagbi-build.

Kung may gusto kayong malaman ukol sa pangaraw-araw na build, basahin lang ang aking artikulong Daily Builds are Your Friend.

4. Mayroon ka bang bug database?

Wala akong pakialam sa sasabihin niyo. Kung gumagawa kayo ng code, kahit nag-iisa lang kayo, mababang kalidad ng code ang inyong maisi-ship kung wala kayong organisadong database na naglilista ng lahat ng bugs ng code niyo. Maraming programmers ang nag-iisip na kaya nilang tandaan ang lahat ng bugs. Iyan ay walang katuturan. Ako man ay nakakatanda lamang ng dalawa o tatlong bugs. Pagdating kinabukasan o sa pagmamadali na ng shipping, nakakalimutan na iyon. Kailangan talagang may pormal na pamamaran para masubaybayan ang mga bugs.

Ang mga bug database ay maaaring maging komplikado o simple. Ang mapapakinabangang bug database ay kinakailangang may ganitong mga detalye sa bawat bug:

  • kumpletong hakbang para magawa ulit ang bug
  • inaasahang resulta
  • naobserbang (mali o buggy) resulta
  • kanino ito nakaatas
  • kung ito ay naayos na o hindi pa

Kung ang kasalimuutan ng bug tracking software lang ang pumipigil sa iyo sa pagbabantay sa mga bugs, gumawa na lamang ng simpleng table na mayroon nung 5 krusyal na columns at iyan na lang ang gamitin.

Para sa karagdagang impormasyon tungkol sa bug tracking, basahin ang Painless Bug Tracking.

5. Nag-aayos ka ba ng bugs bago gumawa ulit ng bagong code?

Yung pinaka-unang bersyon ng Microsoft Word for Windows ay tinuring na "death march" na proyekto. Para itong hindi matapos-tapos at patagal ng patagal. Ang buong pangkat ay nagtatrabaho na nang wala sa tamang oras. Naantala na nang naantala ang proyekto, kaya't ang stress ay napakatindi. Nang matapos ang langyang proyekto, huli na ng mga ilang taon, pinadala ng Microsoft and buong grupo sa Cancun para magbakasyon at para na rin makapagmuni-muni at alamin ang mga sanhi ng pagkakamali.

Na-realize nila na ang pagpipilit ng mga project managers na sundin ang skedyul ang naging sanhi kung kaya basta na lang nagsulat ng code ang mga programmers, at naging sobrang sama ng pagka-code dahil yung parte ng pag-aayos ng bugs ay hindi isinama sa pormal na iskedyul ng proyekto. Hindi nagkaroon ng inisyatibo na pababain ang bilang ng bugs. Mayroong isang istorya na ang isang programmer, na kinakailangang magsulat ng code para kalkulahin ang taas ng isang linya ng text, ay basta na lang nagsulat ng "return 12;" at naghintay na lang na lumabas ang isang bug report tungkol sa kung bakit parating mali ang kanyang function. Ang iskedyul ay isa lamang listahan ng mga features na naka-abang maging bugs. Pagkatapos maimbistigahang lahat, tinawag itong "infinite defects methodology".

Para maayos ang problema, kinakailangang sumunod ang Microsoft sa bagay na tinawag nilang "zero defects methodology". Marami sa mga programmers ang natawa dahil akala ng management pwedeng maibaba ang bilang ng bugs sa pamamagitan ng isang ehekutibong direktiba. Sa katunayan, ang ibig sabihin ng "zero defects" ay ang pagbibigay ng importansya na alisin ang mga bugs bago pa man ulit gumawa ng bagong code.

Sa kabuuan, habang humahaba ang hintayan bago ayusin ang mga bugs, mas nagiging magastos (sa pera at sa oras).

Halimbawa, pag nagkamali ka o may syntax error na mahuhuli ang compiler, hindi ito napakahirap ayusin.

Pag nagkaroon ka ng bug at nakita mo ito sa umpisa pa lang, madali mo itong maayos dahil sariwa pa ang lahat sa iyong isipan.

Kung madiskubre mong mayroon kang pagkakamali sa code na nagawa mo nung ilang araw na ang nakalipas, kinakailangan mo pa siguro ng kaunting panahon para maayos mo ito. Pero kung babasahin mo ulit yung code na ginawa mo, maalala mo nang lahat at madali mo na rin itong maayos.

Pero kung makakadiskubre ka ng bug sa code na nagawa mo ilang buwan na ang nakalipas, malamang na nakalimutan mo na kung paano mo ito ginawa at mas magiging mahirap ang pagsasaayos nito. Baka sa mga ganyang oras ay code naman na gawa ng iba ang iyong inaayos. At yung may gawa ng problema ay hindi mo mahagilap dahil nakabakasyon sa Aruba. Sa ganitong kaso, ang pagsasaayos ng bug ay parang isang siyensiya na kinakailangan mong maging mabagal, metodikal, at metikuloso, at hindi ka makakasiguro kung gaano katagal kang makakahanap ng lunas.

At pag nakahanap ka ng bug sa code na naiship na, siguradong mapapagastos ka ng husto para ito maisaayos.

Isa ito sa mga dahilan kaya kinakailangan maisaayos agad ang mga bugs, dahil madali lang ito maisaayos. Pero mayroon pang ibang dahilan, na may kinalaman sa katotohanang mas madali mong mahuhulaan kung gaano katagal gumawa ng bagong code kaysa mag-ayos ng isang bug. Halimbawa, kung tatanungin kita kung gaano katagal i-code ang pag-sort ng isang listahan, masasagot mo agad at mabibigyan mo ako ng estimate. Pero kung tatanungin kita kung gaano katagal ayusin ang nakita mong bug sa iyong code kapag nakainstall ang Internet Explorer 5.5, di mo siguro mahuhulaan man lang, sapagkat talagang hindi mo alam ang dahilan ng bug. Pwedeng abutin ka ng 3 araw para makita ang dahilan ng problema, o puede ring 2 minuto lamang.

Ang ibig sabihin nito ay kung may iskedyul ka at marami pang natitirang mga bugs na kailangang ayusin, ang skedyul ay hindi mo maasahan. Pero kung naayos mo na ang mga kilalang bugs na lumabas, at ang natitira na lang ay ang paggawa ng mga bagong code, saka mo lang masasabing halos eksakto ang iyong iskedyul.

Ang isang magandang resulta kapag nananatili ang bug count sa zero ay mas mabilis kang makakasagot sa mga kakompetensya. Sa ibang programmers, isinasaisip nila ito para manatiling palaging handa para i-ship ang produkto sa kahit ano mang panahon. At kapag ang iyong kakompetensya ay nakagawa ng isang pamatay na bagong feature na nakakanakaw ng iyong kustomer, makakayanan mo ring gumawa ng ganoong feature at magship kaagad ng hindi mo inaalalang magayos pa ng maraming bugs na naipon na.

6. Mayroon ka bang iskedyul na up-to-date?

At ngayo'y tutungo tayo sa mga iskedyul. Kung ang code mo ay importante sa negosyo, maraming dahilan kung bakit importante sa mga business people na malaman kung kailan matatapos ang code. Ang mga programmer ay kilala sa pagiging aburido pag tungkol sa pagset ng iskedyul. "Matatapos siya pag tapos na siya!" ang madalas na sigaw nila sa mga business people.

Kaso, hindi naman uubra ang ganito. Masyadong maraming desisyon sa paghahanda ang kailangang gawin ng mga business people bago pa ilabas ang code: mga demo, mga trade show, advertising, at iba pa. At ang nag-iisang paraan para magawa ito ay sa pamamagitan ng skedyul na tama sa panahon.

Ang isa pang krusyal na bagay ukol sa pagkakaroon ng skedyul ay yung napipilitan kang magdesisyon sa kung anong mga features ang gagawin mo. Pagkatapos ay napipilitan ka ring pumili kung alin sa mga di gaanong importanteng features ang tatanggalin mo kaysa magkaroon ka ng featuritis (o scope creep).

Ang paggawa ng skedyul ay di naman dapat mahirap. Basahin ang artikulo kong Painless Software Schedules, na naglalarawan ng isang simpleng pamamaraan sa paggawa ng maaayos na skedyul.

7. Mayroon ka bang spec?
Ang pagsusulat ng spec ay parang pagfofloss: lahat ay naniniwalang ito ay nakabubuti pero walang namang may gumagawa.

Ewan ko ba kung bakit ganito, pero dahil siguro sa ang nakararaming programmers ay kinasusuklaman ang pagsusulat ng dokumento. Kapag ang isang grupo na puro programmers ay mayroong isinasaayos na problema, mas gugustuhin nilang ipahayag ang pagsasaayos sa pamamagitan ng code kaysa sa pamamagitan ng mga dokumento. Mas gugustuhin nilang mag-code agad kaysa gumawa ng isang spec muna.

Habang nasa pagdidisenyo pa lamang at nakadiskubre ng mga problema, maaayos mo agad ito sa pamamagitan ng pagpalit ng ilang linya ng text. Pero kapag naisulat na ang code, medyo magastos na ang pagsasaayos nito, hindi lang dahil sa panahong nasayang kundi pati na rin sa panghihinayang sa natapos nang code (walang may gustong magtapon na lang basta-basta ng code), kung kaya nagkakaroon ng pagsasalungat sa pagsasaayos ng mga problema. Ang software na hindi ginawa base sa isang spec ay nauuwing hindi maganda ang pagkadisenyo at nagiging mahirap kontrolin ang iskedyul. Mukhang ito ang naging problema sa Netscape, na ang unang apat na bersyon ay lumaki ang naging gulo na naging sanhi ito para ang management ay tangang nagdesisyon na ibasura ang kabuuang code at magumpisa ulit ng panibago. At naulit ang pagkakamaling ito sa Mozilla, na parang nakagawa ng isang dambuhala na hindi makontrol at ilang taon pa ang kinailangan para maabot ang alpha stage.

Ang aking teoriya rito ay maaayos ang ganitong mga problema sa pamamagitan ng pagtuturo na maging katanggap-tanggap sa mga programmers ang pagsusulat sa pamamagitan ng pagpapadala sa kanila sa isang intensibong kurso sa pagsusulat. Isang solusyon din ang pagkakaroon ng magagaling na program managers para magsulat ng mga spec. Sa alin mang paraan, ipagpilitan mo ang simpleng patakarang "walang spec, walang code."

Basahin ang aking sinulat na 4-part series tungkol sa pagsusulat ng specs.

8. Tahimik ba ang lugar na pinagtatrabahuan ng mga programmers?

Maraming nang naisulat tungkol sa pagtaas ng productivity sa pamamagitan ng pagbibigay ng espasyo, katahimikan, at kalihiman sa mga manggagawa. Mababasa mo ang mga benepisyo nito sa Peopleware , isang aklat tungkol sa software management.

Heto ang nakakabahala. Alam nating lahat na ang mga manggagawa ay nakakapagtrabaho nang mahusay kapag sila ay nasa kanilang "flow", o kapag sila ay "in the zone", kung saan ang buong konsentrasyon nila ay nasa trabaho at hindi na nila napapansin ang kanilang kapaligiran. Hindi na nila napapansin ang oras at nakakapagpakita ng pinakamahusay nilang gawa sa pamamagitan ng ganap na konsentrasyon. Ito ay tuwing nagagawa nila ang lahat nilang trabaho. Ang mga manunulat, programmers, siyentipiko, at pati na rin mga basketbolista ay makakapagsabi sa inyo tungkol sa pagiging in the zone.

Ang problema nga lang ay di madaling mapalagay sa "zone". Kapag sinubukan mong sukatin, mukhang karaniwang inaabot lamang ng 15 minuto upang makapagsimulang magtrabaho ng maksimong produktibidad. Minsan, kung ikaw ay pagod o kapag maraming malikhaing gawain na ang iyong nagawa sa araw na iyon, tila hindi ka na mapapa "in the zone" at nasasayang lang ang natitirang oras ng pagtatrabaho sa pamamagitan ng panggugulo, pag-surf sa web, at paglalaro ng Tetris.

Ang isa pang nakakabahala ay yung napakadaling mawala sa zone. Ingay, tawag sa telepono, paglabas para mananghalian, 5 minutong pagmamaneho patungo sa Starbucks para mag-kape, at pagaabala ng mga kasamahan sa trabaho -- lalong-lalo na ito --- lahat ay nakapagpapaalis sa iyo sa zone. Kung ang kasamahan mo ay magtanong sa iyo, ito ay nagiging sanhi ng 1 minutong abala, ngunit napakatindi ng pagpapaalis nito sa iyo mula sa zone, aabutin ka na ng kalahating-oras upang makabalik sa pagiging produktib, kaya't matindi ang pagkabahala sa pangkalahatang produktibidad mo. Kung ikaw ay nasa maingay na kapaligiran tulad ng mga nililikha ng mga dotcoms, kung saan maraming mga taga-marketing ang nagsisigawan sa telepono sa tabi ng mga programmers, ang iyong produktibidad ay babagsak dahil sa maya't-mayang pagaabala kaya't di ka na makapasok sa zone.

Sa mga programmers, ito ay talagang mahirap. Ang produktibidad ay depende sa abilidad na makatanda sa maraming maliliit na detalye sa short term memory nang sabay-sabay. Kahit anong pagaabala ay makakagulo sa pagtanda mo sa mga detalyeng iyon. Kapag nagpatuloy ka na sa iyong trabaho, wala ka nang matandaang detalye (kagaya ng local variable names na ginagamit mo, o kung nasaan ka na sa isinasagawa mong search algorithm) at kakailanganin mong parating hanapin ang mga bagay na ito, na nakakapagpabagal lamang sa iyo.

Heto ang simpleng algebra. Sabihin nating (ayon sa pinararating ng mga ebidensiya) abalahin natin ang isang programmer, kahit 1 minuto lang, ang talagang nangyayari ay nasasayang natin ang 15 minutong produktibidad. Sa halimbawang ito, gamitin natin ang dalawang programmer na sina Jeff at Mutt, na nasa magkatabing bukas na cubicles na kagaya ng standard na Dilbert veal-fattening farm. Hindi maalala ni Mutt ang pangalan ng bersyon ng strcpy function sa Unicode. Maari niyang hanapin iyon, na aabutin ng 30 segundo, o puwede niyang tanungin si Jeff, na aabutin ng 15 segundo. Dahil sa katabi lamang niya si Jeff, tinanong na lamang niya ito. Nagulo na tuloy si Jeff at 15 minutong produktibidad na ang nawala (para lang makatipid si Mutt ng 15 segundo).

Ngayon ilipat naman natin sila sa magkahiwalay na opisina na may mga pader at pinto. Ngayon, kapag di maalala ni Mutt ang pangalan ng function na iyon, puwede niyang hanapin, na aabutin pa rin ng 30 segundo, o puwede niyang tanungin si Jeff, na ngayo'y aabutin na ng 45 segundo at kakailanganin pa niyang tumayo (di madaling gawain dahil sa karaniwang estado ng physical fitness ng mga programmers!). Hinanap na lang niya. Nawalan si Mutt ng 30 segundong produktibidad, pero nakatipid naman tayo ng 15 minuto para kay Jeff. Ahhhyos!

9. Gumagamit ka ba ng mga pinakamagandang kagamitan na mabibili ng pera?
Ang pag-co-code sa isang compiled lanaguage ay isa sa mga bagay na hindi mo puwedeng magawa kaagad sa computer na pambahay. Kung ang paraan mo sa pag compile ay tumatagal ng mahigit sa iilang segundo, makakatipid ka sa oras kung makakakuha ka ng pinakabago at pinakamabilis na modelo ng computer. Kung ang pagko-compile ay humihigit ng 15 segundo, maiinip lang ang mga programmers sa paghihintay sa tumatakbong compiler at ililipat na lang ang kanilang atensyon sa pagbabasa ng The Onion, na tiyak ay nakakawili at maaaring kumain ng kanilang mahahalagang oras ng produktibidad.

Ang pagdedebug ng GUI code na gamit ang isang monitor lamang ay napakasakit, kundi man napakaimposible. Kung gumagawa ka ng GUI code, makakadali nang trabaho ang magkaroon ng dalawang monitors.

Karamihan sa mga programmers ay kalaunang magmamanipula ng bitmaps para sa paggawa ng icons at saka toolbars, at karamihan sa kanila ay walang maayos na bitmap editor. Ang paggamit ng Microsoft Paint para sa pagmamanipula ng bitmap ay katawa-tawa pero sa katotohanan ay yun nga ang kinakailangang gawin ng mga programmers.

Sa huli kong pinagtrabahuan, parati na lang akong pinapadalhan ng system administrator ng automated na spam sabay reklamo na ako'y gumagamit na ng mahigit sa 220 megabytes na espasyo sa hard drive ng server. Ang punto ko naman ay sa presyo ng hard drives sa panahon ngayon, ang nagamit kong espasyo ay di hamak na mas mura pa sa presyo ng toilet paper. Ang maglaan ng kahit 10 minuto para linisin ang directory ko ay isang napakalaking pagsasayang lang ng produktibidad.

Ang mga pinakamagagaling na development teams ay hindi pinahihirapan ang kanilang mga programmers. Kahit ang mga kaunting bagay na nakakadismaya dahil sa hindi maganda ang mga gamit-paggawa ay nakakadagdag, kung kaya nagiging aburido at hindi masaya ang mga programmers. Dapat nating isaisip na ang isang aburidong programmer ay isang hindi produktibong programmer.

Dagdag pa rito, madaling suhulan ang mga programmers sa pamamagitan ng pagbigay sa kanila ng pinakamagara at pinakabagong mga gamit. Isa ito sa pinakamurang paraan para mahikayat mo silang magtrabaho nang maayos kaysa magpasuweldo ng may kataasan!

10. Mayroon ka bang mga taga-test?

Kung ang inyong pangkat ay walang nakalaang mga taga-test, kahit man lang isa para sa bawat dalawa o tatlong programmers, ikaw ay nagpapadala ng mga produktong buggy o ikaw ay nagsasayang lamang ng pera sa pagkakaroon ng $100/oras na programmers na gumagawa ng trabahong kakayanin ng $30/oras na mga taga-test. Ang pagtitipid sa mga taga-test ay isang napakatinding huwad na ekonomiya na di ko maisip kung bakit di ito makita ng karamihan.

Basahin ang Top Five (Wrong) Reasons You Don't Have Testers, isang artikulong sinulat ko tungkol sa paksang ito.

11. Ang mga bagong kandidato ba ay nagsusulat ng code habang iniinterview?
Magha-hire ka ba ng isang salamangkero na hindi mo pasusubukang gumawa ng mga magic tricks? Syempre hindi.

Magha-hire ka ba ng caterer para sa iyong kasal na hindi mo titikman ang kanilang luto? Tingin ko hindi. (Puwera kung si Aunt Marge, kamumuhian ka nya magpakailanman kung hindi mo sya papayagang magluto ng kanyang pinakatanyag na chopped liver cake).

Pero, araw araw, natatanggap sa trabaho ang mga programmers base lamang sa kanilang nakakaimpress na resumé o dahil sa natuwa ang naginterview sa kakakausap sa mga ito. O kaya tinanong lang sila ng mga pakuwelang mga tanong ("ano ang pagkakaiba ng CreateDialog() sa DialogBox()?") na masasagot pag tumingin lang sa dokumentasyon. Bale wala dapat sa iyo ang nakakabisado nila na higit sa ilan-libong pakuwelang mga tanong. Ang dapat mong tingnan ay kung makakagawa ba sila ng code. Ang malala pa rito ay kung tatanungin sila ng mga katanungang tipong "AHA!". Ito ay mga tanong na parang madaling sagutan kapag alam mo ang isasagot pero parang imposible kapag di mo alam.

Pakiusap lang po, itigil na natin ang paggawa nito. Gawin mo na ang gusto mong gawin kapag nagi-interview, pero pagsulatin mo naman ang kandidato ng code. (Kung gusto mo pa ng iba pang abiso, basahin lamang ang aking Guerrilla Guide to Interviewing.)

12. Do you do hallway usability testing?
Ang hallway usability test ay kung saan hinihila mo lang ang kung sinong sumunod na dumaan sa hallway at puwersahin siyang gamitin ang code na iyong isinulat. Kapag ginawa mo ito sa 5 tao, matututunan mo ang 95% ng kung ano mang kailangang matutunan sa usability problems sa iyong code.

Ang magandang user interface ay hindi mahirap gawin tulad ng inyong pagaakala, at napakaimportante nito kung gusto niyong magustuhan at bilhin ng mga customer ang produkto. Puwedeng basahin ang aking free online book on UI design, isang maikling primer para sa mga programmers.

Pero ang pinakaimportanteng bagay tungkol sa mga user interfaces ay kapag ipinakita mo ang iyong program sa iilang mga tao (lima o anim ay sapat na), madali mong madidiskubre ang mga pinakamalaking problemang mayroon ang mga tao. Basahin ang artikulo ni Jakob Nielsen na nagpapaliwanag kung bakit. Kahit ang karunungan niyo sa UI design ay limitado lamang, basta pinupuwersa niyo ang inyong sariling gumawa ng mga hallway usability tests, na wala naman kayong gagastusin, ang inyong UI ay magiging mas mainam.

4 Na Paraan sa Paggamit ng Joel Test

  1. Irate niyo ang inyong sariling software organization, at sabihin niyo sa akin para maipagkakalat ko ito.
  2. Kung ikaw ang manager ng programming team, gamitin mo ito bilang listahan para masigurado ang inyong pangkat ay sama-samang nagtatrabahong maayos. Pag nagsimula na kayong mag-rate ng 12, puwede mo nang pabayaang mag-isa ang iyong mga programmers at ituon ang inyong buong pansin sa paglalayo sa mga negosyante sa kanila para hindi sila maistorbo.
  3. Kung ikaw ay nagdadalawang-isip kung kukuha ng trabahong programming, tanungin ang inyong prospective na employer kung ano ang rating nila sa test na ito. Kung masyadong mababa, siguraduhing ikaw ay mayroong awtoridad na maisaayos ang mga bagay na ito. Kung hindi, ikaw lang ay madidismaya at magiging hindi produktibo.
  4. Kung ikaw ay investor na gumagawa ng karampatang kasipagan upang mahusgahan ang halaga ng programming team, o kung ikaw ay kumpanya ng software na kinokonsider na makipagsanib sa isa pa, makakapagbigay ang test na ito ng madaling rule of thumb.


Ang artikulong ito ay orihinal na lumalabas sa Ingles sa ngalang The Joel Test: 12 Steps to Better Code  

Si Joel Spolsky ang nagtatag ng Fog Creek Software, isang maliit na kumpanya ng sofware sa New York City. Siya ay nagtapos sa Yale University at nagtrabaho bilang programmer at manager sa Microsoft, Viacom, at Juno.


Ang mga nilalaman ng mga pahinang ito ay kumakatawan sa opinyon ng isang tao.
Ang lahat ng nilalaman ay Copyright ©1999-2005 ni Joel Spolsky. Taglay ang lahat ng karapatan sa pagmamay-ari.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky