Web Development

কখন বুজবেন আপনার সপ্টওয়ার থেকে দুর্গন্ধ বের হচ্ছে

কোন একটা Software project start করার আগে যদি Project এর clear picture আপনি বুজতে পারেন তাহলে আপনি খুবি ভাগ্যবান developer. খুব সহজেই Project develop করতে পারবেন এতে কোন সন্দেহ নাই। আর যদি Project অল্প অল্প বুজি এবং অল্প বুজা নিয়ে Project Start করেন তাহলে আপনার কপালে খারাপই লেখা আছে।

যাইহোক, ধরে নিলাম আপনি ভাগ্যবান developer. Project complete করলেন এবং First release ও দিলেন কিছুদিন পর Client বললো আমার এটা দরকার, এটা বাদ দেন, আরো feature দরকার, খেলাটা আসলে তখনি Start হবে, আর যদি Project এ problem ধরা পড়ে তাহলে অচিরেই আপনি বুজতে পারবেন কি অখাদ্য টাই আপনি বানিয়েছেন এবং এর দুর্গন্ধ কিভাবে ছড়াচ্ছে। চলেন দেখা যাক আপনি কিভাবে বুজবেন আপনার Software এ পচন ধরেছে।

বাজে Software এর দুর্গন্ধ:

১) Rigidity(অনমনিয়তা): Rigidity’র কারনে Software Change করা খুব কষ্টসাধ্য ব্যাপার, এমনকি যে কোন সহজ Change। একটা Software তখনি Rigid হয় যখন Single কোন Change এর কারনে Software এর অনেক জায়গা্য় অথবা অনেক মডিউলে Change করতে হয়। অধিকাংশ Developer’রাই এ situation face করে। যদি তাদেরকে Simple change করতে বলা হয়, তখন তারা Change এর requirement দেখে time estimate করে, কিন্তু কাজ করতে গিয়েই বিপত্তি ঘটে। তখন তাদের Simple change এর জন্য অনেক মডিউল change করতে হয়, স্বাভাবিক ভাবে Deadline miss করে। তখন তাদের যদি বলা হয় ভাই কি কারনে Deadline miss হলো Answer কি জানেন “আমি যা ভেবেছিলাম তা তার চেয়ে অনেক অনেক কঠিন”।

২) Fragility (ভন্গুরতা/অল্পতেই crash হয় এমন): Fragility হচ্ছে Program এ Simple change এর কারনে Software এর অনেক জায়গায় crash হওয়ার possibility. যার কারনে কোন একটা bug fix করতে গিয়ে developer রা আরও অনেক bug এর সম্মুখীন হয়। So, বোজেন অবস্থা!

এই ধরনের যত মডিউল Software থাকবে ততই unexpected bug এর সম্মুখীন হতে হবে সন্দেহ নাই। এই ধরনের মডিউলে সবসময় bug আসতেই থাকবে। মজার ব্যাপার কি জানেন developer রা এসব মডিউল সম্পর্কে ভালোভাবেই জানে, যে এইসব মডিউল re-design করা দরকার। কিন্তু ভয়ের কারনে করতে পারেনা, না জানি আবার কোন বড় ধরনের প্রবলেম হয়।

৩) Immobility(অসচলতা): এটা খুবি কমন ঘটনা। একটা software design তখনি immobile হবে যখন এর কোন মডিউল এর কিছু অংশ অন্য মডিউলে বা অন্য system এর জন্য useful হতে পারে, কিন্তু এইসব useful অংশ separate করা খুবি risky এবং অনেক effort এর প্রয়োজন হয়।

৪) Viscosity(লস, সান্দ্রতা): Viscosity দুই ধরনের হতে পারে-
a) viscosity of a software
b) viscosity of the environment

a) Viscosity of a software: Developer রা যখন software change করতে বসে তখন তারা অনেক way/process চিন্তা করে, এটাই স্বাভাবিক। কিছু কিছু process current design meet করে আর কিছু কিছু process crash হয়ার possibility থাকে। এখন, যে process current design meet করে তা implement করা যদি crash হয়া process এর কঠিন হয় তাহলে তখন viscosity of design high হয়। So, ভুল পথে যাওয়াটাই খুব সহজ এবং সঠিক পথে যাওয়াটা কঠিন।

Software design এমন হয়া উচিত, যাতে যে কোন change current design preserve করে সহজে করা যায়।

b) Viscosity of the environment: এখন যদি development environment এমন হয় (প্রচন্ড স্লো) simply একটা project compile/debug করতে অনেক সময় প্রয়োজন হয় তখন বোজেন developer দের মনের অবস্থা। মেজাজ খারাপ করে টেবিল থাপরানো, কিবো্র্ড থাপরানো শুরু হয়ে যাবে। এমতাবস্হায়, simple কোন change ও করতে তারা বিরক্ত হবে, সাথে যদি viscosity of software থাকে তাহলে বিপদ কারে কয়।

এই দুই ধরনের viscosity খুব dangerous। So. software environment and design এমন হয়া উচিত যাতে খুব সহজে যেকোন ধরনের change করা যায় এবং তা improve করা যায়।

৫) Needless complexity: একটা design তখনি Needless complexity এর সম্মুখীন হয় যখন system এ currently use হয়না এমন code/module থাকে। Developer দের স্বাভাবিক ভাবে project-এ এধরনের unused code রেখে দেয়ার বদঅভ্যাস থাকে। ভাবে ভবিষ্যতে কাজে লাগতেও পারে! মজার ব্যাপার হচ্ছে ভবিষ্যতে তাদের এ ভাবনা’র ঠিক উল্টোটা ঘটে। এতে করে project-এ প্রচুর unused code/module থেকে যায় পরবর্তীতে project বুজতে অনেক জামেলা পোহাতে হয়। এমতাবস্হায় যদি Developer দের নতুন কোন change দেয়া হয় তাহলে তারা নিজেরাই এই সব unused code/module দেখে হতবাক “এসব কি use হচ্ছে না হচ্ছে না, হায় হায়!”। আর যদি নতুন Developer এসব project এ কাজ করতে বসে, এই সেরেছে!

৬) Needless repetition: copy, cut, past এর সাথে আমরা সবাই পরিচিত। অনেক software আছে যেখানে একই ধরনের কোড ভিন্ন ভিন্ন মডিউলে use হয়। এধরনের কোড শত শত হতে পারে। তো developer রা just copy+past করে এবং requirement অনুযায়ী change নেয় এটা খুব স্বাভাবিক। এখন কোন কারনে যদি developer copy+past করে requirement অনুযায়ী change করতে miss করে তখন টের পাবেন কি আজিব টাইপের bug আসা শুরু হয়েছে, সেই সাথে client এর গালিগালাজ শুনতে হতে পারে। Be careful about copy+paste। এবং project এ কোড repetition যত কম করা যায় ততই ভালো।

৭) Opacity(জড়তা): যখন software এর module বুজতে অনেক কঠিন হয় তখন তা Opacity হিসেবে বিবেচিত হয়। কোড করার সময় এমন ভাবে করতে হয় যেন যে কেউ কোড দেখে সহজে বুজতে পারে।

Developer রা যখন কোড start করে তখন তাদের কাছে কোড খুব ক্লিন এবং ক্লিয়ার মনে হয়। এবং একটা সময় যাওয়ার পর অনেক কোড হয়ে যায় যা স্বাভাবিক। তো Developer রা যখন পরে আবার কোড মডিফাই কিংবা change করতে বসে তখন তো অবস্হা কাহিল “কি জন্য কি কোড করেছিলাম নিজেই তো ভুলে গেছি”! হায় হায় বলে কি?

So, senior developer দের উচিত কোড review করা otherwise ডট ডট ডট

পলাশ, ১১-০৭-১১

—————————————————————————

Dedicated to all developers

Ref: Agile Principles, Patterns, and Practices in C# – Robart C. Martin and Micah Martin

বাংলা, ইংরেজী একসাথে use করা জন্য really sorry.

Advertisements

2 thoughts on “কখন বুজবেন আপনার সপ্টওয়ার থেকে দুর্গন্ধ বের হচ্ছে

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s