চুক্তিগুলি সফ্টওয়্যার বিকাশের একটি অপরিহার্য অংশ। তারা উন্নয়ন খরচ কম করে এবং বিকাশকারীদের জীবনকে সহজ করে তোলে। তবে একটি সমস্যা আছে - তারা প্রায়শই জিনিসগুলিকে জটিল করে তোলে কারণ সেগুলিকে সঠিকভাবে নথিভুক্ত করা হয় না এবং পুরোনো রূপকথার মতো মুখের কথার মাধ্যমে দলকে জানানো হয় না। ছড়িয়ে পড়ার সময়, চুক্তিগুলি পরিবর্তন হয়। হঠাৎ, নতুন বিবরণ উপস্থিত হয়, এবং পুরানোগুলি চলে যায়। শেষ পর্যন্ত, প্রতিটি দলের সদস্যের মাথায় তাদের নিজস্ব চুক্তির ছবি থাকে এবং এমনকি সেই ছবিও কখনও কখনও বিবর্ণ হয়ে যায়। আরও খারাপ - যখন দলগুলি এই চুক্তিগুলিকে নথিভুক্ত করা শুরু করে, তখন তারা এটি অযৌক্তিকভাবে করে এবং প্রায়শই ঢিলেঢালাভাবে সংযুক্ত নথিগুলির একটি বিশৃঙ্খলা তৈরি করে, যার অর্ধেক এমনকি আপ টু ডেটও নয়। এই নিবন্ধে, আমি আপনাকে চুক্তি নথিভুক্ত করার বলব, যাতে তারা আপনাকে সাহায্য করবে। সঠিক উপায় তাহলে, আমরা কীভাবে চুক্তিগুলিকে সহায়ক করতে পারি? আমাদের কেবল সেগুলি নথিভুক্ত করতে হবে না তবে এটিও করতে হবে যাতে: তারা ব্যবহার করা সহজ ছিল; এই চুক্তিগুলি অনুসরণ করার জন্য ন্যূনতম প্রচেষ্টা প্রয়োজন; এই চুক্তিগুলি এখনও বৈধ কিনা তা বোঝা সহজ হবে; এই চুক্তিগুলি কেন বিদ্যমান তা বোঝা সহজ হবে; আদর্শভাবে - তারা স্বয়ংক্রিয় ছিল। চুক্তিগুলিকে শ্রেণীবদ্ধ করার অনেক উপায় নিয়ে আসতে পারে। আমি তাদের বিমূর্ততা স্তর দ্বারা বিভক্ত করব: কোড-স্তরের চুক্তি; স্থাপত্য-স্তরের চুক্তি; প্রক্রিয়া-স্তরের চুক্তি। বিভিন্ন স্তরের চুক্তির জন্য তাদের নথিভুক্ত করার জন্য এবং বিভিন্ন সুবিধা আনতে বিভিন্ন উপায় প্রয়োজন। এর প্রতিটি স্তরের একটি কটাক্ষপাত করা যাক. কোড-স্তরের কনভেনশন এই চুক্তির উদ্দেশ্য হল কোডকে ইউনিফর্ম, ব্যাপক এবং পঠনযোগ্য করে তোলা। এখানে কিছু উদাহরণঃ: আমরা একক উদ্ধৃতির পরিবর্তে ডবল উদ্ধৃতি ব্যবহার করি। আমরা ক্লাস ছাড়া কোড থেকে সরাসরি ENV-কে কল করি না, যেখানে আমরা এই কলগুলিকে পদ্ধতিতে মোড়ানো করি। Config পরিষেবা বস্তুর পোস্টফিক্স এবং একটি পাবলিক পদ্ধতি আছে। Service call এই ধরনের চুক্তি পাঠকের জ্ঞানীয় লোড কমাতে এবং তাকে দ্রুত অজানা কোডে অভ্যস্ত হতে সাহায্য করার জন্য তৈরি করা হয়। যেমন মার্টিন বলেছেন, কোড লেখার চেয়ে 10 গুণ বেশি পঠিত হয়। রুবি অন রেল ফ্রেমওয়ার্ক সম্পর্কে আপনার মতামত সত্ত্বেও - এটির মূল অংশে রয়েছে, যা যে কোনও রেল বিকাশকারীকে অন্য কারও প্রকল্প খুলতে এবং অবিলম্বে এটিকে বেশ ভালভাবে নেভিগেট করতে দেয়। convention over configuration সুতরাং কিভাবে এই নিয়মাবলী নথি? লিন্টার টুল! কোন উপযুক্ত লিন্টার নিয়ম না থাকলে, আপনার নিজের লিন্ট লিখুন। প্রায় প্রতিটি লিন্টার আপনাকে এটি করার অনুমতি দেয়: এখানে একটি উদাহরণ রয়েছে এবং এখানে এর জন্য। Go ভাষায় Ruby এই ধরনের কনভেনশনের জন্য লিন্টার ব্যবহার করা আপনার তিনটি সুবিধা নিয়ে আসে: তাদের সম্পর্কে চিন্তা করার জন্য কোনও বিকাশকারীর প্রয়োজন নেই - লিন্টার প্রতিটি ত্রুটি হাইলাইট করবে এবং প্রায়শই সেগুলি আপনার জন্য ঠিক করে দেবে। আপনি যদি আপনার দলে কোড রিভিউ ব্যবহার করেন - আপনি আপনার পর্যালোচকদের এই জিনিসগুলি সম্পর্কে চিন্তা করা থেকে মুক্ত করেন এবং আরও গুরুত্বপূর্ণ বিষয়গুলি দেখার জন্য তাদের আরও সময় দেন। বিকাশকারী বিকাশ চক্রের একেবারে শুরুতে একটি সমস্যা দেখতে পাবেন, তাই তিনি পরে প্রসঙ্গে ফিরে আসার জন্য সময় ব্যয় না করে অবিলম্বে এটি ঠিক করবেন। চুক্তি রাখা সস্তা হয়ে যায়। আরও একটি বোনাস: একটি নতুন লিন্টার নিয়ম লেখা একটি জুনিয়র ডেভেলপারের জন্য চমৎকার প্রশিক্ষণ। এই কাজটি সম্পন্ন করার সময়, তিনি কোড পার্সিং এবং এএসটি নির্মাণ সম্পর্কে অনেক কিছু শিখবেন এবং ভাষা আরও গভীরভাবে বুঝতে পারবেন। স্থাপত্য-স্তরের সম্মেলন এটি একটি উচ্চ-স্তরের চুক্তি যার লক্ষ্য আপনার স্থাপত্যকে চিন্তাশীল, সুসঙ্গত এবং অভিন্ন করে তোলা। কয়েকটি উদাহরণ: আমরা সিস্টেমের হাইলোড করা অংশগুলিতে নিয়মিত পরিষেবা এবং এলিক্সির লিখতে পাইথন ব্যবহার করি। ব্যাকএন্ড বর্ণিত বিন্যাসে ত্রুটি প্রদান করে। প্রমিথিউসে মেট্রিক্স পাঠাতে প্রতিটি পরিষেবার প্রয়োজন হয়, এন্ডপয়েন্টে, মেট্রিক্স পাঠানোর পোর্টটি পরিবেশ পরিবর্তনশীল দ্বারা কনফিগার করা হয়। /metrics PROMETHEUS_PORT এই ধরনের চুক্তি শুধুমাত্র জ্ঞানীয় লোড কমায় না, বরং আরও তিনটি সমস্যার সমাধান করে: অপারেটিং খরচ কমানো. যদি পরিষেবাগুলি একই ভাবে চালু করা হয়, একই লগ ফর্ম্যাটে, একই মেট্রিক্স প্রকাশ করে, তাহলে পরিষেবাটি বজায় রাখা এবং ঘটনাগুলি মোকাবেলা করা অনেক সহজ। ডিজাইন খরচ কমান. বিকাশকারীকে প্রতিবার স্ক্র্যাচ থেকে আর্কিটেকচার ডিজাইন করার দরকার নেই - আপনি আগে থেকেই ভেবেছিলেন, এবং এখন তাকে মৌলিক বিষয়গুলি নিয়ে চিন্তা না করে শুধুমাত্র একটি নির্দিষ্ট বৈশিষ্ট্য বা পরিষেবা ডিজাইন করতে হবে। যোগাযোগ খরচ কমান. যদি কাফকাতে সার্ভারের প্রতিক্রিয়া বা ইভেন্ট বিন্যাস পূর্বনির্ধারিত থাকে, তবে বিকাশকারীদের প্রতিবার তাদের মিথস্ক্রিয়া নিয়ে আলোচনা করার দরকার নেই, পরিবর্তে তারা কেবল কনভেনশনটি উল্লেখ করতে পারে। এই ধরনের চুক্তিগুলি আরও জটিল, এবং আমি সেগুলিকে দুটি ধাপে ঠিক করতে পছন্দ করি৷ ধাপ 1 - বর্ণনা করুন আর্কিটেকচার ডিসিশন রেকর্ড (ADR) এই ধরনের চুক্তি নথিভুক্ত করার জন্য একটি হাতিয়ার। এর আকর্ষণ হল এটি একটি চুক্তির সাথে মেটা তথ্য ক্যাপচার করে: কেন এমন একটি চুক্তি গৃহীত হয়েছিল; কি বিকল্প আলোচনা করা হয়েছে; যখন এটি সর্বশেষ সংশোধিত হয়েছিল; চুক্তি এখনও বৈধ? এটি নতুন দলের সদস্যকে সিদ্ধান্ত নেওয়ার কারণগুলি বুঝতে এবং এটি সম্পর্কে আশেপাশের লোকদের জিজ্ঞাসা না করার অনুমতি দেয়। ADR কয়েকটি প্রধান ব্লক নিয়ে গঠিত: চুক্তি কোন সমস্যা সমাধান করে? সমস্যা সমাধানের জন্য কোন বিকল্পগুলি বিবেচনা করা হয়েছিল এবং তাদের সুবিধা এবং অসুবিধাগুলি কী ছিল? শেষ পর্যন্ত কোন বিকল্পটি বেছে নেওয়া হয়েছিল? অতিরিক্ত ব্লক হতে পারে - উদাহরণস্বরূপ, বাস্তবায়ন খরচ গণনা। ADR কে এমন একটি সিস্টেমে রাখা আরও সুবিধাজনক যেখানে কেউ পরিবর্তন এবং আলোচনার ইতিহাস দেখতে পারে। আমার পছন্দ হল Github এবং Notion, প্রত্যেকেরই তার ভালো-মন্দ। Github এর সুবিধা হল এটি একটি পর্যালোচনা টুল এবং বাক্সের বাইরে সংস্করণ ইতিহাস আছে। ডেটাবেস এবং ট্যাগগুলির সাথে কাজ করার সুবিধার কারণে ধারণা একটি ভাল সমাধান হতে পারে। এবং এছাড়াও - নন-ডেভেলপাররা সহজেই এটি পরিচালনা করতে পারে। আপনি যদি ADR এর সাথে শুরু করতে চান, আমি দেখার পরামর্শ দিচ্ছি, যেখানে আপনি বিভিন্ন ADR টেমপ্লেট এবং কীভাবে সেগুলি ব্যবহার করবেন তার উদাহরণগুলি খুঁজে পেতে পারেন৷ সংগ্রহস্থলটি ধাপ 2 - স্বয়ংক্রিয় কোড-স্তরের কনভেনশনের চেয়ে ADR-গুলি স্বয়ংক্রিয়ভাবে করা আরও চ্যালেঞ্জিং: ডিজাইন লিন্টারগুলি এখনও উদ্ভাবিত হয়নি (কী দুঃখের বিষয়!) তা সত্ত্বেও, এটা কি ধরনের চুক্তির উপর নির্ভর করে আংশিকভাবে তাদের স্বয়ংক্রিয় করা সম্ভব। ভাষা, লাইব্রেরি, এবং পরিকাঠামোতে এম্বেডিং পরিষেবাগুলির চুক্তির জন্য পরিষেবা টেমপ্লেট তৈরি এবং আপডেট করুন। তারপরে বিকাশকারী স্ক্র্যাচ থেকে নতুন পরিষেবাগুলি লিখবেন না বরং টেমপ্লেট থেকে এটি অনুলিপি করবেন এবং অবিলম্বে কনফিগার করা ডকারফাইল, মেট্রিক্স প্রকাশনা ইত্যাদি পাবেন৷ একইভাবে, আপনি একটি অ্যাপ্লিকেশনের মধ্যে ক্লাস জেনারেটর তৈরি করতে পারেন। ধরুন আপনি বেশ কয়েকটি অ্যাপ্লিকেশন স্তরে সম্মত হয়েছেন (কন্ট্রোলার => ফর্ম => পরিষেবা বস্তু)। সেই ক্ষেত্রে, আপনি একটি সাধারণ কনসোল কমান্ড তৈরি করতে পারেন যা একবারে একটি নতুন বৈশিষ্ট্যের জন্য সমস্ত স্তর তৈরি করবে। আপনি যদি এমন কিছু নীতিতে সম্মত হন যা এইভাবে স্বয়ংক্রিয় হতে পারে না, আপনি চেকলিস্টগুলি সংগঠিত করতে পারেন যা স্বয়ংক্রিয়ভাবে একটি মার্জ অনুরোধে বা ট্র্যাকারে একটি টাস্কে যুক্ত হয়; এইভাবে, বিকাশকারী কাজটি পাস করার আগে দ্রুত তাদের মাধ্যমে যেতে পারে। প্রক্রিয়া-স্তরের চুক্তি প্রতিটি কোম্পানিতে প্রক্রিয়ার জন্য অনেক চুক্তি আছে, উদাহরণস্বরূপ: কোম্পানিতে নিয়োগ কিভাবে কাজ করে তার বর্ণনা। রিলিজ রোলআউট প্রক্রিয়ার বিবরণ। বড় কাজের জন্য ডিজাইন পর্যালোচনার জন্য প্রয়োজনীয়তা। বর্তমান কাজ এবং প্রতিবন্ধকতা নিয়ে আলোচনা করে সপ্তাহে দুবার টিম মিটিং করা। সম্প্রতি অবধি, আমি এই চুক্তিগুলি নথিভুক্ত করার বিষয়ে ভাবিনি, যদিও তারা উল্লেখযোগ্যভাবে কোম্পানির সাফল্যকে প্রভাবিত করে। এই চুক্তিগুলির ডকুমেন্টেশন শুধুমাত্র উপরে উল্লিখিত প্রকারের সুবিধা বহন করে না বরং আপনাকে প্রক্রিয়াগুলিকে যুক্তিযুক্ত করতে, তাদের দৃশ্যমান সমতলে স্থানান্তর করতে এবং তাদের সুবিধার বিষয়ে চিন্তা করার অনুমতি দেয়। আমি থেকে ধারণা পেয়েছিলাম. তিনি এডিআর-প্রসেস ডিসিশন রেকর্ড (পিডিআর) এর অনুরূপ একটি টুল প্রস্তাব করেছিলেন। শুধুমাত্র পার্থক্য হল যে স্থাপত্য সিদ্ধান্তের পরিবর্তে, এটি প্রক্রিয়া সম্পর্কে সিদ্ধান্তগুলি বর্ণনা করে। উপরন্তু, তিনি প্রতিটি পিডিআর-এ একটি "পুনর্বিবেচনার তারিখ" রাখার পরামর্শ দিয়েছেন - একটি তারিখ যখন আপনি দস্তাবেজে ফিরে আসবেন তা দেখতে এটি এখনও আপনার সমস্যাগুলি সবচেয়ে ভাল উপায়ে সমাধান করে কিনা, দত্তক নেওয়ার মাস পরে (যাইহোক, একই কাজ করা যেতে পারে) ADR সহ)। Vitaly Sharovatov n অটোমেশনের জন্য, আপনি খুব কমই করতে পারেন। আপনি জিরাতে একটি ওয়ার্কফ্লো সেট আপ করে, মিটিংয়ের জন্য অনুস্মারক সেট করে বা এমন একটি বট তৈরি করে যা স্বয়ংক্রিয়ভাবে সপ্তাহের ফলাফলের একটি উপস্থাপনা প্রস্তুত করে কিছু প্রক্রিয়া স্বয়ংক্রিয় করতে পারেন (যদিও আমি এটি একটি বিদেশী কোম্পানিতে করেছি)। কিন্তু প্রায়ই, আপনি সত্যিই প্রক্রিয়াগুলি স্বয়ংক্রিয় করতে পারবেন না এবং আপনার প্রধান লক্ষ্য হল অনুসরণ না করার চেয়ে অনুসরণ করা সহজ করে তোলা। তবুও, নথিভুক্ত চুক্তিগুলি এখনও সহায়ক হবে, এমনকি যদি আপনার প্রক্রিয়াগুলি ইতিমধ্যেই অনুসরণ করা সহজ হয় - আনুষ্ঠানিকীকরণ এবং যৌক্তিককরণ আপনাকে সেগুলি উন্নত করতে অনুমতি দেবে। সুতরাং, ফলাফল কি? ডকুমেন্টেশন এবং পরবর্তী অটোমেশন উপকারী: বিকাশে ব্যয় করা সময় হ্রাস পায়, অ্যাপ্লিকেশনগুলি আরও সমর্থনযোগ্য হয়ে ওঠে এবং প্রক্রিয়াগুলি আরও স্মার্ট হয়ে ওঠে। কেউ ভাবতে পারে যে এই সবই অপ্রয়োজনীয় আমলাতন্ত্র কারণ "আমরা ভাল ছেলে - আমরা এটি ছাড়াই কোড বিকাশ করতে পারি।" কিন্তু প্রকৃতপক্ষে, চুক্তিগুলি আপনাকে যথেষ্ট পরিমাণে সময় এবং অর্থ সাশ্রয় করবে এবং কর্মীদের স্নায়ু কোষগুলিকে রক্ষা করবে। অবশ্যই, চুক্তির বিরুদ্ধে যায় এমন কোনো কিছুকে নিরঙ্কুশভাবে মোকাবেলা করার এবং প্রত্যাখ্যান করার প্রয়োজন নেই - এটি একটি চিহ্ন হতে পারে যে চুক্তিটি আপডেট করা দরকার বা আপনি প্রাথমিকভাবে এর কিছু দিক সম্পর্কে ভাবেননি। আপনি যদি এখনও আপনার দলে চুক্তির নথিভুক্ত করা শুরু না করে থাকেন, তাহলে নিম্ন বিমূর্ত স্তর থেকে উচ্চতর স্তরে যান: কোড-স্তরের চুক্তি থেকে শুরু করুন, তারপরে আর্কিটেকচার-স্তর, এবং শুধুমাত্র তারপর প্রক্রিয়া-স্তরের সাথে মানিয়ে নিন। চুক্তির ডকুমেন্টেশন আপনার দলে বিকাশ করার একটি অভ্যাস, এবং কম বিমূর্ত ধারণা দিয়ে শুরু করা অনেক সহজ। উপরন্তু, নিবন্ধে সব ধরনের বর্ণনা করা হয় না। উদাহরণস্বরূপ, আপনি লাইব্রেরি উপাদান হিসাবে নকশা চুক্তি নথিভুক্ত করতে পারেন। প্রতিটি নতুন ধরনের চুক্তি একই তিনটি পর্যায়ে যায়: এটি কিভাবে নথিভুক্ত করা যায় তা বের করুন। এটি কিভাবে স্বয়ংক্রিয় করতে হয় তা বের করুন। সময় অতিবাহিত হওয়ার সাথে সাথে নিশ্চিত করুন যে এটি রাখার জন্য যতটা লাগে তার চেয়ে বেশি সংস্থান সংরক্ষণ করে। এবং সর্বশেষটি. ডকুমেন্টেশন প্রক্রিয়া চলাকালীন, এটি পাওয়া যেতে পারে যে কিছু বিদ্যমান চুক্তি দৃশ্যত, কোন কিছুর দ্বারা ন্যায়সঙ্গত নয়, আপনার দলের সময় নষ্ট করে, এবং সাধারণত ক্ষতিকারক, কিন্তু আপনি ইতিমধ্যেই তাদের অভ্যস্ত। এই ক্ষেত্রে, আপনাকে দলের মনের অভ্যাসের বাধা অতিক্রম করতে হবে এবং আপনার দলকে বোঝাতে হবে যে চুক্তিগুলিকে প্রত্যাখ্যান করা কখনও কখনও তাদের গ্রহণ করার চেয়ে বেশি গুরুত্বপূর্ণ। কিন্তু এটা সম্পূর্ণ ভিন্ন গল্প। এছাড়াও প্রকাশিত. এখানে
