স্টিল থ্রেড একটি শক্তিশালী কিন্তু অস্পষ্ট সফ্টওয়্যার ডিজাইন পদ্ধতি। স্টিল থ্রেডস সম্পর্কে শেখা আপনাকে আরও ভাল ইঞ্জিনিয়ার করে তুলবে। আপনি একীকরণ ব্যথা মত সাধারণ সমস্যা এড়াতে তাদের ব্যবহার করতে পারেন. এবং আপনি সিস্টেম ডিজাইনের জটিলতা কাটাতে সেগুলি ব্যবহার করতে পারেন।
ইস্পাত থ্রেড কতটা অজানা? ধারণাটি 2013 সালে উইকিপিডিয়া থেকে মুছে ফেলা হয়েছিল কারণ "ধারণাটি সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের মধ্যে উল্লেখযোগ্য নয় এবং উল্লেখযোগ্য উত্স থেকে উল্লেখযোগ্য কভারেজ পায়নি।" এর কভারেজ যোগ করা যাক, এবং কেন এটি একটি দরকারী পদ্ধতির মাধ্যমে কথা বলুন.
একটি ইস্পাত থ্রেড কার্যকারিতার একটি খুব পাতলা স্লাইস যা একটি সফ্টওয়্যার সিস্টেমের মাধ্যমে থ্রেড করে। এগুলিকে "থ্রেড" বলা হয় কারণ তারা সফ্টওয়্যার সিস্টেমের বিভিন্ন অংশের মাধ্যমে বুনন করে এবং একটি গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে প্রয়োগ করে।
এগুলিকে "স্টিল" বলা হয় কারণ থ্রেডটি পরবর্তী উন্নতির জন্য একটি শক্ত ভিত্তি হয়ে ওঠে।
একটি স্টিল থ্রেড পদ্ধতির সাহায্যে, আপনি সম্ভাব্য পাতলা সংস্করণ তৈরি করেন যা সিস্টেমের সীমানা অতিক্রম করে এবং একটি গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে কভার করে।
ধরা যাক আপনি আপনার একচেটিয়া কোডবেসের একটি অংশ প্রতিস্থাপন করতে একটি নতুন পরিষেবা তৈরি করছেন৷ এটি করার সবচেয়ে সাধারণ উপায় হবে
পুরানো কোড দেখুন, এবং নতুন সিস্টেমের প্রয়োজনীয়তা খুঁজে বের করুন।
আপনার প্রয়োজনীয় ক্ষমতা প্রদান করে এমন API গুলি ডিজাইন এবং তৈরি করুন৷
পুরানো কোডে যান এবং নতুন API ব্যবহার করতে রেফারেন্স আপডেট করুন। একটি বৈশিষ্ট্য পতাকা পিছনে এটি করুন.
বৈশিষ্ট্য পতাকা ব্যবহার করে কাটা উপর.
এটি কাজ না করা পর্যন্ত আসা যে কোনও সমস্যা সমাধান করুন, পুরানো কোডের পথে ফিরে যেতে প্রয়োজন হলে বৈশিষ্ট্য পতাকাটি বন্ধ করে দিন।
এটি স্থিতিশীল হলে, পুরানো কোড পাথগুলি সরান।
যুক্তিসঙ্গত শোনাচ্ছে, তাই না? ঠিক আছে, এটি সফ্টওয়্যার ইঞ্জিনিয়ারদের কাজ করার সবচেয়ে সাধারণ উপায়, তবে এই পদ্ধতিতে প্রচুর ল্যান্ডমাইন রয়েছে।
আমি এই প্রকল্পে কি সমস্যা আশা করব?
পুরানো সিস্টেম থেকে সংযোগ বিচ্ছিন্নভাবে নতুন পরিষেবা তৈরি করা আবেদনময় হতে পারে। সব পরে, নকশা বিশুদ্ধ মনে হতে পারে. কিন্তু আপনি উল্লেখযোগ্যভাবে আরও কাঠামোগত পরিবর্তনও প্রবর্তন করছেন, এবং আপনি পুরানো সিস্টেমের সাথে কোনো একীকরণ ছাড়াই এই পরিবর্তনগুলি করছেন। এটি একীকরণের ব্যথা উল্লেখযোগ্যভাবে বৃদ্ধি করে। আমার প্রত্যাশা হবে যে প্রকল্পের জন্য সমস্ত অনুমান অবাস্তব। এবং আমি আশা করি যে প্রকল্পটি সম্পূর্ণ হওয়ার পরে একটি ব্যর্থতা হিসাবে বিবেচিত হবে, এমনকি ফলাফলের পরিষেবাটির সাধারণভাবে ভাল নকশা থাকলেও।
আমি আশা করব নতুন সিস্টেমে সুইচওভার সমস্যাযুক্ত হবে। আপনি সুইচ ওভার করার সাথে সাথে অনেকগুলি সমস্যা উন্মোচিত হবে যার জন্য পুরানো কোড পাথগুলিতে ফিরে যেতে হবে বা প্রকল্পের চূড়ান্ত পর্যায়ে সমস্যাগুলি সমাধান করার জন্য তীব্রভাবে কাজ করতে হবে।
এই দুটি জিনিসই এড়ানো যায়, বিশাল কাটওভার না করে। মনে রাখবেন যে ফিচার ফ্ল্যাগ সহ নতুন পরিষেবাতে এক শতাংশের বেশি ট্রাফিক কাটাও একটি কাটওভার পদ্ধতি। কেন? আপনি একই সময়ে সমস্ত পরিবর্তনের জন্য সমস্ত এক শতাংশ ট্রাফিক কমিয়ে দিচ্ছেন।
আমি এখনও এটি ভাল যেতে আশা করব না. আপনি অনেক বড় পদক্ষেপ নিচ্ছেন।
এটি করার ইস্পাত থ্রেড উপায় সঙ্গে যে পদ্ধতির বৈসাদৃশ্য.
আপনি যে নতুন সিস্টেম তৈরি করছেন সে সম্পর্কে চিন্তা করুন। সিস্টেমের স্টিল থ্রেডের প্রতিনিধিত্ব করে এমন কিছু সংকীর্ণ ব্যবহারের কেস নিয়ে আসুন - তারা সিস্টেমে দরকারী কার্যকারিতা কভার করে, তবে সমস্ত ব্যবহারের ক্ষেত্রে পরিচালনা করে না বা কিছু উপায়ে সীমাবদ্ধ থাকে।
একটি প্রারম্ভিক ব্যবহারের ক্ষেত্রে চয়ন করুন যা যতটা সম্ভব সংকীর্ণ যা কিছু মান প্রদান করে। উদাহরণস্বরূপ, আপনি একটি API বেছে নিতে পারেন যা আপনি নতুন পরিষেবার অংশ হবে বলে মনে করেন।
একটি নতুন পরিষেবাতে নতুন API তৈরি করুন।
শুধু যে সংকীর্ণ ব্যবহারের ক্ষেত্রে এটি কাজ করুন. অন্য কোন ব্যবহারের ক্ষেত্রে, পুরানো কোড পাথ ব্যবহার করুন। এটি উৎপাদনের জন্য এবং সম্পূর্ণ ব্যবহারের মধ্যে পান। (টিপ: আপনি এমনকি নতুন এবং পুরানো কোড পাথ উভয়ই করতে পারেন এবং তুলনা করতে পারেন!)
তারপরে আপনি ধীরে ধীরে অতিরিক্ত ব্যবহারের ক্ষেত্রে যোগ করুন, যতক্ষণ না আপনি আপনার প্রয়োজনীয় সমস্ত কার্যকারিতা নতুন পরিষেবাতে স্থানান্তরিত করছেন। প্রতিটি ব্যবহারের ক্ষেত্রে উত্পাদন হয়.
একবার আপনার হয়ে গেলে, আপনি পুরানো কোড এবং বৈশিষ্ট্য ফ্ল্যাগগুলি ছিঁড়ে ফেলবেন। এটি মোটেও ঝুঁকিপূর্ণ নয়, যেহেতু আপনি ইতিমধ্যেই নতুন সিস্টেমে চলছেন৷
এটাও কি “অবরোধকারী” প্যাটার্ন নয়? হ্যাঁ, তবে এটি নতুন প্রকল্পের জন্যও ব্যবহার করা যেতে পারে। একটি গ্রিনফিল্ড উদাহরণ জন্য পড়ুন.
ইন্টিগ্রেশন ব্যথা প্রকল্পের শেষ মুহূর্তের সমস্যার একটি বড় কারণ। আপনি যখন একটি নতুন সিস্টেমে কাটাচ্ছেন, আপনি সর্বদা এমন সমস্যাগুলি খুঁজে পাবেন যা আপনি আশা করেন না। কাট-ওভার জড়িত এমন যেকোনো বিষয়ে আপনার সন্দেহ হওয়া উচিত। ছোট ইনক্রিমেন্টে কাজ করুন.
স্টিল থ্রেডগুলি শুরু থেকেই একীভূত হয়, তাই আপনার কখনই একীকরণের অনেক কষ্ট হয় না। পরিবর্তে, আপনি ছোট একীকরণ ব্যথা আছে, সব পথ বরাবর.
এছাড়াও, আপনার পরিষেবাটি লাইভ হওয়ার আগে কখনও পরীক্ষা করার দরকার নেই, কারণ আপনি এটিকে ক্রমবর্ধমানভাবে পরীক্ষা করেছেন, পথে। আপনি জানেন যে এটি উত্পাদন লোড পরিচালনা করতে পারে। আপনি ইতিমধ্যে নেটওয়ার্ক লেটেন্সি যোগ করেছেন, তাই আপনি এর প্রভাব জানেন৷
সমস্ত চমক এগিয়ে নিয়ে যাওয়া হয়, এবং ক্রমবর্ধমানভাবে পরিচালনা করা হয়, যেভাবে আপনি ধীরে ধীরে পরিষেবাটি চালু করেন তার অংশ হিসাবে।
গুরুত্বপূর্ণ বিষয় হল আপনার একটি কার্যকরী, সমন্বিত সিস্টেম রয়েছে এবং আপনি এটিতে কাজ করার সাথে সাথে আপনি এটিকে কাজ করতে থাকবেন। এবং আপনি সময়ের সাথে এটি মাংস আউট.
আপনি যখন একটি সিস্টেম ডিজাইন করছেন, আপনার অনেক জটিলতা আছে। নতুন সিস্টেমের জন্য প্রয়োজনীয়তার একটি সেট তৈরি করা একটি চ্যালেঞ্জিং প্রচেষ্টা হতে পারে।
একটি স্টিল থ্রেড পদ্ধতি ব্যবহার করার সময়, আপনি কিছু মূল প্রয়োজনীয়তা বেছে নিন এবং সেগুলিকে এমনভাবে শব্দবন্ধ করুন যা সিস্টেমের স্তরগুলিকে কেটে দেয় এবং আপনার নকশাটি অনুশীলন করে। এটি পুরো সিস্টেমের জন্য এক ধরণের কঙ্কাল কাঠামো সরবরাহ করে।
সেই স্টিল থ্রেডের বাস্তবায়ন তখন হাড় হয়ে যায় যার উপর আরও প্রয়োজনীয়তা তৈরি করা যেতে পারে।
সুতরাং, ইস্পাত থ্রেডগুলি একটি সিস্টেমের প্রয়োজনীয়তার একটি উপসেট ।
ধরা যাক আপনি স্ল্যাকের একটি ক্লোন বাস্তবায়ন করছেন। আপনার প্রাথমিক ইস্পাত থ্রেড কিছু হতে পারে:
“যেকোন অপ্রমাণিত ব্যক্তি একটি হার্ডকোডেড অ্যাকাউন্টে একটি হার্ডকোডেড #জেনারেল রুমে একটি বার্তা পোস্ট করতে পারেন। পৃষ্ঠা রিফ্রেশের মাধ্যমে বার্তাগুলি অব্যাহত থাকে।"
এই প্রাথমিক ইস্পাত থ্রেড কতটা সীমিত তা লক্ষ্য করুন। এটি প্রমাণীকরণ, ব্যবহারকারী বা অ্যাকাউন্ট পরিচালনা করে না। এটি লেখার বার্তা পরিচালনা করে, এবং তাদের ধরে রাখে।
আপনার দ্বিতীয় স্টিল থ্রেড সিস্টেমটিকে আরও দরকারী হওয়ার দিকে নিয়ে যেতে পারে। উদাহরণস্বরূপ, আপনার কাছে একটি স্টিল থ্রেড থাকতে পারে যা বার্তা পোস্টারকে তাদের পোস্ট করা নামটি বেছে নিতে দেয়।
এই দ্বিতীয় ইস্পাত থ্রেড আসলে অনেক কিছু করেনি. আপনার কাছে এখনও প্রমাণীকরণ, অ্যাকাউন্ট বা এমনকি ব্যবহারকারীর ধারণা নেই। কিন্তু আপনি একটি চ্যাট রুম তৈরি করেছেন যা যথেষ্ট কাজ করে যে আপনি এটি ব্যবহার শুরু করতে পারেন।
এছাড়াও, মনে রাখবেন যে আপনি সিস্টেমের প্রতিটি অংশের মাধ্যমে ইস্পাত থ্রেড টাননি। কিন্তু আপনি ব্যবহারকারী এবং অ্যাকাউন্টের ধারণাগুলোকে বাদ দিয়েছেন।
মনে রাখবেন যে এই স্ল্যাক ক্লোন উদাহরণে, আপনি যে সিস্টেমটি তৈরি করছেন সে সম্পর্কে প্রাথমিক প্রতিক্রিয়া পেতে পারেন, যদিও আপনি এখনও এতটা তৈরি করেননি। ইস্পাত থ্রেড ব্যবহার করার জন্য এটি আরেকটি শক্তিশালী কারণ।
এই দুটি স্টিল থ্রেডের পরে, আপনার দল পুরো সময় চ্যাট রুম ব্যবহার করা শুরু করতে পারে। আপনার সিস্টেম ব্যবহার করে আপনার দল কতটা শিখবে সে সম্পর্কে চিন্তা করুন। এটা একটা কাজের সিস্টেম।
আপনি ব্যবহারকারী এবং অ্যাকাউন্ট সিস্টেম তৈরি করতে, সবকিছু হুক করে, এবং অবশেষে একটি চ্যাট রুম তৈরি করতে যা শিখেছেন তার সাথে তুলনা করুন।
আপনার প্রকল্পগুলি ডিজাইন করার সময় ইস্পাত থ্রেডগুলি প্রায়শই শুরু করার জন্য একটি ভাল জায়গা। বাকি কাজের জন্য তারা একটি কঙ্কাল তৈরি করে। তারা সিস্টেমের মূল অংশগুলিকে পেরেক দিয়ে ফেলে যাতে মাংস বের করার জন্য প্রাকৃতিক জায়গা থাকে।
আমি আপনাকে একটি স্টিল থ্রেডেড পদ্ধতির চেষ্টা করার জন্য উত্সাহিত করি। আমি মনে করি আপনি এটি আপনার প্রকল্প রূপান্তর করতে পারেন খুঁজে পাবেন. আমাকে এটার সাথে আপনার অভিজ্ঞতা জানতে দিন!
আপনি "উল্লম্ব স্লাইসিং" শব্দটি শুনে থাকতে পারেন। আমি মাইলস্টোনস- এ আমার পোস্টে ধারণাটি বর্ণনা করেছি।
স্টিল থ্রেড হল একটি সফ্টওয়্যার ডিজাইন কৌশল যা আপনার সফ্টওয়্যারকে উল্লম্ব স্লাইসে সরবরাহ করে। শব্দটি একটি সিস্টেমের প্রারম্ভিক উল্লম্ব স্লাইস বর্ণনা করতে ব্যবহার করা হয়।
তারা ঘনিষ্ঠভাবে সম্পর্কিত ধারণা, কিন্তু সম্পূর্ণরূপে একই নয়।
আমি ইস্পাত থ্রেডগুলিকে "ট্রেসার বুলেট" হিসাবে উল্লেখ করার কথাও শুনেছি।
পিক্সাবে থেকে স্টিন জেপসেনের ছবি
এই গল্পটি মূলত এখানে উপস্থিত হয়েছিল: https://www.rubick.com/steel-threads/