𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗧𝗿𝗮𝗱𝗲𝗼𝗳𝗳𝘀

நீங்கள் எடுக்கும் ஒவ்வொரு வடிவமைப்புத் தேர்வும் மற்றொரு விருப்பத்திற்கான கதவை மூடுகிறது. மென்பொருள் சமரசங்களின் (trade-offs) மூலமே இயங்குகிறது. நீங்கள் இந்தத் தேர்வுகளைத் திட்டமிட்டுச் செய்ய வேண்டும். இல்லையெனில், அவை தற்செயலாக நடக்கும்.

நீங்கள் எதிர்கொள்ளும் பொதுவான சமரசங்கள்:

• செயல்பாட்டுத் திறன் vs செயல்திறன் (Functionality vs Performance) சுத்தமான குறியீடு (Clean code) பெரும்பாலும் மெதுவாக இயங்கும். வேகமான குறியீடு பெரும்பாலும் வாசிப்பதற்கு கடினமாக இருக்கும். ஒரு நாளைக்கு ஒருமுறை இயங்கும் தொகுப்புச் செயல்பாடுகளுக்கு (batch processes) வாசிக்கக்கூடிய குறியீட்டைப் பயன்படுத்தவும். ஒவ்வொரு கோரிக்கையிலும் (request) ஆயிரக்கணக்கான முறை இயங்கும் பாதைகளுக்கு உகந்த (optimized) குறியீட்டைப் பயன்படுத்தவும்.

• நெகிழ்வுத்தன்மை vs எளிமை (Flexibility vs Simplicity) சிக்கலான சுருக்கங்கள் (Complex abstractions) குறியீட்டைப் புரிந்துகொள்வதைக் கடினமாக்குகின்றன. வேலை செய்யக்கூடிய மிக எளிமையான குறியீட்டை எழுதுங்கள். அதைத் தேவைப்படும்போது பின்னர் விரிவாக்கம் செய்யும் வகையில் உருவாக்குங்கள்.

• அளவிடுதல் திறன் vs செலவு (Scalability vs Cost) அதிகப்படியான போக்குவரத்திற்காக (massive traffic) வடிவமைப்பது இப்போது அதிக செலவை ஏற்படுத்தும். உங்கள் வளர்ச்சியின் விகிதத்தை அளவிடுவது நீங்கள் முடிவெடுக்க உதவும். நீங்கள் ஒவ்வொரு மாதமும் 20% வளர்கிறீர்கள் என்றால், எதிர்காலத்திற்காகத் திட்டமிடுங்கள். உங்களிடம் குறைந்த மூலதனம் இருந்தால், உங்கள் செலவுகளைக் கவனியுங்கள்.

• பாதுகாப்பு vs பயன்பாட்டுத்திறன் (Security vs Usability) அதீத பாதுகாப்பு பயனர் அனுபவத்தைப் பாதிக்கலாம். ஒருமுறை ஒரு நிர்வாகக் கருவிக்காக (admin tool) நாங்கள் வன்பொருள் டோக்கன்களை (hardware tokens) கட்டாயப்படுத்தினோம். அதன் விளைவாக லாகின் வெற்றி விகிதம் 98%-லிருந்து 84%-ஆகக் குறைந்தது. அவசர காலங்களில் பொறியாளர்கள் உள்ளே நுழைய முடியாமல் முடங்கினர். நாங்கள் மொபைல் புஷ் அறிவிப்புகளுக்கு (mobile push notifications) மாறினோம். வெற்றி விகிதம் மீண்டும் 96%-ஆக உயர்ந்தது. அதிகபட்ச பாதுகாப்பைத் தேடாமல், நியாயமான பாதுகாப்பை இலக்காகக் கொள்ளுங்கள்.

சிறந்த முடிவுகளை எடுப்பது எப்படி:

  • உங்கள் இலக்கைப் பற்றித் தெளிவாக இருங்கள்.
  • யூகிக்காமல் தரவுகளை அளவிடுங்கள்.
  • ஒரு எளிமையான தீர்with தொடங்குங்கள்.
  • உங்களிடம் போதுமான ஆதாரம் இருக்கும்போது மட்டும் மேம்படுத்துங்கள் (Optimize).
  • நீங்கள் ஏன் அந்தத் தேர்வை எடுத்தீர்கள் என்பதை ஆவணப்படுத்துங்கள்.

மைக்ரோ விநாடிகளைக் கூட மிச்சப்படுத்த ஒருமுறை நான் ஒரு JSON serializer-ஐ மேம்படுத்த முயன்றேன். அது 300 MB வரை அதிகரித்த மெமரி லீக் (memory leak) சிக்கலை ஏற்படுத்தியது. நெட்வொர்க் I/O தான் உண்மையானத் தடையானது (bottleneck) என்று ஒரு profiler காட்டியது. குறியீட்டை மீண்டும் எழுதும் முன் எப்போதும் ஒரு profiler-ஐப் பயன்படுத்துங்கள்.

தொழில்நுட்பக் கடன் (Technical debt) என்பது நிஜமானது. இன்று எடுக்கும் குறுக்குவழி நாளை நேரத்தை வீணடிக்கும். ஒரு குழப்பமான சேவையை (messy service) நாங்கள் பொறுப்பேற்றபோது, அதை முழுமையாக மாற்றியமைக்கவில்லை. மாறாக, சிறிய மற்றும் தொடர்ச்சியான மாற்றங்களைச் செய்தோம். நாங்கள் டெஸ்ட் கவரேஜை (test coverage) 30%-லிருந்து 78%-ஆக உயர்த்தினோம். இது பிழைத் திருத்த நேரத்தை 4 நாட்களில் இருந்து 1.2 நாட்களாகக் குறைத்தது.

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

Source: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Optional learning community: https://t.me/GyaanSetuAi