কয়েক বছর আগে আমি সহ অনেক আইটি লোকের জন্য, আদর্শ সফ্টওয়্যার বিকাশ প্রক্রিয়াটি কোডের একটি লাইন লেখার আগে প্রচুর ইউএমএল ডায়াগ্রামের সাথে বিশদ নকশার নথি তৈরির সাথে জড়িত। (এটিকে জলপ্রপাতের মডেলের বর্ণনার মতো মনে হচ্ছে তবে পুনরাবৃত্তিগুলি ছোট হওয়া ব্যতীত এটি চতুর সাথে একই)
গত দু-তিন বছরে আমি পুরোপুরি আমার মন পরিবর্তন করেছি। আমি এখনও মনে করি যে সম্পর্কিত পরীক্ষাগুলির সাথে বিশদ প্রয়োজনীয়তার স্পেসিফিকেশন একেবারে প্রয়োজনীয়। বড় প্রকল্পগুলির জন্য, কোড শুরু করার আগে আমার সামগ্রিক আর্কিটেকচারের একটি রূপরেখাও প্রয়োজন। তবে বাকি সমস্তগুলি যথাসম্ভব কোডে করা উচিত। আদর্শ ক্ষেত্রে কোড ছাড়া নিজেই সফ্টওয়্যার ডিজাইনের কোনও বিবরণ থাকতে হবে না।
আমি কীভাবে এই সিদ্ধান্তে পৌঁছলাম? এখানে কিছু যুক্তি দেওয়া হল:
প্রতিক্রিয়া
ডকুমেন্ট লেখার জন্য বা ডায়াগ্রাম তৈরির সরঞ্জামগুলি খুব কম প্রতিক্রিয়া সরবরাহ করে। হ্যাঁ, এমন মডেলিং সরঞ্জাম রয়েছে যা ইউএমএল ডায়াগ্রামগুলিতে কিছু ধারাবাহিকতা পরীক্ষা করে তবে সেগুলি সীমিত এবং প্রচুর ওভারহেড নিয়ে আসে।
প্রতিক্রিয়া ব্যতীত ত্রুটিগুলি চিহ্নিত করা এবং সংশোধন করা শক্ত।
কোড লেখার সাথে সাথে আপনি প্রচুর প্রতিক্রিয়া পাবেন, উদাহরণস্বরূপ:
- সংকলক থেকে ত্রুটি এবং সতর্কতা
- স্থির কোড বিশ্লেষণ ফলাফল
- ইউনিট পরীক্ষা
ত্রুটিগুলি দ্রুত চিহ্নিত এবং সংশোধন করা যায়।
দৃঢ়তা
কোডটি আপনার দস্তাবেজের সাথে সামঞ্জস্যপূর্ণ কিনা তা নিশ্চিত করার জন্য আপনাকে বারবার চেক করতে হবে। যদি ঘন ঘন পরিবর্তন হয় তবে কোড এবং দস্তাবেজগুলি সিঙ্কে রাখা শক্ত।
refactoring
পাঠ্য বিবরণ বা ডায়াগ্রামগুলি সংশোধন করার সময় শক্তিশালী সরঞ্জাম এবং কৌশলগুলি থাকে যখন পাঠ্য বিবরণ বা ডায়াগ্রামগুলি সাধারণত শক্ত এবং ত্রুটির প্রবণ হয়।
এই কাজটি করার একটি শর্ত রয়েছে: কোডটি পড়ার এবং বুঝতে যথেষ্ট সহজ হতে হবে। এটি সম্ভবত এসেম্ব্লার, বেসিক বা ফোর্টরান দিয়ে অর্জন করা যায় না তবে আধুনিক ভাষা (এবং গ্রন্থাগারগুলি) অনেক বেশি অভিব্যক্তিপূর্ণ।
সুতরাং যদি আমার যুক্তি বৈধ হয় তবে কম বা বেশি লাইটওয়েট সফ্টওয়্যার ডিজাইনের বিশদকরণ এবং ডকুমেন্টেশনের দিকে ঝোঁক থাকতে হবে। এই প্রবণতার জন্য কি কোনও অভিজ্ঞতামূলক প্রমাণ রয়েছে?