ডকুমেন্ট-চালিত উন্নয়ন সম্পর্কে আপনি কি জানেন?

কেন আমাদের এমনকি উন্নয়ন প্রক্রিয়ায় কোনো নথির প্রয়োজন?

এই বিবৃতি সম্পর্কে কি কোড নথি নিজেই ?

আসুন সবচেয়ে সাধারণ পরিস্থিতি বিবেচনা করা যাক: সিস্টেমের কোড (সেটি একটি প্রোগ্রাম, প্রকল্প বা পণ্যই হোক না কেন) দীর্ঘ সময়ের জন্য লেখা হচ্ছে, এবং এই প্রক্রিয়া চলাকালীন দলটি ধীরে ধীরে পরিবর্তিত হয়, বিকাশকারীরা চলে যাওয়ার সাথে সাথে তাদের সাথে সিস্টেম সম্পর্কে নির্দিষ্ট জ্ঞান গ্রহণ করে।

এমন ক্ষেত্রে আমরা কী করতে পারি?

সবচেয়ে সহজ উত্তর হল একটি স্পেসিফিকেশন লেখা যা সমস্ত বাস্তবায়নের বিবরণ ক্যাপচার করে যাতে সিস্টেমটি মূল প্রয়োজনীয়তাগুলি পূরণ করে তা নিশ্চিত করে।

যাইহোক, এই ধরনের একটি নথি আগে থেকে লেখা খুব কঠিন, এবং উন্নয়ন প্রক্রিয়া চলাকালীন, কিছু বাস্তবায়ন বিবরণ পরিবর্তিত হতে পারে (বাজারের সাথে খাপ খাইয়ে নেওয়া/মেকানিক্সের জন্য নতুন অনুরোধ ইত্যাদি)। সুতরাং, বাস ফ্যাক্টর উন্নত করার জন্য আমরা কি পরিকল্পনা করতে পারি?

আসুন একটি প্রবাহ অনুসরণ করার চেষ্টা করি যা উপরে উল্লিখিত সমস্যার সমাধানের সম্ভাব্য সমাধানগুলির মধ্যে একটি হতে পারে।

প্রয়োজনীয়তা এবং RFC

প্রথমত, আমাদের স্টেকহোল্ডারদের প্রয়োজনীয়তার ভিত্তিতে প্রাথমিক নকশা বর্ণনা করতে হবে এবং এটি নথিভুক্ত করতে হবে। এর পরে, এই নথিটি অন্যান্য দলের সাথে ভাগ করা যেতে পারে এবং তাদের প্রতিক্রিয়া অনুরোধ করা হয়েছে: নির্দিষ্ট বৈশিষ্ট্যগুলি বাস্তবায়ন করতে বলুন, প্রাথমিক নকশায় মন্তব্য করুন, একটি নির্দিষ্ট ইন্টারফেস ঠিক করুন, ইত্যাদি। এই জাতীয় নথিটিকে একটি RFC বলা যেতে পারে।

RFC , বা "মন্তব্যের জন্য অনুরোধ," হল একটি ডকুমেন্ট যা আগ্রহী পক্ষের মধ্যে বিতরণ করা হয়—যার মধ্যে ডেভেলপার, আর্কিটেক্ট এবং অন্যান্য দল রয়েছে- প্রতিক্রিয়া, মন্তব্য এবং পরামর্শ সংগ্রহ করতে। এটি একটি স্পেসিফিকেশনের চেয়ে কম বিস্তারিত এবং এতে শুধুমাত্র প্রাথমিক সমস্যা, কাজ এবং সমাধানের ডোমেন অন্তর্ভুক্ত রয়েছে। আরও নমনীয় হওয়ার কারণে, এটি নকশার পরিবর্তনগুলিকে সক্রিয়ভাবে গ্রহণ করার জন্য কাজটির গভীর উপলব্ধি নিশ্চিত করে এবং গুণমান এবং চিন্তাশীল সিদ্ধান্ত গ্রহণের সুবিধা দেয়।

ডিজাইন প্রতিশ্রুতি এবং ADR

ঠিক আছে, আমরা প্রযুক্তিগত প্রয়োজনীয়তা সংজ্ঞায়িত করেছি এবং অন্যান্য দল থেকে প্রয়োজনীয়তা সংগ্রহ করেছি । এরপর কি?

এই পর্যায়ে, সিস্টেমের নকশা এবং এটি যে সমস্ত প্রধান কার্য সম্পাদন করবে তা চূড়ান্ত করা প্রয়োজন। এই উদ্দেশ্যে, আমরা একটি ADR লিখি।

ADR , বা "আর্কিটেকচার ডিসিশন রেকর্ড," হল একটি নথি যা সফ্টওয়্যার ডেভেলপমেন্ট প্রক্রিয়া চলাকালীন গুরুত্বপূর্ণ স্থাপত্য সংক্রান্ত সিদ্ধান্তগুলি রেকর্ড করে। প্রতিটি ADR একটি নির্দিষ্ট উচ্চ-স্তরের স্থাপত্য সিদ্ধান্ত, এর প্রেক্ষাপট, বিকল্প বিবেচনা করা, সিদ্ধান্ত নেওয়া এবং অন্যদের তুলনায় এই নির্দিষ্ট বিবরণগুলি বেছে নেওয়ার প্রেরণা বর্ণনা করে।

এই জাতীয় নথি প্রতিটি দলের সদস্যকে (এবং অন্যান্য দলগুলিকেও) নকশার অন্তর্নিহিত নীতি এবং মানগুলি বোঝার অনুমতি দেয়। যদি কোনও নতুন বিকাশকারী বছর পরে দলে যোগদান করে এবং জিজ্ঞাসা করে, "কেন আপনি এইভাবে করেছেন?", তাদের এই নথিটি দেখানো যেতে পারে, যা তাদের সমস্ত প্রশ্নের উত্তর দেবে।

স্পেসিফিকেশন

এখন কোড এবং এর স্পেসিফিকেশন লেখার পালা। এই পর্যায়ে, আমরা প্রতিটি বৈশিষ্ট্যের মাধ্যমে পুঙ্খানুপুঙ্খভাবে কাজ করি, একই সাথে একটি বিশেষ নথিতে সমস্ত তথ্য এবং বাস্তবায়নের বিবরণ সংকলন করি। এই নথিটি সিস্টেমের জন্য বর্তমান নিম্ন-স্তরের প্রয়োজনীয়তাগুলিকে প্রতিফলিত করবে।

একটি গুরুত্বপূর্ণ বিষয় : সফ্টওয়্যার জীবনচক্রের সময়, এই জাতীয় স্পেসিফিকেশন উল্লেখযোগ্যভাবে পরিবর্তিত হতে পারে এবং এটি ঠিক আছে। যাইহোক, কোডবেসটিকে নিয়ন্ত্রণের অযোগ্য কিছু হতে বাধা দেওয়ার জন্য এখনও মূল নকশা এবং আর্কিটেকচারের মধ্যে থাকা খুবই গুরুত্বপূর্ণ।

পরীক্ষণ পরিকল্পনা

এটা কেন প্রয়োজন? স্পেসিফিকেশন অনুযায়ী লেখা কোডের ভিত্তিতে নয় (আমরা এই কোডের জন্য কোড এবং পরীক্ষা লিখি যাতে তারা পাস করে) তৈরি করা একটি পরীক্ষার পরিকল্পনার জন্য গুরুত্বপূর্ণ, তবে এমন একটি নকশার ভিত্তিতে যা সমালোচনামূলক পরিস্থিতি অন্তর্ভুক্ত করে সঠিকভাবে প্রক্রিয়া করা আবশ্যক । এটাও খুব সুবিধাজনক যে আপনি অন্যান্য দলের পর্যালোচনার জন্য এই ধরনের একটি পরীক্ষা পরিকল্পনা জমা দিতে পারেন (একীকরণের জন্য বা শুধুমাত্র অতিরিক্ত পরীক্ষার জন্য), এটি পরিষ্কার করে যে সিস্টেমটি বিভিন্ন পরিস্থিতিতে কীভাবে আচরণ করবে।

এটা কি অন্তর্ভুক্ত?

• সমস্ত সম্ভাব্য সিস্টেম অপারেশন পরিস্থিতিতে

  • সুখের পথ
  • বিষণ্ণ পথ
  • ত্রুটি পরিচালনা

• সিস্টেম অপারেশন সময় বজায় রাখা আবশ্যক যে সব সম্ভাব্য invariants

• শুরুতে সিস্টেমের অবস্থা পরীক্ষা করার জন্য গ্রহণযোগ্যতা পরীক্ষা (পরিবেশ বিবেচনা করা উচিত, যেমন, নেটওয়ার্কের ডেটা)

  
  

আমরা নকশা চূড়ান্ত করেছি, কোড এবং স্পেসিফিকেশন লিখেছি এবং পরীক্ষার পরিকল্পনা সংকলন করেছি। ইতিমধ্যে বেশ কঠিন শোনাচ্ছে! কিন্তু আমরা আর কি যোগ করতে পারি?

স্থাপনার পরিকল্পনা

বাস ফ্যাক্টর উন্নত করতে এবং এমন পরিস্থিতি তৈরি করার জন্য যে কোনও দলের সদস্য সিস্টেমটি স্থাপন করতে এবং এটির অবস্থা যাচাই করতে কিছু পরিমাণে এই জাতীয় পরিকল্পনার প্রয়োজন হতে পারে।

কেন আমরা এটা ছাড়া করতে পারি না? আমরা পারি, কিন্তু বাস্তব জগতে, অনেক বড় দল যেখানে সিস্টেমের বিভিন্ন অংশের জন্য অনেক লোক দায়ী, এবং স্থাপনা প্রক্রিয়া সম্পূর্ণরূপে DevOps-এ অর্পিত হতে পারে। এতে সমস্যা কী, যেহেতু আমরা পরীক্ষা লিখেছি, সেগুলিকে সিআই-তে রেখেছি এবং দুর্বলতার জন্য পরীক্ষা করেছি, আমাদের কি আর কিছু দরকার? হয়তো না, কিন্তু প্রায়ই পরীক্ষাগুলি সিস্টেমের বর্তমান অবস্থা বিবেচনা করে না এবং আমরা যা চাই তা পরীক্ষা করে না।

কি স্থাপনার পরিকল্পনা থাকতে পারে :

• মোতায়েন সঞ্চালনের জন্য সঞ্চালিত করা প্রয়োজন এমন ক্রিয়াগুলির একটি সম্পূর্ণ বিবরণ৷
• স্থাপনার পরামিতি:
  • পরিবেশ পরিবর্তনশীল
  • প্রাথমিক অবস্থায়
  • লঞ্চের জন্য পরামিতি
• কোনো পদক্ষেপে কিছু ভুল হলে তার জন্য একটি পরিকল্পনা
• একটি ব্যাকআপ পরিকল্পনা, যদি সম্ভব হয়
• স্থাপনা চালিয়ে যাওয়া সম্ভব না হলে প্রয়োজনীয় অবস্থা যেখানে সিস্টেমটি আনতে হবে
• স্থাপনার পরে সঞ্চালিত করা প্রয়োজন যে কর্ম
  • অন্যান্য দলকে অবহিত করুন
  • প্রয়োজনে প্রয়োজনীয় ইন্টিগ্রেশন সক্রিয় করুন

কিছুই জটিল, তাই না? একটি নির্দিষ্ট আপডেটের জন্য এই জাতীয় নথি থাকা বাস ফ্যাক্টরকে উল্লেখযোগ্যভাবে উন্নত করতে পারে এবং নির্দিষ্ট ব্যক্তির উপর নির্ভরতা প্রতিরোধ করতে পারে । আমরা কি এটাই চাই না?

উপসংহার

সফ্টওয়্যার ডেভেলপমেন্ট প্রক্রিয়ায়, শুধুমাত্র কোড লেখাই নয়, ডকুমেন্টেশন তৈরি করাও গুরুত্বপূর্ণ যা উন্নয়নের সমস্ত ধাপ জুড়ে বোঝাপড়া এবং ধারাবাহিকতা নিশ্চিত করে। ডকুমেন্টেশন নিজেই কোড হতে পারে , কিন্তু অভিজ্ঞতা দেখিয়েছে যে সিস্টেমের গুণমান, স্থিতিশীলতা এবং ভবিষ্যত মাপযোগ্যতা বজায় রাখার জন্য ডকুমেন্টেশন খুবই গুরুত্বপূর্ণ, বিশেষ করে যখন দলটি বিকাশের সময় পরিবর্তিত হয়, এবং এছাড়াও যখন প্রকল্পটি বিকশিত হয় এবং নতুন প্রয়োজনীয়তার সাথে খাপ খায়।

ডকুমেন্টেশনের মধ্যে রয়েছে RFC (মন্তব্যের জন্য অনুরোধ), ADR (আর্কিটেকচার রেকর্ডস), স্পেসিফিকেশন , টেস্ট প্ল্যান , ডিপ্লয়মেন্ট প্ল্যান এবং আরও অনেক কিছু। এটি দলে জ্ঞান ধারণ করার গ্যারান্টি দেবে, প্রকল্পে নতুন কর্মচারীদের একীভূত করার প্রক্রিয়াকে সহজ করবে এবং সিস্টেমের সামগ্রিক নির্ভরযোগ্যতা এবং পরিবর্তনের প্রতিরোধ বাড়াবে ।