ট্রান্সফরমার: 50% দ্রুত, শূন্য ডাউনটাইম। আপনার লিগ্যাসি কোড কি আপনাকে ধরে রেখেছে?

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

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

বার্ধক্য কোড একটি ব্যবসার প্রতিটি অংশ ধীর করতে পারে। রিলিজ বেশি সময় নেয়, ছোট পরিবর্তন অপ্রত্যাশিত বাগ তৈরি করে, এবং সিস্টেম কীভাবে কাজ করে তা বোঝার জন্য নতুন বিকাশকারীদের সপ্তাহ লাগে। পুরো প্ল্যাটফর্মটি প্রতিস্থাপন করা আকর্ষণীয় শোনাতে পারে, তবুও একটি বড় পুনঃলিখন দৈনন্দিন ক্রিয়াকলাপকে বাধাগ্রস্ত করতে পারে এবং নতুন ঝুঁকি তৈরি করতে পারে। আমি ধীরে ধীরে পদ্ধতি পছন্দ করি। নিয়ন্ত্রিত পদক্ষেপে কোডবেস উন্নত করার সময় দলটি পণ্যটিকে চলমান রাখে। ### বর্তমান সিস্টেমের একটি পরিষ্কার দৃষ্টিভঙ্গি দিয়ে শুরু করুন কোড পরিবর্তন করার আগে, আমি সবচেয়ে গুরুত্বপূর্ণ অংশগুলি ম্যাপ করি: - মূল ব্যবসায়িক ফাংশন - বাহ্যিক পরিষেবা এবং API - ডেটাবেস সংযোগ - স্থাপনের পদক্ষেপ - ঘন ঘন ত্রুটিযুক্ত এলাকা - মডিউল যা পরীক্ষা করা কঠিন - বৈশিষ্ট্যগুলি যা গ্রাহকরা প্রতিদিন ব্যবহার করে এই পর্যালোচনাটি দলটিকে জরুরী সমস্যাগুলিকে পুরানো কোড থেকে আলাদা করতে সহায়তা করে যা এখনও ভাল কাজ করে৷ একটি বিলিং পরিষেবা যা অর্থপ্রদান প্রক্রিয়া করে মাসে একবার ব্যবহৃত অভ্যন্তরীণ রিপোর্টের চেয়ে বেশি মনোযোগ দেওয়া উচিত। একা কোড বয়স কি পরিবর্তন করতে হবে তা আমাকে বলে না। ব্যবসায়িক প্রভাব, ব্যর্থতার ঝুঁকি, এবং রক্ষণাবেক্ষণের প্রচেষ্টা একটি ভাল নির্দেশিকা দেয়। ### একটি ছোট আধুনিকীকরণ লক্ষ্য সেট করুন একটি কোডবেস উন্নত করা সহজ হয়ে যায় যখন দলটি একটি পরিষ্কার সূচনা পয়েন্ট বেছে নেয়। একটি দরকারী লক্ষ্য হতে পারে: - একটি পরিষেবার জন্য স্থাপনার পদক্ষেপগুলি হ্রাস করুন - একটি উচ্চ-ঝুঁকির মডিউলে স্বয়ংক্রিয় পরীক্ষাগুলি যোগ করুন - একটি অসমর্থিত লাইব্রেরি প্রতিস্থাপন করুন - একটি ফাংশনকে একটি পৃথক পরিষেবাতে সরান - একটি মূল কর্মপ্রবাহের জন্য ত্রুটি লগিং উন্নত করুন - একটি সমর্থিত ভাষা সংস্করণে অ্যাপ্লিকেশনটির একটি অংশ আপগ্রেড করুন ছোট লক্ষ্যগুলি পরিমাপ করা সহজ করে তোলে৷ তারা সিস্টেমের বড় অংশ স্পর্শ করার আগে দলকে শেখার একটি নিরাপদ উপায়ও দেয়। ### পরীক্ষার মাধ্যমে কোড সুরক্ষিত করুন পরীক্ষা ছাড়াই আধুনিকীকরণ একটি মেশিন চলাকালীন পরিবর্তনের মত অনুভব করতে পারে। দলটি কাঠামোর উন্নতি করতে পারে এবং এখনও একটি গ্রাহকের কর্মপ্রবাহ ভাঙতে পারে। আমি সাধারণত সবচেয়ে মূল্যবান আচরণের চারপাশে পরীক্ষা দিয়ে শুরু করি। এই পরীক্ষাগুলি প্রতিটি লাইন কভার করার প্রয়োজন নেই। তাদের নিশ্চিত করতে হবে যে আবেদনটি কী চালিয়ে যেতে হবে। একটি অনলাইন অর্ডার সিস্টেমের জন্য, দরকারী পরীক্ষাগুলি পরীক্ষা করতে পারে যে: - একজন গ্রাহক একটি কার্টে একটি আইটেম যোগ করতে পারেন - একটি নিশ্চিত অর্ডারের পরে স্টক স্তর পরিবর্তন হয় - একটি ব্যর্থ অর্থপ্রদান একটি সম্পূর্ণ অর্ডার তৈরি করে না - একটি ফেরত অর্ডারের স্থিতি আপডেট করে - একটি অর্ডার নিশ্চিতকরণ সঠিক ইমেল ঠিকানায় পৌঁছায় চরিত্রগত পরীক্ষাগুলি পুরানো সিস্টেমে সাহায্য করতে পারে৷ দল অভ্যন্তরীণ কোড পরিবর্তন করার আগে তারা বর্তমান আচরণ রেকর্ড করে। এই পদ্ধতিটি সহায়ক যখন ডকুমেন্টেশন সীমিত হয় এবং বিদ্যমান অ্যাপ্লিকেশনটিতে বছরের ব্যবসায়িক নিয়ম থাকে। ### ছোট অংশে গঠন উন্নত করুন একটি বড় ফাইলে প্রায়ই বিভিন্ন দায়িত্ব থাকে। এটি এক জায়গায় ইনপুট যাচাই করতে, ব্যবসার নিয়ম প্রয়োগ করতে, ডেটা সংরক্ষণ করতে, ইমেল পাঠাতে এবং লগ লিখতে পারে। আমি এই দায়িত্বগুলিকে এক সময়ে আলাদা করি৷ প্রক্রিয়াটি এইরকম দেখতে পারে: 1. একটি ফাংশন বা মডিউল চয়ন করুন। 2. এর বর্তমান আচরণের চারপাশে পরীক্ষা যোগ করুন। 3. বারবার যুক্তি সরান। 4. অস্পষ্ট ভেরিয়েবল এবং পদ্ধতির আরও ভালো নাম দিন। 5. ডাটাবেস বা ব্যবহারকারী ইন্টারফেস কোড থেকে পৃথক ব্যবসা নিয়ম. 6. টেস্ট স্যুট চালান। 7. স্বাভাবিক প্রসবের প্রক্রিয়ার মাধ্যমে পরিবর্তনটি প্রকাশ করুন। এই পদ্ধতি প্রতিটি পরিবর্তন পর্যালোচনা করা সহজ রাখে। রিলিজ আশানুরূপ আচরণ না করলে এটি সমস্যার উত্স সনাক্ত করা সহজ করে তোলে। ### পুরানো উপাদানগুলিকে ক্রমান্বয়ে পাথ দিয়ে প্রতিস্থাপন করুন একটি সম্পূর্ণ পুনর্লিখন প্রায়শই ব্যর্থ হয় কারণ দলটি প্রতিস্থাপনের জন্য কয়েক মাস ব্যয় করে যখন পুরানো সিস্টেম পরিবর্তন হতে থাকে। প্রয়োজনীয়তা স্থানান্তরিত হয়, লুকানো নিয়মগুলি উপস্থিত হয় এবং নতুন সংস্করণের পরিধি বৃদ্ধি পায়। ধীরে ধীরে প্রতিস্থাপন সেই ব্যবধান কমিয়ে দেয়। একটি ব্যবহারিক প্যাটার্ন হল পুরানো মডিউলের পাশে একটি নতুন পরিষেবা স্থাপন করা। নতুন অনুরোধগুলি নতুন পরিষেবাতে যেতে পারে যখন সরানো হয়নি এমন ক্ষেত্রে পুরানো পথটি উপলব্ধ থাকে। দলটি ফলাফলের তুলনা করতে পারে, ত্রুটি পর্যালোচনা করতে পারে এবং স্থিতিশীল প্রমাণিত হওয়ার পরে নতুন পথ প্রসারিত করতে পারে। উদাহরণস্বরূপ, একটি কোম্পানি অ্যাকাউন্ট ইতিহাস সরানোর আগে গ্রাহক প্রোফাইল আপডেট স্থানান্তর করতে পারে। প্রতিটি অংশের নিজস্ব চেক এবং রিলিজ পরিকল্পনা আছে। মাইগ্রেশন অগ্রসর হওয়ার সময় ব্যবহারকারীরা পণ্যটি অ্যাক্সেস করতে থাকে। ### ডাটাবেস পরিবর্তনগুলিকে নিরাপদ রাখুন ডাটাবেসের কাজ সতর্কতার সাথে পরিকল্পনার দাবি রাখে কারণ অ্যাপ্লিকেশন কোড এবং সংরক্ষিত ডেটা একে অপরের উপর নির্ভর করে। আমি সেই পরিবর্তনগুলি এড়াই যেগুলির জন্য পুরানো এবং নতুন অ্যাপ্লিকেশন সংস্করণগুলিকে একই মুহুর্তে বিভিন্ন ডেটা ফর্ম্যাট ব্যবহার করার প্রয়োজন হয়৷ একটি নিরাপদ স্থানান্তর প্রায়শই এই প্যাটার্ন অনুসরণ করে: - নতুন ক্ষেত্র বা টেবিল যোগ করুন - উভয় অ্যাপ্লিকেশন সংস্করণকে পুরানো কাঠামো বুঝতে দিন - ছোট ব্যাচে বিদ্যমান ডেটা অনুলিপি করুন - নতুন কাঠামোতে লেখা শুরু করুন - যাচাইকরণের পরে নতুন কাঠামো থেকে পড়ুন - পুরানো কাঠামোটি আর প্রয়োজন না থাকার পরে এটি সরান দলটিকে মাইগ্রেশনের গতি, ব্যর্থ রেকর্ড, ডাটাবেস লোড এবং ডেটা অমিল নিরীক্ষণ করা উচিত৷ একটি ব্যাকআপ পরিকল্পনা মাইগ্রেশন শুরু হওয়ার আগে পরীক্ষা করা উচিত, কোনো ঘটনার সময় নয়। ### রিলিজগুলিকে নিয়ন্ত্রণ করা সহজ করুন একটি আধুনিক কোডবেস এখনও ঝুঁকি তৈরি করে যদি প্রতিটি রিলিজ স্থাপন করা কঠিন হয়। আমি ডেলিভারি পুনরাবৃত্তিযোগ্য করার উপায় খুঁজছি: - কোডের বাইরে কনফিগারেশন সঞ্চয় করুন - স্বয়ংক্রিয় বিল্ড চেক ব্যবহার করুন - প্রতিটি পুল অনুরোধের সময় পরীক্ষা চালান - প্রতিটি পরিবেশের জন্য একই প্যাকেজ তৈরি করুন - স্থাপনার পদক্ষেপগুলি নথিভুক্ত রাখুন - ধীরে ধীরে প্রকাশের প্রয়োজন এমন পরিবর্তনগুলির জন্য বৈশিষ্ট্য পতাকা ব্যবহার করুন - একটি পরীক্ষিত রোলব্যাক প্রক্রিয়া রাখুন বৈশিষ্ট্য ফ্ল্যাগগুলি সর্বজনীন রিলিজ থেকে স্থাপনাকে আলাদা করতে পারে৷ কোডটি উত্পাদনে উপস্থিত থাকতে পারে যখন অ্যাক্সেস অভ্যন্তরীণ ব্যবহারকারী বা গ্রাহকদের একটি ছোট গ্রুপের মধ্যে সীমাবদ্ধ থাকে। এটি সবার জন্য খোলার আগে পরিবর্তনটি দেখার জন্য দলকে সময় দেয়। ### দরকারী পর্যবেক্ষণ লগ এবং মেট্রিক্স যোগ করুন নির্দিষ্ট প্রশ্নের উত্তর দিতে সাহায্য করবে। ডেটার একটি উচ্চ ভলিউম দরকারী দৃশ্যমানতার মতো নয়। প্রতিটি আধুনিক এলাকার জন্য, আমি জানতে চাই: - পরিষেবাটি উপলব্ধ? - অনুরোধ করতে কতক্ষণ লাগে? - কত ঘন ঘন অনুরোধ ব্যর্থ হয়? - কোন ত্রুটি ব্যবহারকারীদের প্রভাবিত করে? - ডাটাবেস কল কি কর্মপ্রবাহকে ধীর করে দিচ্ছে? - নতুন সংস্করণ কি ব্যবসার ফলাফল পরিবর্তন করেছে? একটি অর্থপ্রদান পরিষেবার ব্যর্থ লেনদেন এবং বিলম্বিত প্রতিক্রিয়াগুলির জন্য সতর্কতার প্রয়োজন হতে পারে। একটি অনুসন্ধান বৈশিষ্ট্য খালি ফলাফল এবং প্রতিক্রিয়া সময় ডেটা প্রয়োজন হতে পারে. সর্বোত্তম পর্যবেক্ষণ প্রতিফলিত করে কিভাবে মানুষ পণ্য ব্যবহার করে। ### লোকেদের জড়িত রাখুন কোড আধুনিকীকরণ শুধুমাত্র একটি প্রযুক্তিগত কাজ নয়। প্রোডাক্ট ম্যানেজার, সাপোর্ট টিম, অপারেশন স্টাফ এবং ডেভেলপাররা প্রত্যেকেই সিস্টেমের একটি আলাদা অংশ জানেন। সমর্থন রেকর্ডগুলি এমন সমস্যা প্রকাশ করতে পারে যা কোড মেট্রিক্স মিস করে। একজন বিকাশকারী একটি ধীর পদ্ধতি দেখতে পারে, যখন একজন সমর্থন এজেন্ট জানে যে গ্রাহকরা একটি ফর্ম পরিত্যাগ করে যখন এটি প্রতিক্রিয়া জানাতে খুব বেশি সময় নেয়। আমি দলগুলিকে শেয়ার করতে বলি: - কোন কার্যপ্রবাহ বারবার অভিযোগের কারণ হয় - কোন ম্যানুয়াল কাজগুলি কর্মীদের সময় ব্যয় করে - কোন রিলিজগুলি সমর্থন অনুরোধ তৈরি করে - কোন একীকরণ বজায় রাখা কঠিন - কোন ব্যবসার নিয়মগুলি লেখা নেই এই বিবরণগুলি দলকে এমন কাজ বেছে নিতে সাহায্য করে যা কোড এবং পণ্য উভয়েরই উন্নতি করে৷ ### একটি বাস্তব সাফল্যের পরিমাপ ব্যবহার করুন আধুনিকীকরণ পরিমাপ করা উচিত পরিবর্তনের মাধ্যমে যা ব্যবসা এবং প্রকৌশল দল বুঝতে পারে। দরকারী ব্যবস্থাগুলির মধ্যে রয়েছে: - একটি ছোট পরিবর্তন প্রকাশ করার জন্য সময় প্রয়োজন - স্থাপনার পরে ত্রুটির সংখ্যা - ঘটনাগুলি নির্ণয় করার সময় ব্যয় করা - সমালোচনামূলক কর্মপ্রবাহের জন্য পরীক্ষা কভারেজ - স্থাপনার রোলব্যাক ফ্রিকোয়েন্সি - পুনরাবৃত্ত সমস্যাগুলি সমাধান করতে বিকাশকারীর সময় ব্যয় - মূল গ্রাহকের ক্রিয়াকলাপের জন্য প্রতিক্রিয়া সময় প্রতিটি ফাইলকে নতুন দেখায় লক্ষ্য নয়৷ লক্ষ্য হল এমন একটি সিস্টেম তৈরি করা যাতে দলটি কম ঝুঁকি এবং কম অপচয়ের প্রচেষ্টায় পরিবর্তন করতে পারে। ### একটি স্থির পথ একটি নাটকীয় পুনর্লিখনের চেয়ে ভাল কাজ করে আমি কোড আধুনিকীকরণকে স্পষ্ট ব্যবসায়িক লক্ষ্যগুলির সাথে চলমান রক্ষণাবেক্ষণ হিসাবে বিবেচনা করি। দলটি বর্তমান সিস্টেম অধ্যয়ন করে, পরীক্ষার মাধ্যমে মূল আচরণকে রক্ষা করে, এক সময়ে একটি এলাকাকে উন্নত করে এবং পরবর্তী সিদ্ধান্ত নেওয়ার জন্য মনিটরিং ব্যবহার করে। একটি স্থিতিশীল পণ্যের কোড উন্নত হওয়ার সময় থামার প্রয়োজন নেই। ছোট রিলিজ, নিরাপদ ডাটাবেস পরিবর্তন, এবং একটি রোলব্যাক প্ল্যান সহ, টিম গ্রাহকদের পরিষেবা চালিয়ে যাওয়ার সাথে সাথে কোডবেসকে আধুনিকীকরণ করতে পারে। আমরা শিল্প ক্ষেত্রে ব্যাপক অভিজ্ঞতা আছে. পেশাদার পরামর্শের জন্য আমাদের সাথে যোগাযোগ করুন: অ্যামি উ: amy.wu@ihuagroup.com/WhatsApp +8613612662976।

রেফারেন্স মার্টিন ফাউলার, 2004, স্ট্র্যাংলার ফিগঅ্যাপ্লিকেশন মাইকেল সি ফেদারস, 2004, লিগ্যাসি কোডের সাথে কার্যকরীভাবে কাজ করা নিকোল ফরসগ্রেন জেজ হাম্বল এবং জিন কিম, 2018, জিনকে ত্বরান্বিত করুন কিম কেভিন বেহর এবং জর্জ স্প্যাফোর্ড, 2013, দ্য পিহো 1, ডেভিড 01, ডেভিড প্রজেক্ট ক্রমাগত বিতরণ রবার্ট সি মার্টিন, 2017, ক্লিন আর্কিটেকচার