ভাল সফ্টওয়্যার আর্কিটেকচারের জন্য মানদণ্ড

দক্ষতা

অভিজ্ঞ প্রোগ্রামাররা সহজেই একটি খারাপ থেকে একটি ভাল আর্কিটেকচার বলতে পারেন, তবে যদি এটিকে কয়েকটি শব্দে বর্ণনা করতে বলা হয় তবে তারা তা করতে সক্ষম হওয়ার সম্ভাবনা কম। ভাল স্থাপত্যের জন্য কোন একক মাপকাঠি নেই এবং কোন একক সংজ্ঞা নেই।

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

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

• দক্ষতা;
• নমনীয়তা;
• প্রসারণযোগ্যতা;
• পরিমাপযোগ্যতা;
• পরীক্ষাযোগ্যতা
• কোড রক্ষণাবেক্ষণযোগ্যতা।

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

আপনি ক্রমাগত এমন প্রোগ্রাম জুড়ে আসবেন যা তারা যা করার দাবি করে তা করে না।

• Libre Office হল Microsoft Office এর সম্পূর্ণ প্রতিস্থাপন (আসলে নয়);
• এজ ব্রাউজার সমস্ত ওয়েব স্ট্যান্ডার্ড সমর্থন করে (আসলেই নয়);
• ব্যাঙ্ক তার ব্যবহারকারীদের ব্যক্তিগত তথ্যের নিরাপত্তার বিষয়ে যত্নশীল (আসলে নয়)।

এবং আমরা এখনও পারফরম্যান্স, নির্ভরযোগ্যতা, সময়মত বাগ ফিক্স বা পরিচিত দুর্বলতা সম্পর্কে তথ্য প্রকাশের উপর স্পর্শ করিনি।

এটা স্পষ্ট যে কেউ নিখুঁত নয়, তবে প্রোগ্রামটিকে অবশ্যই তার প্রাথমিক কাজগুলি সমাধান করতে হবে। অতএব, দক্ষতা ছাড়া, কোথাও.

নমনীয়তা

আমার মতে দক্ষতার চেয়ে গুরুত্বপূর্ণ একমাত্র জিনিস হল নমনীয়তা। যেকোনো অ্যাপ্লিকেশন সময়ের সাথে সাথে পরিবর্তন করতে হবে, প্রয়োজনীয়তা পরিবর্তিত হওয়ার সাথে সাথে নতুন যুক্ত করা হয়। বিদ্যমান কার্যকারিতা পরিবর্তন করা যত দ্রুত এবং আরও সুবিধাজনক, এটি যত কম সমস্যা এবং ত্রুটি সৃষ্টি করে, সিস্টেম আর্কিটেকচার তত বেশি নমনীয় ।

খুব প্রায়ই, নবীন প্রোগ্রামার / স্থপতিরা মনে করেন যে তাদের বর্তমান কাজের জন্য একটি আদর্শ আর্কিটেকচার দরকার। না. এক বছরে আপনাকে যে কাজগুলি ঘোষণা করা হবে তার জন্য আপনার একটি আদর্শ আর্কিটেকচার দরকার। আপনি, ইতিমধ্যে ভবিষ্যতের কাজগুলি জানেন না, সেগুলি কী হবে তা জানা উচিত।

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

নিজেকে জিজ্ঞাসা করুন: "কি হবে যদি বর্তমান স্থাপত্য সিদ্ধান্তটি ভুল হয়ে যায়?", "কতটা কোড পরিবর্তন করা হবে?"। সিস্টেমের একটি খণ্ড পরিবর্তন করা তার অন্যান্য খণ্ডকে প্রভাবিত করা উচিত নয়।

যখনই সম্ভব, স্থাপত্য সংক্রান্ত সিদ্ধান্তগুলি পাথরে সেট করা উচিত নয় এবং স্থাপত্য ত্রুটির পরিণতি যুক্তিসঙ্গতভাবে সীমিত হওয়া উচিত। "ভাল আর্কিটেকচার আপনাকে মূল সিদ্ধান্তগুলি বিলম্বিত করতে দেয়" (বব মার্টিন) এবং ভুলের "খরচ" কমিয়ে দেয়।

এই পদ্ধতিগুলির মধ্যে একটি হল অ্যাপ্লিকেশনটিকে মাইক্রোসার্ভিসে বিভক্ত করা: ইতিমধ্যে বিদ্যমান যুক্তিটিকে আলাদা অংশে ভাঙ্গা সহজ। কিন্তু সবচেয়ে বড় সমস্যা হল একটি ছোট বৈশিষ্ট্য বাস্তবায়নের জন্য এক ডজন পরিষেবায় ভবিষ্যৎ পরিবর্তন করা।

পরিমাপযোগ্যতা

স্কেলেবিলিটি হল প্রকল্পে নতুন লোক যুক্ত করে উন্নয়নের সময় কমানোর ক্ষমতা। স্থাপত্যের উন্নয়ন প্রক্রিয়াটিকে সমান্তরাল করার অনুমতি দেওয়া উচিত যাতে অনেক লোক একই সময়ে প্রোগ্রামে কাজ করতে পারে।

দেখে মনে হচ্ছে এই নিয়মটি নিজেই সঞ্চালিত হয়, তবে বাস্তবে সবকিছু ঠিক বিপরীত। এমনকি একটি অতি-জনপ্রিয় বই, দ্য মিথিক্যাল ম্যান-মান্থ , যা ব্যাখ্যা করে যে কেন যখন একটি প্রকল্পে নতুন লোক যুক্ত করা হয়, তখন বিকাশের সময় বৃদ্ধি পায়।

প্রসারণযোগ্যতা

এক্সটেনসিবিলিটি হল একটি সিস্টেমের মূল কাঠামো ভেঙ্গে নতুন বৈশিষ্ট্য এবং সত্তা যোগ করার ক্ষমতা। প্রাথমিক পর্যায়ে, সিস্টেমে শুধুমাত্র মৌলিক এবং সবচেয়ে প্রয়োজনীয় কার্যকারিতা রাখা বোধগম্য।

এটি তথাকথিত যগ্নি নীতি - আপনার এটির প্রয়োজন হবে না , "আপনার এটির প্রয়োজন হবে না"। একই সময়ে, আর্কিটেকচার আপনাকে প্রয়োজন অনুসারে অতিরিক্ত কার্যকারিতা সহজেই বৃদ্ধি করতে দেয়। এবং যাতে সর্বাধিক সম্ভাব্য পরিবর্তনগুলি প্রবর্তনের জন্য সর্বনিম্ন প্রচেষ্টার প্রয়োজন হয়৷

সিস্টেমের আর্কিটেকচারটি নমনীয় এবং প্রসারিত হওয়ার প্রয়োজনীয়তা (অর্থাৎ পরিবর্তন এবং বিবর্তনে সক্ষম হওয়া) এত গুরুত্বপূর্ণ যে এটি এমনকি একটি পৃথক নীতি হিসাবে প্রণয়ন করা হয়েছে - "ওপেন/ক্লোজড প্রিন্সিপল " । খোলা-বন্ধ নীতি হল পাঁচটি সলিড নীতির দ্বিতীয়: সফ্টওয়্যার সত্তা (শ্রেণী, মডিউল, ফাংশন) এক্সটেনশনের জন্য উন্মুক্ত হওয়া উচিত, কিন্তু পরিবর্তনের জন্য বন্ধ করা উচিত ।

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

এর মানে হল যে অ্যাপ্লিকেশনটি এমনভাবে ডিজাইন করা উচিত যাতে বিদ্যমান কোড পরিবর্তন না করেই নতুন কোড (এক্সটেনশন) লেখার মাধ্যমে এর আচরণ পরিবর্তন করা এবং নতুন কার্যকারিতা যোগ করা সম্ভব হবে।

এই ক্ষেত্রে, নতুন প্রয়োজনীয়তার উত্থানের ফলে বিদ্যমান যুক্তির পরিবর্তন হবে না, তবে এটিকে প্রসারিত করে প্রাথমিকভাবে প্রয়োগ করা যেতে পারে। এই নীতিটি "প্লাগ-ইন আর্কিটেকচার" (প্লাগইন আর্কিটেকচার) এর ভিত্তি। যে কৌশলগুলি দ্বারা এটি অর্জন করা যায় তা পরে আলোচনা করা হবে।

servlets এবং ফিল্টার মনে রাখবেন? কেন ফিল্টার প্রয়োজন ছিল, এবং এমনকি পৃথক ইন্টারফেসের সাথে, যদি বাস্তবে, সার্লেট ব্যবহার করে একই যুক্তি প্রয়োগ করা যেতে পারে?

এটি ফিল্টার (পরিষেবা সার্লেট) ধারণার উদ্ভাবন যা বিভিন্ন পরিষেবা ফাংশনকে একটি পৃথক স্তরে স্থানান্তর করা সম্ভব করে তুলেছিল। এবং ভবিষ্যতে, ফিল্টারগুলির আচরণ পরিবর্তন করার সময়, সার্লেটগুলি পরিবর্তন করার প্রয়োজন ছিল না।

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

পরীক্ষাযোগ্যতা

আপনি যদি জাভা ব্যাকএন্ড বিকাশকারী হন, তাহলে আপনার সার্ভার অ্যাপ্লিকেশনগুলি প্রায়শই একটি REST API হিসাবে পদ্ধতির একটি সেট প্রকাশ করে। এবং আপনার সমস্ত পদ্ধতিগুলি উদ্দেশ্য হিসাবে কাজ করে তা পরীক্ষা করার জন্য, সেগুলিকে পরীক্ষার মাধ্যমে আবৃত করা দরকার।

সাধারণভাবে, API পরীক্ষার কভারেজ একটি ভাল শৈলী। এটি আপনাকে নিশ্চিত করতে দেয় যে আপনার API সত্যিই যা করার উদ্দেশ্যে ছিল তা করে। এবং এছাড়াও, আরও গুরুত্বপূর্ণভাবে, আপনি সার্ভারের যুক্তিতে পরিবর্তন করতে পারেন এবং সহজেই পরীক্ষা করতে পারেন যে আপনি ভুলবশত কিছু ভেঙে ফেলেছেন না ।

যত তাড়াতাড়ি আপনি পরীক্ষা লিখতে শুরু করবেন, আপনি বুঝতে পারবেন যে বেশিরভাগ কোড মোটেই পরীক্ষা করা যায় না: ব্যক্তিগত পদ্ধতি, শক্তিশালী কাপলিং, স্ট্যাটিক ক্লাস এবং ভেরিয়েবল।

"কোড কাজ করলে আমাদের পরীক্ষার প্রয়োজন কেন?", শিক্ষানবিস জিজ্ঞাসা করবে।

"কেন আমাদের কাজের কোড দরকার যদি এটি পরীক্ষা করা না যায়?", পেশাদার জিজ্ঞাসা করবে।

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

এখানে আইডিয়াল আর্কিটেকচার বই থেকে একটি উদ্ধৃতি দেওয়া হল: "একটি ক্লাসের "পরীক্ষাযোগ্যতা" নীতিটি ভাল ক্লাস ডিজাইনের "লিটমাস টেস্ট" হিসাবে ব্যবহার করুন৷ এমনকি যদি আপনি পরীক্ষার কোডের একটি লাইন নাও লিখুন, 90-এ এই প্রশ্নের উত্তর দিন % ক্ষেত্রে বুঝতে সাহায্য করবে কিভাবে সবকিছু ভালো" বা "খারাপ" তার ডিজাইনের সাথে।"

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

কোড রক্ষণাবেক্ষণযোগ্যতা

একটি নিয়ম হিসাবে, অনেক লোক প্রোগ্রামে কাজ করে - কিছু চলে যায়, নতুন আসে। একটি আইটি কোম্পানিতে একজন প্রোগ্রামারের গড় কাজের সময় দেড় বছর। সুতরাং আপনি যদি 5 বছর বয়সী একটি প্রকল্পে আসেন, তবে আপনার সহকর্মীদের মধ্যে মাত্র 20% প্রথম থেকেই এটিতে কাজ করেছেন।

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

অতএব, একটি ভাল স্থাপত্য নতুন লোকেদের জন্য সিস্টেমটি বোঝার জন্য অপেক্ষাকৃত সহজ এবং দ্রুত করা উচিত । প্রকল্প হতে হবে:

• ভাল কাঠামো.
• ডুপ্লিকেশন ধারণ করবেন না.
• ভাল ফর্ম্যাট কোড আছে.
• ডকুমেন্টেশন অন্তর্ভুক্ত করা বাঞ্ছনীয়।
• প্রোগ্রামারদের জন্য মানক এবং পরিচিত সমাধান প্রয়োগ করা প্রয়োজন।

আপনি 5-পয়েন্ট স্কেলে আপনি যে প্রকল্পে কাজ করছেন তা সহজেই রেট করতে পারেন । এই প্রয়োজনীয়তার প্রতিটির জন্য শুধু দুটি পয়েন্ট গণনা করুন । এবং আপনি যদি 5 বা তার বেশি পান তবে আপনি ভাগ্যবান।

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