மென்பொருள் உருவாக்கும் விந்தையுலகம் 8: உற்பத்தித் திறனை மேம்படுத்த குமிழிகள் அனைத்தையும் 10-க்குத் திருப்புங்கள்!

Agile/Scrum பற்றி தொடர் கட்டுரை – 8

 

கென்ட் பெக் (Kent Beck) 1996-ல் க்ரைஸ்லர் நிறுவனத்தின் சம்பள செயலியை மாற்றி எழுதும் மென்பொருள் திட்டத்தின் தலைவராக ஆனார். அந்தத் திட்டத்தில் அதீத நிரலாக்கத்தை (Extreme Programming or XP) ஆரம்பித்து செயற்படுத்தினார். 1999-ல் அவர் Extreme Programming Explained புத்தகத்தை வெளியிட்ட போது அதில் அவர் விவரித்த சில நடைமுறைகள் மென்பொருள் உலகை அதிர வைத்தன.

 

அனைத்து மென்பொருளையும் இரண்டு நிரலாளர்கள் இணைந்து உருவாக்குதல் – அதாவது ஒரு திரை இரண்டு நிரலாளர்கள் (pair programming). ஒருவர் எழுதிய நிரலை குழுவில் மற்றொரு சக நிரலாளர் மறுஆய்வு செய்வது வழுக்களைக் குறைத்து நிரலின் தரத்தை மேம்படுத்தும் என்பதற்கு நிறைய ஆதாரங்கள் உள்ளன. ஆனால் இரண்டு நிரலாளர்கள் இணைந்து உருவாக்குதல் மிகவும் புரட்சிகரமான நடவடிக்கை.

 

முதலில் ஓரலகு சோதிப்புகள் (unit tests) எழுதிவிட்டு பின்னர்தான் நிரல் எழுதவே ஆரம்பித்தல். நிரலாளர்கள் நிரல் எழுதியவுடன் கைமுறையில் சோதனை செய்வதே வழக்கமாக இருந்தது. இந்த சோதனையை தானியங்கியாக செய்தல் நல்ல மேம்பாடுதான். ஆனால் முதலில் சோதனை செய்துவிட்டு பின்னர்தான் நிரல் எழுதவே ஆரம்பித்தல் என்பது நூதனமானது.

 

மறுசீரமைப்பு (refactoring) செய்து நிரலை தொடர்ந்து மேம்படுத்தல். உற்பத்தி மற்றும் கட்டுமான தொழில்துறைகளில் “முதல் முறையே சரியாகச் செய்வோம்” என்ற முழக்கம் நன்கு நிலைபெற்றது. நாம் முன்னால் பார்த்தபடி இத் தொழில்துறைகளில் வேலையை ஒரு முறை செய்த பிறகு அதை மாற்றியமைப்பது மிகக் கடினம். ஆனால் மென்பொருளில் நிரலை மாற்றி அமைப்பது அவ்வளவு கடினம் அல்ல. ஆனால் மாற்றி அமைத்த பின் சோதனை செய்வதுதான் வேலை கொள்ளும், மேலும் இடர்பாடானது. நிரலாளர்களைக் கேட்டுப் பாருங்கள். ஐந்தே நிமிடத்தில் மாற்றித் தருகிறேன் என்றுதான் சொல்வார்கள். ஆனால் சோதனையாளர்களோ வேறு எங்கு ஒழுங்காய் வேலை செய்து கொண்டிருக்கும் நிரல்கூறு உடையுமோ என்று கவலை கொள்வார்கள்.

 

சில சமயங்களில் ஒரு சிறிய வழுவை நீக்கப் போய் அது பெரிய பிரச்சினைகளில் கொண்டு விடுவதை நாம் பார்த்திருக்கிறோம், நாம் அன்றாடம் பயன்படுத்தும் செயலிகளில் நடைமுறையிலும் அனுபவித்திருக்கிறோம். எடுத்துக்காட்டாக 2005 ஆம் ஆண்டில், டிரெண்ட் மைக்ரோ (Trend Micro) தரமற்ற பேட்ச் (patch) ஒன்றை வெளியிட்டது. இதனால் செயல்திறன் கடுமையாகக் குறைந்தது. இந்தப் பிரச்சினையால் அவதிப்பட்ட வாடிக்கையாளர்களிடம் இருந்து சுமார் 4 லட்சம் புகார்கள் வந்து குவிந்தன. இறுதியில் வாடிக்கையாளர்களுக்கு இழப்பீடு மட்டும் $ 8 மில்லியனுக்கு மேல் செலவிட நேர்ந்தது.

 

XP மாற்றி அமைப்பதை ஊக்குவித்தது மட்டும் அல்ல, அதை அவசியமாக்கியது. ஏனென்றால் ஒரு குறிப்பிட்ட தேவைக்கு நீங்கள் குறைந்தபட்ச நிரல் எழுதி ஓரலகு சோதிப்பில் சரியானால் போதும். அடுத்து நிரலை மறுசீரமைப்பு செய்யும்போது அதை மேம்படுத்தலாம். XP-ல் சோதனை செய்வது கடினம் அல்ல. ஏனென்றால் இப்போது உங்களிடம் ஓரலகு சோதிப்பின் முழுத் தொகுப்பும் உள்ளது. அதுவும் நீங்கள் பொத்தானைத் தட்டி விட்டால் தானாகவே ஓடும் வகையில் நிறுவி வைத்திருப்பீர்கள். ஆக, நிரல் மறுசீரமைப்பு மென்பொருளில் தொடர்ந்து முன்னேற்றம் செய்ய வழி செய்தது. ஓரலகு சோதிப்பு மறுசீரமைப்பினால் புதிய பிரச்சினைகள் வராது என்ற நம்பிக்கையைக் கொடுத்தது.

 

ஒவ்வொரு நாளும் பல முறை தொடர் ஒருங்கிணைப்பு செய்தல் (continuous integration). சில அருவி செயல்முறை திட்டங்களில் ஒருங்கிணைத்தல் செய்ய கடைசி கட்டங்களில்தான் நேரம் ஒதுக்கப்பட்டிருக்கும். அப்படி செய்யும்போது ஒருங்கிணைத்தலிலும் அதன்பின் சோதனையிலும், முக்கியமாக செயல்திறன் சோதனையிலும், பல பிரச்சினைகள் வெளிப்படலாம். முன்னெச்சறிக்கையான சிலர் இடையிடையே ஒருங்கிணைத்தல் செய்வது உண்டு. விடாமுயற்சி உள்ள சிலர் ஒவ்வொரு வாரமும் வாரக்கடைசியில் ஒருங்கிணைத்தல் செய்வர். ஆனால் ஒவ்வொரு முறையும் நிரலாளர் தொகுபதிவகத்தில் நிரல் சேர்க்கும்போது தானியங்கியாக ஒருங்கிணைத்தலும், சோதனை செய்தலும் அதுவரை கேட்டறியாத விஷயம்.

 

அவர் அதீத நிரலாக்கத்தை இப்படித்தான் விளக்கினார். மென்பொருள் உருவாக்கத் தேவையான ஒவ்வொரு செயல்முறையையும் கட்டுப்பாட்டகத்தில் ஒரு குமிழி என்று உருவகப்படுத்திக் கொண்டார். தான் எந்த செயல்முறைகள் இன்றியமையாதவை என்று நினைத்தாரோ அவற்றை 1 முதல் 10 வரை உள்ள டயல்களில் அனைத்துக் குமிழிகளையும் 10-ல் திருப்பி வைத்தால் என்ன ஆகிறதென்று பார்க்கலாம் என்றார்.

360px-TASCAM_M-520_knobs.jpg

 

இவை எல்லாவற்றையும் செயல்படுத்திய பின் இந்த செயல்முறைகளின் முழுத் தொகுப்பு நிலையானதாக, கணிக்கக் கூடியதாக, மற்றும் இணங்கு தன்மையுடன் இருந்ததைப் பார்த்து அவருக்கே கொஞ்சம் ஆச்சரியமாக இருந்தது என்றார்.

 

ஆக XP பொது அறிவுக் கொள்கைகளை அதீத மட்டங்களுக்கு எடுத்துச் செல்கிறது. மேலும் எடுத்துக்காட்டாக குறுகிய மறுசெய்கை (iteration)* நல்லது என்றால் அதைக் கூடியவரை XP குறுக்குகிறது. இதற்காக குறைந்தபட்ச ஆனால் மிகவும் வணிக அர்த்தமுள்ள, சாத்தியமான வெளியீட்டை தேர்வு செய்ய வாடிக்கையாளரைக் கேட்டுக்கொள்கிறது. அருவி செயல்முறையில் பெரும்பாலும் திரைப்பட வெளியீடு போல தடல்புடலாக முழு மென்பொருளையும் ஒரே நேரத்தில் வெளியீடு செய்வதுடன் ஒப்பிட்டுப் பாருங்கள்.

 

XP இரண்டு விதமான வாக்குறுதிகளை அளிக்கிறது என்று சொல்கிறார் கென்ட் பெக், “நிரலாளர்களுக்கு ஒவ்வொரு நாளும் முக்கியமான விஷயங்களில் வேலை செய்ய முடியும் என்று XP வாக்களிக்கிறது. வாடிக்கையாளர்கள் மற்றும் மேலாளர்களுக்கு XP ஒவ்வொரு வாரமும் அதிகபட்ச மதிப்புடைய மென்பொருள் பெற முடியும் என்று வாக்களிக்கிறது. மேலும் அவர்கள் அநியாய செலவுகள் செய்யாமல் திட்டத்தின் மத்தியில் திசையை மாற்ற முடியும். சுருக்கமாகச் சொல்லப்போனால் பணித்திட்டத்தின் இடரைக் குறைக்கவும், வணிக மாற்றங்களுக்குத் தக மாற்றவும், உற்பத்தித் திறனை மேம்படுத்தவும், நிரலாக்க அணி ஆர்வத்துடன் ரசித்து வேலை செய்யவும், இவை யாவையும் ஒரே நேரத்தில் முடியும் என்று XP வாக்களிக்கிறது”.

*Scrum-ல் ‘sprint’ என்று சொல்வதை XP-ல் ‘iteration’ என்று சொல்கிறோம். இதுவும் அதே குறுவோட்டம்தான்.

 

நன்றி,
இரா. அசோகன்
%d bloggers like this: