மென்பொருள் உருவாக்குவது ஒரு பொதுவெளியில் நிகழும் நிகழ்ச்சி போலத் தோன்றலாம். இணையம் புதிய வெளியீடுகள் (launches), ஸ்கிரீன்ஷாட்டுகள் மற்றும் மாற்றங்களின் பட்டியல்களை (changelog) மட்டுமே போற்றுகிறது. எனவே, ஒரு டெவலப்பர் ஒரு முழு நேரத்தையும் ஒரு திட்டத்திற்காகச் செலவிட்டு, இறுதியில் காட்டிக்கொள்ள எதுவுமே இல்லை என்றால், அந்த நாள் வீணாகிவிட்டது என்று நினைப்பது இயல்பு. Food Blog Platform-ன் சமீபத்திய டெவ் லாக் (dev log) இதற்கு நேர்மாறான உண்மையைக் காட்டுகிறது. அங்கு காண்பிக்கப் புதிய ரெசிபிகள் (recipes) இல்லை, மாற்றியமைக்கப்பட்ட கார்டுகள் (cards) இல்லை, அல்லது பயனர்கள் கிளிக் செய்ய கூடுதல் பட்டன்கள் இல்லை. வெறும் குறியீடு (code) மட்டுமே பிரிக்கப்பட்டு, ஆராயப்பட்டு, முன்பை விடச் சிறப்பாக மீண்டும் இணைக்கப்பட்டது.
நீண்டகாலத் திட்டங்களை உயிர்ப்புடன் வைத்திருப்பது இந்தத் தெரியாத உழைப்புதான்.
அம்சங்கள் புகழைப் பெறுகின்றன; Refactoring திட்டத்தைத் தொடர்ந்து இயங்க வைக்கிறது
நீங்கள் ஒரு உணவு வலைதளத்தைப் (food blog platform) பராமரிக்கும்போது, அதன் வெளிப்பகுதி எளிமையாகத் தெரியும். பயனர்கள் ரெசிபிகளைப் பதிவேற்றுவார்கள், புகைப்படங்களைப் பதிவேற்றுவார்கள் மற்றும் வகைகளின் அடிப்படையில் தேடுவார்கள். ஆனால் அதன் அடியில், நீங்கள் இமேஜ் பைப்லைன்கள் (image pipelines), பொருட்கள் மற்றும் வழிமுறைகளுக்கு இடையிலான தரவுத்தள உறவுகள் (database relationships), தேடல் குறியீடுகள் (search indexes) மற்றும் கேச்சிங் லேயர்கள் (caching layers) எனப் பலவற்றைச் சமாளித்துக் கொண்டிருப்பீர்கள். காலப்போக்கில், விரைவான தீர்வுகளுக்காகச் செய்யப்பட்ட மாற்றங்கள் (quick fixes) குவியத் தொடங்கும். மூன்று வெவ்வேறு கோப்புகளில் நகலெடுக்கப்பட்ட ஒரு ஹெல்ப்பர் ஃபங்ஷன் (helper function). பத்து பதிவுகளுக்குச் சரியாக இருந்த ஒரு தரவுத்தள வினவல் (database query), ஆயிரம் பதிவுகள் வரும்போது மெதுவாகச் செயல்படும். ஐந்து அவசரத் திருத்தங்களால் ஒரு சிக்கலான பாதையாக மாறிய CSS.
Refactoring என்பது அந்தச் சிக்கல்களை நேரடியாக எதிர்கொள்வதாகும். ஒரு ரெசிபி எடிட்டிங் ஃபார்ம் மற்றும் ஒரு அட்மின் டேஷ்போர்டு ஆகியவை தனித்தனி பதிப்புகளைப் பராமரிப்பதற்குப் பதிலாக, ஒரே சரிபார்ப்பு லேயரிலிருந்து (validation layer) தரவுகளைப் பெறும் வகையில் நகல் தர்க்கங்களை (duplicate logic) ஒருங்கிணைப்பதாக இருக்கலாம். அல்லது ஒரு பக்கம் ரீலோட் ஆகும்போதெல்லாம் ஒவ்வொரு முறையும் இயங்குவதற்குப் பதிலாக, இமேஜ் கம்ப்ரஷன் (image compression) முறை ஒருமுறை மட்டும் இயங்கும் வகையில் எளிமையாக்குவதாக இருக்கலாம். அல்லது புதிய உள்ளடக்க வகையை (content type) பின்னாளில் சேர்க்கும்போது, ஆறு தொடர்பில்லாத கோப்புறைகளைத் (directories) தேட வேண்டிய அவசியம் இல்லாதவாறு குறியீட்டுத் தொகுப்பை (codebase) மறுசீரமைப்பதாக இருக்கலாம்.
இவை எதுவும் பயனர் இடைமுகத்தில் (user interface) தெரியாது. தளத்திற்கு வரும் ஒரு பார்வையாளர் "வினவல் மேம்படுத்தப்பட்டது" (query optimized) அல்லது "கூறு பிரிக்கப்பட்டது" (component decoupled) என்று கூறும் பேனர்களைப் பார்க்க மாட்டார். ஆனால் தளம் வேகமாக இயங்கும்போது அதை அவர்கள் உணர்வார்கள். ஒரு புதிய அம்சம் கேட்கப்பட்ட மூன்று வாரங்களுக்குப் பதிலாக மூன்று நாட்களில் வரும்போது அதை அவர்கள் கவனிப்பார்கள். டெவலப்பர் இன்று புதிய திறன்களைச் சேர்க்கவில்லை. மாறாக, குறியீட்டுத் தொகுப்போடு போராடாமல் புதிய திறன்களைச் சேர்க்கும் பாதையை அவர் தயார் செய்துள்ளார்.
சுத்தமான குறியீடு (Clean Code) என்பது எதிர்காலத் தோல்விக்கு எதிரான ஒரு முதலீடு
ஒரு மாதத்திற்கு மேலாக நீடிக்கும் ஒவ்வொரு திட்டமும் உராய்வுகளைச் (friction) சந்திக்கிறது. ஒரு யோசனையைச் சோதிக்க நீங்கள் ஒரு விரைவான முன்மாதிரியை (prototype) உருவாக்குகிறீர்கள். பின்னர் பயனர்கள் வருகிறார்கள். பிறகு உங்களுக்கு ஒரு அங்கீகார அடுக்கு (authentication layer), ஒரு மாடரேஷன் வரிசை (moderation queue) மற்றும் ஒரு மொபைல் லேஅவுட் தேவைப்படுகிறது. இவை ஒவ்வொன்றும் ஏற்கனவே இருக்கும் கட்டமைப்பின் மீது கட்டப்படுகின்றன. முறையான பராமரிப்பு இல்லையென்றால், அந்தத் தளம், ஒவ்வொரு புதிய அறையும் தரைத்தள வரைபடத்தைப் பார்க்காத ஒரு வெவ்வேறு நபரால் வடிவமைக்கப்பட்ட ஒரு வீட்டைப் போலத் தோற்றமளிக்கத் தொடங்கும்.
தொழில்நுட்பக் கடன் (Technical debt) என்பது ஒழுக்கமின்மையின் தோல்வி அல்ல. அது ஒரு நிஜமான பொருளை வெளியிடுவதற்காகச் செய்யப்படும் சமரசங்களின் (trade-offs) இயற்கையான விளைவாகும். ஆபத்து என்பது உங்கள் குறியீடு குறையற்றதாக இல்லை என்பதில் இல்லை. மாறாக, ஒரு மாறியை (variable) மாற்றினால் மூன்று தொடர்பில்லாத அம்சங்கள் உடைந்துவிடும் அளவுக்கு அதை நீண்ட காலம் குறையற்றதாகவே விட்டுவிடுவதுதான் ஆபத்து. கடைசியாகத் தேடல் பட்டியில் (search bar) முயன்றபோது டேக் சிஸ்டம் (tag system) உடைந்துவிட்டதால், அதைத் தொடக்கூட நீங்கள் பயப்படுகிறீர்கள். தரவுத்தள அமைப்பு (database schema) ஒரு சிக்கலான முடிச்சாக மாறிவிட்டதால், ஒரு மீல்-பிளானர் விட்ஜெட்டை (meal-planner widget) சேர்ப்பதை நீங்கள் தள்ளிப்போடுகிறீர்கள்.
ஒரு நாளை முழுவதையும் Refactoring-க்காகச் செலவிடுவது என்பது, வட்டி உங்களை ஆட்கொள்வதற்கு முன் அந்தத் Deb-ஐத் திருப்பிச் செலுத்துவது போன்றது. இது சிறிய பிரச்சினைகள் பெரியதாக மாறுவதைத் தடுக்கிறது. Food Blog Platform இறுதியில் தனது அடுத்த முக்கிய அம்சத்தைச் சேர்க்கும்போது, டெவலப்பர் பலவீனமான குறியீட்டைச் சுற்றித் தாண்ட வேண்டியிருக்காது. அவர் புதிய தர்க்கத்தை (logic) எழுதி, அதை ஒரு சுத்தமான இடைமுகத்தில் இணைத்துவிட்டு அடுத்த வேலையைப் பார்ப்பார். இதுதான் முதலீட்டின் மீதான லாபம் (return on investment).
சிறிய படிகள், உண்மையான கற்றல்
மென்பொருள் மேம்பாடு என்பது ஒரே இரவில் அனைத்தையும் மாற்றி எழுதும் மேதமைத் திறன்கள் அல்லது மாரத்தான் கோடிங் அமர்வுகள் போன்றது என்ற ஒரு கட்டுக்கதை உள்ளது. வேலை செய்யும் பெரும்பாலான டெவலப்பர்கள் இது ஒரு கற்பனை என்று சொல்வார்கள். உண்மையான முன்னேற்றம் என்பது ஒரு செவ்வாய்க்கிழமை மதிய வேளையில் ஒரு 'diff' போல இருக்கும்; அங்கு மூன்று ஃபங்ஷன்கள் சுருங்கியிருக்கும், ஒரு தேவையற்ற சார்பு (dependency) நீக்கப்பட்டிருக்கும், மற்றும் அடுத்த வாசகர் எளிதில் புரிந்துகொள்ளும் வகையில் ஒரு குழப்பமான மாறிப் பெயர் (variable name) மாற்றப்பட்டிருக்கும்.
Food Blog Platform-ன் டெவ் லாக் இந்தத் தாளத்தை (rhythm) சரியாகப் படம்பிடிக்கிறது. மென்பொருள் உருவாக்குவது என்பது சிறிய, நிலையான முன்னேற்றங்களைப் பற்றியது. ஒவ்வொரு சவாலிலிருந்தும் நீங்கள் கற்றுக்கொள்கிறீர்கள். ஒருவேளை இன்று சவால் என்பது ஒரு குறிப்பிட்ட மாட்யூல் (module) ஏன் மற்றொன்றைச் சார்ந்து வளர்ந்துள்ளது என்பதைப் புரிந்துகொள்வதாக இருக்கலாம். அல்லது இரண்டு வாரங்களுக்கு முன்பு எடுக்கப்பட்ட ஒரு குறுக்குவழி, அது மிச்சப்படுத்திய நேரத்தை விட அதிக நேரத்தை ஏற்கனவே செலவழிக்கத் தொடங்கியிருப்பதை உணர்வதாக இருக்கலாம். ஒவ்வொரு கமிட்டும் (commit) திட்டத்தை மேம்படுத்துகிறது, அந்த கமிட் உருவாக்குவதை விட அதிகமாக ஒன்றை நீக்கினாலும் கூட.
இந்த அணுகுமுறை உங்கள் ஊக்கத்தையும் பாதுகாக்கிறது. பெரிய அளவிலான மறுபதிவுகள் சோர்வைத் தரக்கூடியவை மற்றும் ஆபத்தானவை. அவை பழைய பிழைகளைத் தீர்க்க முயலும்போது புதிய பிழைகளையும் உருவாக்குகின்றன. படிப்படியான மறுசீரமைப்பு, செய்யப்படுகிறது.