2.14 প্রকল্প ও রিপজিটরির কাঠামো
পরিচিতি ও প্রেরণা
প্রকল্প ও রিপজিটরির কাঠামো হলো একটি কোডবেসের ভৌত সংগঠন: যে ফোল্ডার, ফাইল ও নামকরণের রীতি ঠিক করে কোনো জিনিস কোথায় থাকে। একটি রিপজিটরি (প্রায়ই “রিপো” সংক্ষেপে) হলো সেই ভার্সন-নিয়ন্ত্রিত আধার, যা একটি প্রকল্পের ফাইল ও তাদের ইতিহাস ধরে রাখে। একটি প্রকল্প, কখনো কখনো সমাধান বলা হয় যখন তা কয়েকটি সম্পর্কিত উপাদান জড়ো করে, হলো আপনার গড়া সফটওয়্যারের যৌক্তিক একক। কাঠামো হলো সেই মানচিত্র, যা দিয়ে আপনি সেই সফটওয়্যার খুঁজে পান, বোঝেন ও বদলান।
ছোট দলে একজন মানুষ পুরো বিন্যাস মাথায় ধরে রাখতে পারেন। বড় দলে, শত শত বা হাজারো ইঞ্জিনিয়ার, দলগুলোর মধ্যে ঘন ঘন সরা এবং ঠিকাদারদের আসা-যাওয়াসহ, ভিন্নভাবে সংগঠিত প্রতিটি রিপজিটরি নতুন জ্ঞানীয় কর আরোপ করে। অপরিচিত রিপো খুললে আপনি ম্যানুয়াল না পড়েই অনুমান করতে পারা উচিত সোর্স, টেস্ট, ডকুমেন্টেশন ও ডিপ্লয়মেন্ট কনফিগারেশন কোথায় থাকে। প্রতিটি রিপো যখন সেই প্রশ্নের একই উত্তর দেয়, তখন সরা সস্তা এবং অনবোর্ডিং দ্রুত। প্রতিটি রিপো যখন স্নোফ্লেক, প্রতিটি প্রেক্ষাপট বদল একটি ছোট গবেষণা প্রকল্প হয়ে ওঠে।
এন্টারপ্রাইজ ও সরকারি পরিবেশে সামঞ্জস্যপূর্ণ কাঠামো নিয়ন্ত্রণ ও নিশ্চয়তার উদ্বেগও। নিরীক্ষক, নিরাপত্তা পর্যালোচক এবং দীর্ঘমেয়াদি রক্ষণাবেক্ষক, যাঁরা প্রায়ই মূল রচয়িতা চলে যাওয়ার বছর পরে কাজ করেন, নির্ভরযোগ্যভাবে স্পেসিফিকেশন নথি, লাইসেন্স ফাইল, নিরাপত্তা নীতি ও বিল্ড সংজ্ঞা খুঁজে পেতে চান। একটি পূর্বানুমেয় বিন্যাস স্বয়ংক্রিয় টুলিংকেও (স্ক্যানার, নির্ভরতা বিশ্লেষক, বিধি-মান্যতা পরীক্ষা) সিস্টেমের পুরো পোর্টফোলিও জুড়ে একইভাবে কাজ করতে দেয়। তাই এই অধ্যায় কাঠামোকে এমন রীতি হিসেবে দেখে, যা আপনি একবার ঠিক করেন এবং সর্বত্র প্রয়োগ করেন। এটি কোডিং মান ও শৈলী (অধ্যায় 2.1), ভার্সন কন্ট্রোল ও সোর্স ব্যবস্থাপনা (অধ্যায় 2.6) এবং ডকুমেন্টেশনের (অধ্যায় 2.7) সঙ্গে ঘনিষ্ঠভাবে সম্পর্কিত।
মূল নীতিসমূহ
- ন্যূনতম বিস্ময়ের নীতি অনুসরণ করুন: বিন্যাস একজন অভিজ্ঞ ইঞ্জিনিয়ারের প্রত্যাশার সঙ্গে মেলা উচিত, যাতে কিছু মুখস্থ করতে না হয়।
- স্থানীয় চতুরতার চেয়ে রিপজিটরি জুড়ে সামঞ্জস্য ভালো; সর্বত্র যথেষ্ট-অভিন্ন কাঠামো এক জায়গার নিখুঁত কাঠামোর চেয়ে বেশি মূল্যবান।
- README হলো সামনের দরজা; একজন নবাগত কেবল তা থেকেই নিজেকে অভিমুখী করতে পারা উচিত।
- নামকরণের মাধ্যমে কাঠামোকে স্বয়ংবর্ণনামূলক করুন, যাতে ফোল্ডার ও ফাইল তাদের উদ্দেশ্য ঘোষণা করে।
- ইচ্ছাশক্তি ও রিভিউ মন্তব্যে নয়, স্ক্যাফোল্ডিং ও টেমপ্লেট দিয়ে কাঠামো বলবৎ করুন।
- উদ্বেগ ভৌতভাবে আলাদা করুন: সোর্স, টেস্ট, ডক, বিল্ড ও ডিপ্লয়মেন্ট স্বতন্ত্র, পূর্বানুমেয় জায়গায় থাকে।
- নির্ভরতা এমনভাবে সংগঠিত করুন যাতে তা এক দিকে প্রবাহিত হয়, স্থিতিশীল কেন্দ্র থেকে অস্থির প্রান্তের দিকে।
সুপারিশ
একটি সামঞ্জস্যপূর্ণ শীর্ষ-স্তরের বিন্যাস গ্রহণ করুন
শীর্ষ-স্তরের ফোল্ডারের একটি প্রমিত সেট সংজ্ঞায়িত করুন, যা প্রতিটি রিপজিটরি যেখানে প্রযোজ্য ব্যবহার করে, এবং প্রতিটির উদ্দেশ্য নথিবদ্ধ করুন। একটি সাধারণ, বিক্রেতা-নিরপেক্ষ রীতিতে আছে: উৎপাদন কোডের জন্য একটি সোর্স ফোল্ডার (প্রায়ই src); স্বয়ংক্রিয় টেস্টের জন্য একটি টেস্ট ফোল্ডার (প্রায়ই test বা tests); ডকুমেন্টেশনের জন্য docs ফোল্ডার; বিল্ড সংজ্ঞা ও আউটপুটের জন্য build ফোল্ডার; ডিপ্লয়মেন্ট ও অবকাঠামো-অ্যাজ-কোড (সার্ভার, নেটওয়ার্ক ও সেবার যন্ত্র-পাঠযোগ্য সংজ্ঞা, অধ্যায় 8.2-এ আচ্ছাদিত)-এর জন্য deploy ফোল্ডার; স্বয়ংক্রিয়করণ ও ডেভেলপার টুলিংয়ের জন্য scripts ফোল্ডার; চালানো-যায় নমুনার জন্য examples ফোল্ডার; এবং প্রয়োজনীয়তা ও নকশা স্পেসিফিকেশনের জন্য spec বা specification ফোল্ডার। প্রতিটি রিপোতে প্রতিটি ফোল্ডার লাগে না, কিন্তু যেখানে কোনো উদ্বেগ আছে, তা প্রত্যাশিত জায়গায় প্রত্যাশিত নামে থাকা উচিত।
README-কে প্রবেশ-বিন্দু করুন
একক, প্রামাণ্য শুরুর বিন্দু হিসেবে রিপজিটরির মূলে একটি README ফাইল আবশ্যক করুন। এতে বলা উচিত প্রকল্পটি কী, কীভাবে তা গড়তে ও চালাতে হয়, কীভাবে টেস্ট চালাতে হয়, গভীরতর ডকুমেন্টেশন কোথায় পাবেন, কার মালিকানা, এবং কীভাবে অবদান রাখবেন। README সম্পূর্ণ ডকুমেন্টেশন সেট নয়; এটি সূচি যা বাকিটার দিকে নির্দেশ করে (অধ্যায় 2.7)। অনুপস্থিত বা সেকেলে README-কে ত্রুটি গণ্য করুন, কারণ এটিই প্রতিটি নতুন ইঞ্জিনিয়ার, নিরীক্ষক বা ইন্টিগ্রেটরের প্রথম পড়া জিনিস।
এডিটর ও কনফিগারেশন ফাইল প্রমিত করুন
ভাগ করা এডিটর ও টুলিং কনফিগারেশন রিপজিটরিতে চেক-ইন করুন, যাতে প্রতিটি অবদানকারী স্বয়ংক্রিয়ভাবে সামঞ্জস্যপূর্ণ আচরণ পায়। একটি .editorconfig ফাইল (সাদা স্থান, ইন্ডেন্টেশন ও লাইন-শেষের নিয়ম সংজ্ঞায়িত করা একটি সরল, এডিটর-নিরপেক্ষ ফাইল) বিভিন্ন এডিটর ও অপারেটিং সিস্টেম জুড়ে মৌলিক ফরম্যাটিং অভিন্ন রাখে। ভার্সন-কন্ট্রোল সিস্টেমের জন্য একটি উপেক্ষা ফাইল যোগ করুন (যাতে বিল্ড আউটপুট ও স্থানীয় সামগ্রী কখনো কমিট না হয়), সঙ্গে অধ্যায় 2.1-এ বর্ণিত ভাগ করা ফরম্যাটার ও লিন্টার কনফিগারেশন। এই ফাইলগুলো রিপজিটরির রীতিকে কেবল নথিবদ্ধ নয়, সক্রিয় করে।
নামকরণ ও ফোল্ডার রীতি সংজ্ঞায়িত করুন
ফোল্ডার ও ফাইল নামকরণের রীতিতে (কেসিং, বিভাজক, একবচন বনাম বহুবচন, এবং টেস্ট চিহ্নিত করার মতো প্রয়োজনীয় প্রত্যয়) একমত হন এবং সমানভাবে প্রয়োগ করুন। নাম উদ্দেশ্য প্রকাশ করা উচিত এবং প্রতিষ্ঠানের অন্যত্র ব্যবহৃত ডোমেইন শব্দভাণ্ডারের সঙ্গে মেলা উচিত। লক্ষ্য সরল: একটি পথ অর্থ জানাবে, যাতে একটি ফোল্ডার বা ফাইলের নাম পড়েই না খুলে জানা যায় ভেতরে কী আছে।
স্তর ও নির্ভরতা সুচিন্তিতভাবে সংগঠিত করুন
কোডবেস এমনভাবে কাঠামো করুন যাতে তার স্থাপত্যগত স্তর ফোল্ডার বিন্যাসে দেখা দেয়, এবং নির্ভরতা একটি একক, যুক্তিসঙ্গত দিকে প্রবাহিত হয়। উচ্চ-স্তরের নীতি নিম্ন-স্তরের খুঁটিনাটির ওপর নির্ভর করা উচিত নয়। ভাগ করা, স্থিতিশীল কোড এমন জায়গায় বসা উচিত যেখানে বহু মডিউল চক্র তৈরি না করে তাতে পৌঁছাতে পারে। স্তরবিন্যাস ভৌত করলে, ডিরেক্টরি ট্রিতে প্রতিফলিত, ইঞ্জিনিয়াররা তা মানার সম্ভাবনা বেশি, এবং রিভিউ ও স্বয়ংক্রিয় নির্ভরতা পরীক্ষায় লঙ্ঘন ধরা সহজ।
স্ক্যাফোল্ডিং ও টেমপ্লেট দিয়ে কাঠামো বলবৎ করুন
স্ক্যাফোল্ডিং, একটি শুরুর প্রকল্পের স্বয়ংক্রিয় তৈরি, দিন, যাতে নতুন রিপজিটরি আগে থেকেই সঠিক অবস্থায় শুরু হয়। একটি টেমপ্লেট বা কুকিকাটার (পরামিতিযুক্ত প্রকল্প কঙ্কাল, যা কয়েকটি প্রশ্নের উত্তর থেকে একটি তৈরি রিপজিটরি তৈরি করে) প্রমিত বিন্যাস, README, কনফিগ ফাইল এবং CI সেটআপ এক জায়গায় এনকোড করে। ইঞ্জিনিয়াররা ভাগ করা টেমপ্লেট থেকে নতুন সার্ভিস তৈরি করলে সামঞ্জস্য আকাঙ্ক্ষার বদলে ডিফল্ট হয়, এবং টেমপ্লেটের উন্নতি ভবিষ্যৎ প্রকল্পে প্রবাহিত হয়।
বহু রিপজিটরি জুড়ে বড় পরিসরে কাঠামো সামঞ্জস্যপূর্ণ রাখুন
বিন্যাসকেই নিয়ন্ত্রিত মান হিসেবে দেখুন: অন্য যেকোনো প্রকৌশল মানের মতো কেন্দ্রীয়ভাবে রক্ষণাবেক্ষণ করা (অধ্যায় 1.7), এবং কোডের মতো ভার্সন করা (অধ্যায় 2.6)। এটি প্রকাশ করুন, এটি বাস্তবায়নকারী টেমপ্লেট দিন, এবং বিচ্যুতি কেবল নথিবদ্ধ ব্যতিক্রম প্রক্রিয়ায় অনুমতি দিন, যাতে “মান” তার অর্থ ধরে রাখে। পোর্টফোলিও পরিসরে কাঠামোর প্রায় সব মূল্য আসে রিপজিটরি জুড়ে অভিন্নতা থেকে, তাই বিচ্যুতিই পরিচালনার মূল ঝুঁকি।
মনোরিপো বনাম বহু-রিপো পছন্দে কাঠামোকে জানাতে দিন
কাঠামোকে অধ্যায় 2.6-এ আচ্ছাদিত রিপজিটরি-সীমানার সিদ্ধান্তের সঙ্গে যুক্ত করুন। একটি মনোরিপো (বহু প্রকল্প ধারণকারী একটি রিপজিটরি)-র প্রকল্প ও তাদের ভাগ করা কোড আলাদা করার একটি স্পষ্ট অভ্যন্তরীণ রীতি দরকার, যাতে একক ট্রি নেভিগেট-যোগ্য থাকে। একটি বহু-রিপো পদ্ধতির (প্রতি প্রকল্প বা সার্ভিসে একটি ছোট রিপজিটরি) শক্ত আন্তঃরিপো সামঞ্জস্য দরকার, যাতে প্রতিটি রিপো আলাদাভাবে দাঁড়ালেও পরিচিত মনে হয়। যেভাবেই হোক, একটি নথিবদ্ধ, টেমপ্লেটযুক্ত কাঠামোই নেভিগেশন পূর্বানুমেয় রাখে। সীমানা পছন্দ বদলায় আপনি কোথায় রীতি প্রয়োগ করেন, রীতি লাগে কি না তা নয়।
ট্রেড-অফ: সুবিধা ও অসুবিধা
| পছন্দ | সুবিধা | অসুবিধা |
|---|---|---|
| কঠোর প্রতিষ্ঠানজোড়া প্রমিত বিন্যাস | তাৎক্ষণিক পরিচিতি; স্থানান্তরযোগ্য ইঞ্জিনিয়ার; অভিন্ন টুলিং | অস্বাভাবিক প্রকল্পে মাঝেমধ্যে খারাপ খাপ; গভর্নেন্স লাগে |
| প্রতি-দলের বিন্যাসের স্বাধীনতা | স্থানীয় অপ্টিমাইজেশন; উচ্চ স্বায়ত্তশাসন | খণ্ডন; ব্যয়বহুল প্রেক্ষাপট বদল; অসঙ্গত টুলিং |
| স্ক্যাফোল্ডিং ও টেমপ্লেট | ডিফল্টে সঠিক রিপো; পরিবর্তন ছড়ায় | টেমপ্লেট রক্ষণাবেক্ষণ; তৈরি রিপো থেকে বিচ্যুতির ঝুঁকি |
| গভীর, স্তরবিন্যস্ত ফোল্ডার শ্রেণিবিন্যাস | সুস্পষ্ট কাঠামো; স্পষ্ট সীমানা | নেভিগেশনের বাড়তি বোঝা; দীর্ঘ পথ; অতি-প্রকৌশলের ঝুঁকি |
| সমতল, অগভীর বিন্যাস | স্ক্যান করা সহজ; কম আনুষ্ঠানিকতা | দুর্বল বিচ্ছিন্নতা; প্রকল্প বাড়লে ভেঙে পড়ে |
প্রধান ট্রেড-অফ অভিন্নতা বনাম স্বায়ত্তশাসন। একটি একক প্রমিত বিন্যাস কোডবেসের মধ্যে সরা বহু ইঞ্জিনিয়ারের ঘর্ষণ সরায়, মাঝেমধ্যে এমন প্রকল্পের মূল্যে যার প্রয়োজন ছাঁচে ঠিকঠাক খাপ খায় না। একটি বড় প্রতিষ্ঠানে পরিচিতি থেকে সামগ্রিক লাভ প্রায় সবসময় সেই স্থানীয় ক্ষতিকে ছাড়িয়ে যায়। সেজন্যই প্রস্তাবিত অবস্থান কঠোর অভিন্নতা বা অপরিচালিত স্বাধীনতা নয়, বরং একটি শক্ত ডিফল্ট মান এবং একটি নথিবদ্ধ ব্যতিক্রম পথ (অধ্যায় 1.7)। একটি গৌণ ট্রেড-অফ গভীরতা বনাম সরলতা: প্রকৃত উদ্বেগ আলাদা করতে যথেষ্ট কাঠামো, কিন্তু এতটা নয় যে নেভিগেশন ফাঁকা ফোল্ডারের মধ্য দিয়ে ভ্রমণ হয়ে ওঠে।
আপনার দলের সঙ্গে আলোচনার প্রশ্ন
একজন ইঞ্জিনিয়ার আমাদের কোনো অপরিচিত রিপোতে গেলে টেস্ট, ডিপ্লয় কনফিগ ও মালিক খুঁজে পেতে কত সময় লাগে? এটি সেই নেভিগেশন কর, যা দূর করতে কাঠামো আছে, এবং পোর্টফোলিও পরিসরে এটি বছরে হাজার বার ছোট ছোট ভাগে দেওয়া হয়, যা যোগ হয়ে গুরুতর হারানো প্রকৌশল সময় দাঁড়ায়। ন্যূনতম বিস্ময়ের নীতির মূল কথা হলো একজন অভিজ্ঞ ইঞ্জিনিয়ার ম্যানুয়াল না পড়েই অনুমান করতে পারা উচিত সোর্স, টেস্ট, ডক ও ডিপ্লয়মেন্ট কোথায় থাকে, তাই সৎ পরীক্ষা হলো সেই অনুমান আপনার রিপো জুড়ে সফল হয় কি না। সভায় একটি প্রকৃত সংখ্যা আনুন: দুই-তিনটি অপরিচিত অভ্যন্তরীণ রিপজিটরিতে নিজেদের অভিমুখী হতে সময় মাপুন, বা নতুন সদস্যরা একটি প্রথম পরিবর্তন করতে কত সময় নেন তার অনবোর্ডিং তথ্য টানুন। উত্তর যদি চেনার মিনিটের বদলে গবেষণার দিনে মাপা হয়, তাহলে আপনি স্নোফ্লেক রিপোর খরচ পরিমাণযোগ্য করেছেন, এবং প্রতিটি রিপো ভাগ করা একটি প্রমিত বিন্যাসে একবারের বিনিয়োগ তা যুক্তিসঙ্গত করে।
আমাদের স্থাপত্যগত স্তর কি ফোল্ডার ট্রিতে দেখা দেয়, নাকি নির্ভরতার চক্র সমতল বিন্যাসের ভেতরে লুকায়? কাঠামো কেবল খুঁজে-পাওয়া নয়: স্তরবিন্যাস ভৌত করলে ইঞ্জিনিয়াররা তা মানেন এবং পর্যালোচক ও স্বয়ংক্রিয় নির্ভরতা পরীক্ষা লঙ্ঘন ধরতে পারে, আর সমতল স্তূপ অনুপযুক্ত সংযুক্তি ও চক্র অলক্ষ্যে ঢুকতে দেয় যতক্ষণ না পরিবর্তন বিপজ্জনক হয়। বড়, দীর্ঘজীবী সিস্টেমে এটিই উচ্চ-স্তরের নীতিকে নিঃশব্দে নিম্ন-স্তরের খুঁটিনাটির ওপর নির্ভর করা থেকে ঠেকায়, এবং এটিই সেই ক্ষয় যা ঠেকানো সস্তা আর উল্টানো ব্যয়বহুল। আপনার নির্ভরতা গ্রাফ আনুন বা একটি দ্রুত পরীক্ষা চালান: কোনো চক্র আছে কি, এবং স্থিতিশীল কিছু কি অস্থির কিছুর ওপর নির্ভর করে? উত্তর আপনাকে ডিরেক্টরিতে স্তর প্রতিফলিত করা এবং স্বয়ংক্রিয় নির্ভরতা-দিকের পরীক্ষা যোগ করার দিকে ঠেলা উচিত, যাতে সীমানা ট্রিতে দৃশ্যমান এবং পাইপলাইনে বলবৎ থাকে, কারও মানসিক মডেলে থাকার বদলে।
আমাদের নতুন রিপজিটরি কি একটি টেমপ্লেট থেকে সঠিক অবস্থায় শুরু হয়, নাকি আমরা একটি উইকি পাতা ও শুভ উদ্দেশ্যের ওপর ভরসা করি? স্ক্যাফোল্ডিং দিয়ে বলবৎ কাঠামো ডিফল্ট; দলিলে বর্ণিত কাঠামো বিচ্যুত হয়, কারণ বাস্তবতা অনুসরণ করে যা রিপো তৈরি করে, কোনো পাতা কেমন হওয়া উচিত বলে তা নয়। বড় বা নিয়ন্ত্রিত প্রতিষ্ঠানের জন্য এটি নিশ্চয়তার উদ্বেগও: প্রতিটি রিপো একটি ভাগ করা টেমপ্লেট থেকে তৈরি হলে নিরাপত্তা স্ক্যানার, নির্ভরতা বিশ্লেষক ও নিরীক্ষকরা লাইসেন্স, নিরাপত্তা নীতি, স্পেসিফিকেশন ও বিল্ড সংজ্ঞা প্রতিবার একই জায়গায় পান, বিক্রেতা ও বছর জুড়ে। প্রমাণ আনুন: আপনার সাম্প্রতিক কতগুলো রিপো প্রমিত টেমপ্লেট থেকে স্ক্যাফোল্ড করা বনাম হাতে জোড়া, এবং টেমপ্লেট-করাগুলো তারপর কতটা বিচ্যুত হয়েছে? পদক্ষেপ হলো টেমপ্লেটকে রিপো শুরু করার একমাত্র সহজ উপায় করা, একে নথিবদ্ধ ব্যতিক্রম পথসহ ভার্সনযুক্ত মান হিসেবে নিয়ন্ত্রণ করা, এবং বিচ্যুতি স্বয়ংক্রিয়ভাবে শনাক্ত করা, কারণ কাঠামোর প্রায় সব মূল্য থাকে অভিন্নতায়।
আমাদের মান একটি মনোরিপো না বহু আলাদা রিপজিটরি জুড়ে বিস্তৃত তা কি আমরা ঠিক করেছি, এবং সেই সীমানার দুই পাশেই কি একই রীতি আসলে ধরে? রিপজিটরি-সীমানার পছন্দ বদলায় আপনি কোথায় রীতি প্রয়োগ করেন, রীতি লাগে কি না তা নয়, এবং এটি ভুল করলে মানে এমন একটি দৈত্যাকার ট্রি যা কেউ নেভিগেট করতে পারে না, বা প্রতিটি অপরিচিত মনে হওয়া রিপোর ছড়াছড়ি। একটি মনোরিপোর প্রকল্প ও তাদের ভাগ করা কোড আলাদা করার একটি স্পষ্ট অভ্যন্তরীণ রীতি লাগে যাতে একক ট্রি নেভিগেট-যোগ্য থাকে, আর বহু-রিপো পদ্ধতির শক্ত আন্তঃরিপো সামঞ্জস্য লাগে যাতে প্রতিটি আলাদা রিপো তবু পরিচিত মনে হয়। বর্তমান তালিকা আনুন: আপনার কতগুলো রিপো আছে, কোনো মনোরিপোর ভেতরে ভাগ করা কোড কীভাবে আলাদা করা, এবং একজন ইঞ্জিনিয়ার বড় ট্রির ভেতরে একটি প্রকল্প একটি আলাদা রিপোর মতো দ্রুত খুঁজে পান কি না তার একটি সময়-মাপা পরীক্ষা। বড় এন্টারপ্রাইজ বা সরকারি কর্মসূচি, যেখানে ভিন্ন বিক্রেতারা আলাদা রিপজিটরি সরবরাহ করে, তার জন্য সুচিন্তিতভাবে ঠিক করুন রীতির কোন অংশ সার্বজনীন আর কোনগুলো সীমানা-নির্দিষ্ট, কারণ নিরীক্ষক ও প্ল্যাটফর্ম টুলিংকে একইভাবে কাজ করতে হবে, কোড একটি ট্রি হিসেবে আসুক বা পঞ্চাশটি।
আমাদের কাঠামো মানের মালিক কে, এবং কোনো প্রকল্প সত্যিই তাতে খাপ না খেলে আসলে কী ঘটে? পোর্টফোলিও পরিসরে কাঠামোর প্রায় সব মূল্য আসে অভিন্নতা থেকে, তাই প্রকৃত ঝুঁকি হলো মালিকহীন মান যা পচে, এবং এত অস্পষ্ট ব্যতিক্রম পথ যে প্রতিটি দল নিঃশব্দে নিজের বিন্যাস উদ্ভাবন করে। টানাপোড়েন কোনো অস্বাভাবিক প্রকল্পে খাপ না-খাওয়া কঠোর অভিন্নতা আর সবকিছু খণ্ডিত করা অপরিচালিত স্বাধীনতার মধ্যে, এবং সুস্থ উত্তর একটি শক্ত ডিফল্ট, সঙ্গে একটি নামধারী মালিক দ্বারা নিয়ন্ত্রিত ও কোডের মতো ভার্সন করা একটি নথিবদ্ধ, নিরীক্ষণযোগ্য ব্যতিক্রম প্রক্রিয়া। প্রমাণ আনুন: একজন একক জবাবদিহিযোগ্য মালিক আছে কি, চেঞ্জলগসহ একটি ভার্সনযুক্ত মান নথি আছে কি, মঞ্জুর করা ব্যতিক্রম ও কেন তার লগ আছে কি, এবং আপনি বাস্তবে খুঁজে পান এমন অনথিভুক্ত বিচ্যুতির সংখ্যা। এন্টারপ্রাইজ ও সরকারি পরিবেশে কেউ রেকর্ড না করা ব্যতিক্রম একটি নিয়ন্ত্রণ ফাঁক, তাই প্রতিটি বিচ্যুতি একটি লিখিত যুক্তি ও পর্যালোচনার তারিখের সঙ্গে বাঁধুন, এবং নিশ্চিত করুন যে বিন্যাস বাধ্যতামূলক করা ক্রয় চুক্তি এর থেকে বিচ্যুতি অনুমোদনের অধিকারীরও নাম দেয়।
আমাদের README ও চেক-ইন করা কনফিগারেশন ফাইল কি আমাদের রীতিকে সক্রিয় করে, নাকি সাজসজ্জা? README হলো সামনের দরজা, আর চেক-ইন করা
.editorconfig, উপেক্ষা ফাইল ও লিন্টার কনফিগারেশনই রীতিকে স্বয়ং-বলবৎ করে, তবু এগুলোই প্রথমে সেকেলে হয় এবং কোনো নিরীক্ষক বা নতুন সদস্য প্রকল্পটি গড়তে না পারা পর্যন্ত সবশেষে কেউ লক্ষ্য করে। টানাপোড়েন হলো হালনাগাদ থাকা ছিমছাম README আর বিচ্যুত হওয়া পুঙ্খানুপুঙ্খ README-র মধ্যে, এবং ঠিকভাবে কোড ফরম্যাট করতে মানুষকে বিশ্বাস করা আর ভাগ করা কনফিগারেশনকে স্বয়ংক্রিয়ভাবে তা বলবৎ করতে দেওয়ার মধ্যে। একটি নমুনা আনুন: পাঁচটি রিপো টেনে দেখুন কতগুলো README আসলে বলে প্রকল্পটি কী, কীভাবে গড়তে, পরীক্ষা করতে ও চালাতে হয়, এবং কে মালিক, আর কতগুলো ব্যক্তিগত অভ্যাসের ওপর ভরসা না করে ভাগ করা কনফিগারেশন ফাইল বহন করে। বড় বা নিয়ন্ত্রিত প্রতিষ্ঠানের জন্য, যেখানে ইন্টিগ্রেটর, নিরাপত্তা পর্যালোচক ও দীর্ঘমেয়াদি রক্ষণাবেক্ষকরা অন্য সবকিছুর আগে README পড়েন, অনুপস্থিত বা সেকেলে সামনের দরজাকে মালিকসহ ত্রুটি ভাবুন, এবং কনফিগ-ফাইলের উপস্থিতি স্বয়ংক্রিয়ভাবে যাচাই করুন, যাতে সামঞ্জস্য শুভেচ্ছার ওপর নির্ভর না করে।
খাতভেদে দৃষ্টিভঙ্গি
স্টার্টআপ। গতিই জেতে, তাই আপনার প্রথম রিপোর জন্য একটি সরল, যথেষ্ট-সমতল বিন্যাসে একমত হন (src, test, docs, scripts, একটি পূর্ণ README, একটি .editorconfig এবং উপেক্ষা ফাইল) এবং একই বিকেলে একটি হালকা টেমপ্লেট হিসেবে সংরক্ষণ করুন। দ্বিতীয় সার্ভিস তা থেকে তৈরি করুন, যাতে দুটি রিপোই পরিচিত মনে হয় এবং একজন নতুন ঠিকাদার স্নোফ্লেক রিভার্স-ইঞ্জিনিয়ারিংয়ের বদলে ঘণ্টায় অনবোর্ড হন। যে গভীর শ্রেণিবিন্যাস ও ভারী গভর্নেন্স এখনো লাগে না তা প্রতিরোধ করুন; পুরো প্রতিদান হলো দুই প্রতিষ্ঠাতা ও একজন ঠিকাদার একটি মানচিত্র ভাগ করেন।
ছোট ব্যবসা। কোনো প্ল্যাটফর্ম বিশেষজ্ঞ নেই আর বাজেট কম, তাই একটি উদ্ভাবনের বদলে আপনার ভাষা বা ফ্রেমওয়ার্ক ইতিমধ্যে যে প্রচলিত বিন্যাস ধরে নেয় তা গ্রহণ করুন, যাতে তৈরি টুলিং ও যেকোনো নতুন সদস্য আগে থেকেই তাতে প্রশিক্ষিত আসেন। নিজের বানানোর বদলে স্ক্যাফোল্ডিং কিনুন (একটি ফ্রেমওয়ার্ক জেনারেটর বা কুকিকাটার টেমপ্লেট), এবং আপনার দুষ্প্রাপ্য প্রচেষ্টা একটি পূর্ণ README হালনাগাদ রাখতে ব্যয় করুন। সেই README হলো যে দিন বিন্যাস জানা একমাত্র মানুষ সরে যান সেদিনের জন্য আপনার সবচেয়ে সস্তা বিমা।
এন্টারপ্রাইজ। বহু দল ও শত শত রিপজিটরি জুড়ে লক্ষ্য অভিন্নতা: একটি ভার্সনযুক্ত কাঠামো মান প্রকাশ করুন, প্রতিটি নতুন সার্ভিস ভাগ করা টেমপ্লেট থেকে তৈরি করুন, বিচ্যুতি স্বয়ংক্রিয়ভাবে শনাক্ত করুন, এবং বিচ্যুতি কেবল নথিবদ্ধ ব্যতিক্রম প্রক্রিয়ায় অনুমতি দিন। প্রতিটি রিপো একই রকম দেখায় বলে নতুন দলে বদলি হওয়া ইঞ্জিনিয়ার ঘণ্টার মধ্যে উৎপাদনশীল হন এবং পোর্টফোলিওজোড়া নিরাপত্তা ও নির্ভরতা স্ক্যানার প্রতিবার একই জায়গায় লাইসেন্স, নিরাপত্তা নীতি ও বিল্ড সংজ্ঞা পায়। টেমপ্লেট রক্ষণাবেক্ষণ ও বিচ্যুতি শনাক্তকরণে সুস্পষ্টভাবে বাজেট করুন, কারণ সেই রক্ষণাবেক্ষণই বড় পরিসরে মানকে অর্থপূর্ণ রাখে।
সরকার। ক্রয়, স্বচ্ছতা ও দীর্ঘমেয়াদি জবাবদিহি বিন্যাসকে আকার দেয়, তাই প্রতিটি বিক্রেতাকে বাঁধা সরবরাহ মানে একটি সাধারণ কাঠামো বাধ্যতামূলক করুন। কোডকে অনুমোদিত প্রয়োজনীয়তায় যুক্ত করা একটি specification ফোল্ডার, মূলে একটি লাইসেন্স ও নিরাপত্তা-নীতি ফাইল, এবং অবকাঠামো-অ্যাজ-কোড সংজ্ঞা ধারণকারী একটি deploy ফোল্ডার আবশ্যক করুন, যাতে নিরীক্ষকরা প্রতিটি সিস্টেমে বিধি-মান্যতা সামগ্রী একইভাবে খুঁজে পান। ভিন্ন বিক্রেতার ঠিকাদাররা সবাই একটি মানচিত্র অনুসরণ করে বলে চুক্তি শেষ হওয়ার পর রক্ষণাবেক্ষণের খরচ অনেক কম, এবং জনগণ প্রয়োজনীয়তা থেকে চলমান কোড পর্যন্ত একটি সমর্থনযোগ্য, পরিদর্শনযোগ্য ট্রেইল পায়।
উদাহরণ
স্টার্টআপ। তিনজনের একটি স্টার্টআপ তার প্রথম রিপোর জন্য একটি সরল প্রমিত বিন্যাসে একমত হয় (src, test, docs, scripts, একটি পূর্ণ README, একটি .editorconfig এবং উপেক্ষা ফাইল) এবং একটি হালকা টেমপ্লেট হিসেবে সংরক্ষণ করে। এক মাস পরে দ্বিতীয় সার্ভিস চালু করার সময় তারা সেই টেমপ্লেট থেকে তৈরি করে, তাই দুটি রিপোই ইতিমধ্যে পরিচিত মনে হয় এবং নতুন ঠিকাদার একটি বিকেলে অনবোর্ড হন। তারা যে গভীর ফোল্ডার শ্রেণিবিন্যাস এখনো লাগে না তা প্রতিরোধ করে, ট্রি এক নজরে স্ক্যান করার মতো সমতল রাখে। খরচ ছিল সেটআপের একটি বিকেল, এবং তা তাদের সেই স্নোফ্লেক ছড়াছড়ি থেকে বাঁচায় যা অন্যথায় প্রতিটি ভবিষ্যৎ রিপোকে একটি ছোট গবেষণা প্রকল্প করত।
এন্টারপ্রাইজ। একটি বহুজাতিক খুচরা বিক্রেতা কয়েকটি ভাষা জুড়ে শত শত সার্ভিস চালায়। এর প্ল্যাটফর্ম দল একটি ভার্সনযুক্ত রিপজিটরি-কাঠামো মান এবং তা বাস্তবায়নকারী প্রকল্প টেমপ্লেটের সেট প্রকাশ করে। প্রতিটি নতুন সার্ভিস একটি টেমপ্লেট থেকে তৈরি হয়, তাই তা প্রমিত src, test, docs, deploy ও scripts ফোল্ডার, একটি পূর্ণ README, একটি .editorconfig, উপেক্ষা ফাইল এবং একটি কার্যকর CI পাইপলাইন নিয়ে আসে। প্রতিটি রিপজিটরি একই রকম দেখায় বলে নতুন দলে বদলি হওয়া ইঞ্জিনিয়ার ঘণ্টার মধ্যে উৎপাদনশীল হন, এবং প্রতিষ্ঠানজোড়া নিরাপত্তা ও নির্ভরতা স্ক্যানার অভিন্নভাবে চলে কারণ তারা সবসময় ফাইল প্রত্যাশিত জায়গায় পায়।
সরকার। পুরোনো সিস্টেম আধুনিকায়ন করা একটি জাতীয় সংস্থা সব বিক্রেতার জন্য তার সরবরাহ মানের অংশ হিসেবে একটি সাধারণ রিপজিটরি বিন্যাস বাধ্যতামূলক করে। প্রতিটি রিপজিটরিতে থাকতে হবে কোডকে অনুমোদিত প্রয়োজনীয়তায় যুক্ত করা একটি specification ফোল্ডার, একটি নথিবদ্ধ README, মূলে একটি লাইসেন্স ও নিরাপত্তা-নীতি ফাইল, এবং অবকাঠামো-অ্যাজ-কোড সংজ্ঞা (অধ্যায় 8.2) ধারণকারী একটি deploy ফোল্ডার। ভিন্ন বিক্রেতার ঠিকাদাররা সবাই একই কাঠামো অনুসরণ করে বলে সংস্থার নিরীক্ষকরা প্রতিটি সিস্টেমে বিধি-মান্যতা সামগ্রী একইভাবে খুঁজে পান, এবং চুক্তি শেষ হওয়ার পর দীর্ঘমেয়াদি রক্ষণাবেক্ষণ অনেক কম খরচ করে কারণ আগত রক্ষণাবেক্ষকরা ইতিমধ্যে মানচিত্র জানেন।
ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO
কাঠামো মান গ্রহণের খরচ মূলত এককালীন: বিন্যাসে একমত হওয়া, টেমপ্লেট গড়া এবং রীতি নথিবদ্ধ করা। পুনরাবৃত্ত খরচ কম, টেমপ্লেট রক্ষণাবেক্ষণ ও ব্যতিক্রম নিয়ন্ত্রণে কেন্দ্রীভূত। মান না থাকার খরচ পুনরাবৃত্ত ও চক্রবৃদ্ধি: অপরিচিত রিপো খোলা প্রতিটি ইঞ্জিনিয়ার নেভিগেশন কর দেন, প্রতিটি অনবোর্ডিং ধীরে চলে, এবং স্বয়ংক্রিয় টুলিংকে প্রতি-রিপো কনফিগার করতে হয় কারণ কিছুই প্রত্যাশিত জায়গায় নেই। একটি বড় প্রতিষ্ঠান জুড়ে এই ছোট ঘর্ষণগুলো গুণ হয়ে প্রকৌশল সময়ের গুরুতর ক্ষতিতে দাঁড়ায়।
প্রতিদান দেখা দেয় দ্রুততর অনবোর্ডিং, দলগুলোর মধ্যে সস্তা গতিশীলতা, পোর্টফোলিওজোড়া টুলিং থেকে উচ্চতর সংকেত, এবং নিয়ন্ত্রিত পরিবেশে কম অডিট ও দীর্ঘমেয়াদি-রক্ষণাবেক্ষণের খরচে, কারণ সামগ্রী সবসময় খুঁজে-পাওয়া-যায়। মালিকানার মোট খরচ (TCO, অর্থাৎ একটি সিস্টেম গড়া, চালানো ও রক্ষণাবেক্ষণের পূর্ণ আজীবন খরচ) সবচেয়ে বেশি কমে দীর্ঘজীবী সিস্টেমে, যেখানে পূর্বানুমেয় কাঠামো থেকে উপকৃত রক্ষণাবেক্ষকরা সাধারণত তার রচয়িতা নন। নেতৃত্বের কাছে যুক্তি দিতে কাঠামোকে ডেভেলপার উৎপাদনশীলতা ও অডিট-প্রস্তুতি উন্নত করা কম-খরচের, উচ্চ-লিভারেজ মান হিসেবে উপস্থাপন করুন, এবং অনবোর্ডিং-সময়ের তথ্য ও অপরিচিত রিপজিটরিতে জিনিস খুঁজতে ব্যয় হওয়া পরিশ্রম ব্যবহার করে আজকের অসামঞ্জস্যের খরচের একটি সংখ্যা দিন।
অ্যান্টি-প্যাটার্ন ও ফাঁদ
- স্নোফ্লেক রিপজিটরি: প্রতিটি রিপো ভিন্নভাবে সংগঠিত, তাই প্রতিটি শূন্য থেকে নতুন করে শিখতে হয়।
- অনুপস্থিত বা সেকেলে README: কোনো সামনের দরজা নেই, নবাগতদের প্রকল্প কীভাবে গড়তে ও চালাতে হয় তা রিভার্স-ইঞ্জিনিয়ার করতে বাধ্য করে।
- টেমপ্লেটের বদলে দলিলে কাঠামো: একটি উইকি পাতা প্রমিত বিন্যাস বর্ণনা করে, কিন্তু কিছুই তা তৈরি বা বলবৎ করে না, তাই বাস্তবতা তা থেকে সরে যায়।
- টেমপ্লেটের বিচ্যুতি: টেমপ্লেট থেকে তৈরি রিপজিটরি সময়ের সঙ্গে আলাদা হয় এবং টেমপ্লেটের উন্নতি কখনো তাদের কাছে পৌঁছায় না।
- অতি-প্রকৌশলী শ্রেণিবিন্যাস: প্রায়-ফাঁকা ফোল্ডারের গভীর নেস্ট, যা নেভিগেশনে সাহায্য না করে আনুষ্ঠানিকতা যোগ করে।
- মিশ্র উদ্বেগ: সোর্স, টেস্ট, বিল্ড আউটপুট ও গোপন তথ্য স্পষ্ট বিচ্ছিন্নতা ছাড়া জট পাকানো।
- কমিট করা বিল্ড আউটপুট ও স্থানীয় সামগ্রী: উপেক্ষার নিয়ম কখনো ঠিক করা হয়নি বলে চেক-ইন হওয়া তৈরি ফাইল, ইতিহাস ও ডিফ দূষিত করে।
- সমতল কাঠামোর আড়ালে স্তর লঙ্ঘন: কোনো ভৌত সীমানা নেই, তাই নির্ভরতার চক্র ও অনুপযুক্ত সংযুক্তি অলক্ষ্যে ঢোকে।
পরিপক্বতা মডেল
- স্তর ১ (সূচনা): প্রতিটি রিপজিটরি তার রচয়িতাদের দ্বারা তাৎক্ষণিকভাবে সংগঠিত, মুহূর্তের প্রয়োজনে প্রতিক্রিয়া জানিয়ে; বিন্যাস ব্যাপকভাবে ভিন্ন; README অনুপস্থিত বা অনির্ভরযোগ্য; নবাগতদের প্রতিটি রিপো হাতে হাতে ঘুরিয়ে দেখাতে হয়।
- স্তর ২ (বিকাশ): মৌলিক রীতি অনানুষ্ঠানিকভাবে আছে এবং বহু রিপো একে অপরের মতো দেখায়; কিছু দল নিজস্ব শুরুর বিন্যাস রাখে; কিন্তু কোনো প্রামাণ্য মান, ভাগ করা স্ক্যাফোল্ডিং নেই, এবং কাঠামো এক দল থেকে অন্যটিতে লক্ষণীয়ভাবে বিচ্যুত।
- স্তর ৩ (মানসম্মতকরণ): একটি নথিবদ্ধ, ভার্সনযুক্ত কাঠামো মান প্রতিষ্ঠানজুড়ে বলবৎ; নতুন রিপজিটরি একটি প্রমিত বিন্যাস, README, কনফিগারেশন ফাইল ও CI বহনকারী ভাগ করা টেমপ্লেট থেকে তৈরি; বিচ্যুতি নিঃশব্দে ঘটার বদলে নথিবদ্ধ ব্যতিক্রম প্রক্রিয়ায় যায়।
- স্তর ৪ (ব্যবস্থাপনা): মানের সঙ্গে সামঞ্জস্য তথ্য দিয়ে মাপা ও নিয়ন্ত্রিত: স্বয়ংক্রিয় পরীক্ষা জানায় রিপোর কত অংশ বিন্যাসের সঙ্গে মেলে, টেমপ্লেট-করা রিপো কতটা বিচ্যুত, README-র সম্পূর্ণতা, এবং নির্ভরতা-দিকের লঙ্ঘন, সবই ভিত্তিরেখার বিপরীতে অনুসরণ করা; অনবোর্ডিং ও নেভিগেশনের সময় মাপা; ব্যতিক্রম লগ ও পর্যালোচিত, এবং টেমপ্লেট পরিবর্তন মতামতের বদলে প্রমাণের ভিত্তিতে অনুমোদিত।
- স্তর ৫ (সমন্বয়): কাঠামো নিরন্তর উন্নত ও অভিযোজিত: টেমপ্লেটের উন্নতি বিদ্যমান রিপজিটরিতে স্বয়ংক্রিয়ভাবে ছড়ায়, কাঠামো গভর্নেন্স নিরাপত্তা, বিধি-মান্যতা ও প্ল্যাটফর্ম টুলিংয়ের সঙ্গে একীভূত, এবং ভাষা, স্থাপত্য ও পোর্টফোলিও সরলে মান সুচিন্তিতভাবে বিবর্তিত হয়, প্রতিষ্ঠান চারপাশে বদলালেও অভিন্নতা উচ্চ রেখে।
আলোচনার ভাবনা
- আপনার প্রতিষ্ঠান জুড়ে কোন শীর্ষ-স্তরের ফোল্ডার সত্যিই সার্বজনীন হওয়া উচিত, আর কোনগুলো ঐচ্ছিক?
- টেমপ্লেট থেকে তৈরি রিপজিটরিকে সময়ের সঙ্গে তা থেকে সরে যাওয়া থেকে কীভাবে ঠেকাবেন?
- সহায়ক স্তরবিন্যস্ত শ্রেণিবিন্যাস আর অতি-প্রকৌশলী ফোল্ডার আনুষ্ঠানিকতার মধ্যে রেখা কোথায়?
- আপনার কাঠামো মান মনোরিপো ও বহু-রিপো পদ্ধতির মধ্যে, যদি থাকে, কীভাবে আলাদা হওয়া উচিত?
- যে প্রকল্পের প্রকৃত প্রয়োজন প্রমিত বিন্যাসে খাপ খায় না তার জন্য সঠিক ব্যতিক্রম প্রক্রিয়া কী?
- আপনার কাঠামোর কতটা স্বয়ংক্রিয়ভাবে যাচাই করা যায়, এবং কী এখনো মানুষের রিভিউয়ের ওপর নির্ভর করে?
- কাঠামো মান ও তার টেমপ্লেটের মালিক কে, এবং পরিবর্তন কীভাবে প্রস্তাবিত ও চালু হয়?
প্রধান শিক্ষা
- প্রতিটি রিপজিটরি এমনভাবে সংগঠিত করুন যাতে যেকোনো ইঞ্জিনিয়ার প্রত্যাশা অনুযায়ী যেকোনো কোডবেসে নেভিগেট করতে পারেন, ন্যূনতম বিস্ময়ের নীতি অনুসরণ করে।
- একটি সামঞ্জস্যপূর্ণ শীর্ষ-স্তরের বিন্যাস গ্রহণ করুন (সোর্স, টেস্ট, ডক, বিল্ড, ডিপ্লয়, স্ক্রিপ্ট, উদাহরণ, স্পেসিফিকেশন) এবং README-কে প্রবেশ-বিন্দু করুন।
- এডিটর ও টুলিং কনফিগারেশন (যেমন
.editorconfig) চেক-ইন করুন, যাতে রীতি কেবল লেখা নয়, সক্রিয় হয়। - স্ক্যাফোল্ডিং ও টেমপ্লেট দিয়ে কাঠামো বলবৎ করুন, যাতে নতুন রিপজিটরি ডিফল্টে সঠিক হয়।
- বড় পরিসরে মূল্য অভিন্নতায়: মান নিয়ন্ত্রণ করুন, বিচ্যুতি পরিচালনা করুন, এবং বিচ্যুতি কেবল নথিবদ্ধ ব্যতিক্রমে অনুমতি দিন।
তথ্যসূত্র ও আরও পড়ার জন্য
- Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design
- Steve McConnell, Code Complete: A Practical Handbook of Software Construction
- Andrew Hunt ও David Thomas, The Pragmatic Programmer
- Titus Winters, Tom Manshreck ও Hyrum Wright (সম্পা.), Software Engineering at Google
- Scott Chacon ও Ben Straub, Pro Git
- EditorConfig প্রকল্প ডকুমেন্টেশন (এডিটর কনফিগারেশনের রেফারেন্স মান হিসেবে)