সলআইডিতে স্যুইচ করার পরে ব্যাপক বর্ধিত ক্লাস পরিচালনা ও পরিচালনা করছেন?


49

গত কয়েক বছর ধরে, আমরা আস্তে আস্তে উন্নততর লিখিত কোডে স্যুইচ ওভার করছি, একসাথে কয়েকটি শিশুর পদক্ষেপ। আমরা অবশেষে এমন কিছুতে স্যুইচটিকে শুরু করতে শুরু করি যা কমপক্ষে সলাইডের অনুরূপ, তবে আমরা এখনও সেখানে আছি না। স্যুইচটি তৈরি করার পরে, বিকাশকারীদের কাছ থেকে সবচেয়ে বড় অভিযোগ হ'ল তারা পিয়ার পর্যালোচনা এবং কয়েক ডজন এবং কয়েক ডজন ফাইল ট্র্যাভার করে দাঁড়াতে পারবেন না যেখানে আগে প্রতিটি কার্যেই কেবল বিকাশকারীকে 5-10 ফাইল স্পর্শ করা প্রয়োজন।

স্যুইচ করা শুরু করার আগে, আমাদের আর্কিটেকচারটি নীচের মতো বেশ সুসজ্জিতভাবে সাজানো হয়েছিল (আরও দুটি ফাইলের আকারের দুটি বা দুটি অর্ডার দিয়ে দেওয়া হয়েছে):

Solution
- Business
-- AccountLogic
-- DocumentLogic
-- UsersLogic
- Entities (Database entities)
- Models (Domain Models)
- Repositories
-- AccountRepo
-- DocumentRepo
-- UserRepo
- ViewModels
-- AccountViewModel
-- DocumentViewModel
-- UserViewModel
- UI

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

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

  • ইউনিট টেস্ট
  • ক্লাস গণনা
  • পিয়ার রিভিউ জটিলতা

ইউনিট পরীক্ষাগুলি দলে একটি অবিশ্বাস্যভাবে কঠোর বিক্রয় হয়েছে কারণ তারা সকলেই বিশ্বাস করে যে তারা সময় নষ্ট করে এবং তারা পৃথকভাবে প্রতিটি টুকরো থেকে পুরোপুরি তাদের কোডটি হ্যান্ডেল-টেস্ট করতে সক্ষম। সলিডের পক্ষে প্রস্তাব হিসাবে ইউনিট পরীক্ষাগুলি ব্যবহার করা বেশিরভাগ ক্ষেত্রে নিরর্থক এবং বেশিরভাগ সময়েই এটি একটি রসিকতায় পরিণত হয়েছে।

ক্লাস গণনা সম্ভবত একমাত্র বৃহত্তম বাধা অতিক্রম করতে পারে। যে টাস্কগুলিতে 5-10 ফাইল নেওয়া হত এখন 70-100 লাগতে পারে! এই ফাইলগুলির প্রত্যেকটি পৃথক উদ্দেশ্যে পরিবেশন করার সময়, ফাইলগুলির নিছক ভলিউম অপ্রতিরোধ্য হতে পারে। দলটির প্রতিক্রিয়া বেশিরভাগই কর্ণপাত এবং মাথা চুলকানো ছিল। পূর্বে কোনও কাজের জন্য এক বা দুটি সংগ্রহস্থল, একটি মডেল বা দুটি, একটি লজিক স্তর এবং একটি নিয়ামক পদ্ধতি থাকতে পারে required

এখন, একটি সরল ফাইল সেভিং অ্যাপ্লিকেশন তৈরি করতে আপনার ফাইলটি ইতিমধ্যে উপস্থিত রয়েছে কিনা তা যাচাই করার জন্য একটি ক্লাস রয়েছে, মেটাডেটা লেখার জন্য একটি ক্লাস, বিমূর্ত করার জন্য একটি শ্রেণি DateTime.Nowযাতে আপনি ইউনিট পরীক্ষার জন্য সময় ইনজেকশন করতে পারেন, যুক্তিযুক্ত ফাইলগুলির প্রতিটি ফাইলের জন্য ইন্টারফেস, ফাইলগুলি সেখানে প্রতিটি ক্লাসের ইউনিট পরীক্ষা এবং আপনার ডিআই কনটেইনে সমস্ত কিছু যুক্ত করার জন্য এক বা একাধিক ফাইল রয়েছে।

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


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

নেটওয়ার্ক ড্রাইভে ডকুমেন্টটি সংরক্ষণ করতে আমার কয়েকটি নির্দিষ্ট ক্লাসের প্রয়োজন:

- IBasePathProvider 
-- string GetBasePath() // returns the network path to store files
-- string GetPatientFolderName() // gets the name of the folder where patient files are stored
- BasePathProvider // provides an implementation of IBasePathProvider
- BasePathProviderTests // ensures we're getting what we expect

- IUniqueFilenameProvider
-- string GetFilename(string path, string fileType);
- UniqueFilenameProvider // performs some filesystem lookups to get a unique filename
- UniqueFilenameProviderTests

- INewGuidProvider // allows me to inject guids to simulate collisions during unit tests
-- Guid NewGuid()
- NewGuidProvider 
- NewGuidProviderTests

- IFileExtensionCombiner // requests may come in a variety of ways, need to ensure extensions are properly appended.
- FileExtensionCombiner
- FileExtensionCombinerTests

- IPatientFileWriter
-- Task SaveFileAsync(string path, byte[] file, string fileType)
-- Task SaveFileAsync(FilePushRequest request) 
- PatientFileWriter
- PatientFileWriterTests

সুতরাং মোট 15 টি ক্লাস (পিওসিও এবং স্ক্যাফোल्डিং বাদে) মোটামুটি সরল সাফল্য সঞ্চালনের জন্য। এই সংখ্যাটি উল্লেখযোগ্যভাবে বেলুন করা যখন আমার কয়েকটি সিস্টেমে সত্তার প্রতিনিধিত্ব করার জন্য পোকো তৈরি করার প্রয়োজন হয়েছিল, তৃতীয় পক্ষের সিস্টেমগুলির সাথে যোগাযোগের জন্য কয়েকটি রেপো তৈরি করা হয়েছিল যা আমাদের অন্যান্য ওআরএমের সাথে অসামঞ্জস্যপূর্ণ এবং কিছু ক্রিয়াকলাপের জটিলতাগুলি পরিচালনা করতে লজিক পদ্ধতি তৈরি করেছিল।


52
"যে টাস্কগুলিতে 5-10 ফাইল নেওয়া হত এখন 70-100 লাগতে পারে!" কীভাবে? এটি কোনওভাবেই স্বাভাবিক নয়। আপনি কোন ধরণের পরিবর্তন আনছেন যার জন্য যে অনেকগুলি ফাইল পরিবর্তন করা দরকার ??
ইফফোরিক

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

60
কাজ সেরে সহায়তা করার জন্য আপনি স্পষ্টতই সোলিডকে একটি ধর্ম হিসাবে গ্রহণ করেছেন। যদি সলাইডের কিছু কিছু বেশি কাজ করে বা জিনিসগুলিকে আরও জটিল করে তোলে তবে তা করবেন না।
কিয়াসনাম

25
@ ইউফোরিক: সমস্যাটি দুটি উপায়েই ঘটতে পারে। আমার সন্দেহ হয় আপনি 70-100 ক্লাস ওভারকিলের সম্ভাবনাটি সাড়া করছেন। তবে এটি অসম্ভব নয় যে এটি কেবলমাত্র একটি বিশাল প্রকল্প হিসাবে ঘটেছিল যা 5-10 ফাইলগুলিতে ক্র্যাম হয়েছিল (আমি আগে 20KLOC ফাইলগুলিতে কাজ করেছি ...) এবং 70-100 আসলে ফাইলগুলির সঠিক পরিমাণ।
ফ্ল্যাটার

18
চিন্তার একটি ব্যাধি আছে যা আমি "অবজেক্ট সুখ ডিজিজ" বলি, যা বিশ্বাস করে যে ওও কৌশলগুলি একটি বড় কোডবেসে কাজ করার ব্যয় হ্রাস করার জন্য সম্ভাব্য কয়েকটি কৌশলগুলির মধ্যে একটির চেয়ে নিজেকেই শেষ করে। আপনার একটি বিশেষত উন্নত রূপ রয়েছে, "সলড সুখের রোগ"। সলিড লক্ষ্য নয়। কোডবেস রক্ষণাবেক্ষণের ব্যয় কমিয়ে আনাই লক্ষ্য is আপনার প্রস্তাবগুলিকে সেই প্রসঙ্গে মূল্যায়ন করুন, এটি কোনও মতবাদই সলাইড কিনা in (আপনার প্রস্তাবগুলি সম্ভবত বাস্তবে মতবাদ নয়, সলাইডও বিবেচনা করার জন্য একটি ভাল বিষয়))
এরিক লিপার্ট

উত্তর:


104

এখন, একটি সরল ফাইল সেভিং অ্যাপ্লিকেশন তৈরি করতে আপনার ফাইলটি ইতিমধ্যে উপস্থিত রয়েছে কিনা তা পরীক্ষা করার জন্য একটি ক্লাস রয়েছে, মেটাডেটা লেখার জন্য একটি ক্লাস, ডেটটাইম দূরে বিমূর্ত করার জন্য একটি ক্লাস। এখন আপনি ইউনিট পরীক্ষার জন্য সময় ইনজেকশন করতে পারবেন, প্রতিটি ফাইলের জন্য ইন্টারফেস যুক্ত করতে পারেন যুক্তি, সেখানে প্রতিটি ক্লাসের ইউনিট পরীক্ষার ফাইল এবং আপনার ডিআই কনটেইনে সমস্ত কিছু যুক্ত করার জন্য এক বা একাধিক ফাইল।

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

বিমূর্ত করার জন্য একটি বর্গ DateTime.Nowভাল শোনাচ্ছে। তবে আপনার কেবল সেগুলির মধ্যে একটি প্রয়োজন এবং এটি পরিবেশগত বৈশিষ্ট্যগুলি বিমূর্ত করার জন্য দায়বদ্ধতার সাথে অন্যান্য পরিবেশ বৈশিষ্ট্যগুলি একক শ্রেণিতে আবৃত করা যেতে পারে। আবার একক দায়িত্ব একাধিক উপ-দায়িত্ব।

আপনার "যুক্তিযুক্ত প্রতিটি ফাইলের জন্য ইন্টারফেস" দরকার নেই, আপনার ক্লাসগুলির জন্য ইন্টারফেসের দরকার রয়েছে যার পার্শ্ব-প্রতিক্রিয়া রয়েছে, যেমন those ক্লাসগুলি যা ফাইল বা ডাটাবেসে পড়ে / লেখেন; এবং তারপরেও এগুলি কেবল সেই কার্যকারিতার জনসাধারণের জন্য প্রয়োজন। সুতরাং উদাহরণস্বরূপ AccountRepo, আপনার কোনও ইন্টারফেসের প্রয়োজন নাও হতে পারে, কেবলমাত্র সেই রিপোর মধ্যে ectedুকানো প্রকৃত ডাটাবেস অ্যাক্সেসের জন্য আপনার কেবল ইন্টারফেসের প্রয়োজন হতে পারে।

ইউনিট পরীক্ষাগুলি দলে একটি অবিশ্বাস্যভাবে কঠোর বিক্রয় হয়েছে কারণ তারা সকলেই বিশ্বাস করে যে তারা সময় নষ্ট করে এবং তারা পৃথকভাবে প্রতিটি টুকরো থেকে পুরোপুরি তাদের কোডটি হ্যান্ডেল-টেস্ট করতে সক্ষম। সলিডের পক্ষে প্রস্তাব হিসাবে ইউনিট পরীক্ষাগুলি ব্যবহার করা বেশিরভাগ ক্ষেত্রে নিরর্থক এবং বেশিরভাগ সময়েই এটি একটি রসিকতায় পরিণত হয়েছে।

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

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

সর্বদা বাস্তববাদী হোন এবং মনে রাখবেন সবকিছুই একটি আপস। আপনি যত বেশি ডিআরওয়াইয়ের সাথে মেনে চলবেন, ততই দৃ code়ভাবে আপনার কোডটি সংযুক্ত হয়ে উঠবে। আপনি বিমূর্তকরণগুলিকে যত বেশি পরিচয় করিয়ে দিন, কোডটি পরীক্ষা করা আরও সহজ, তবে এটি বোঝা তত কঠিন। আদর্শ এড়ানো এবং আদর্শ এবং এটিকে সহজ রাখার মধ্যে একটি ভাল ভারসাম্য খুঁজে নিন। উন্নয়ন এবং রক্ষণাবেক্ষণ উভয়ের জন্যই সর্বাধিক দক্ষতার মিষ্টি স্পট রয়েছে।


27
আমি যুক্ত করতে চাই যে লোকেরা যখন "পদ্ধতিগুলির মধ্যে কেবল একটি কাজ করা উচিত" এর খুব বেশি বারবার মন্ত্রটি মেনে চলার চেষ্টা করে এবং এক লাইন পদ্ধতিতে প্রচুর পরিমাণে শেষ হয় কারণ এটি প্রযুক্তিগতভাবে কোনও পদ্ধতিতে তৈরি করা যেতে পারে ।
লোগার

8
পুনরায় "সর্বদা বাস্তববাদী হোন এবং মনে রাখবেন সবকিছুই একটি আপস" : চাচা বব এর শিষ্যরা এর জন্য পরিচিত নন (আসল অভিপ্রায় নির্বিশেষে)।
পিটার মর্টেনসেন

13
প্রথম অংশটি যোগ করতে, আপনার সাধারণত একটি কফি ইন্টার্ন থাকে, প্লাগ-ইন-পেরকোলটারের পুরো স্যুট নয়, ফ্লিপ-সুইচ, চেক-যদি-চিনির দরকার-রিফিলিং, ওপেন-ফ্রিজ, দুধ পান, পান আউট-চামচ, গেট-ডাউন-কাপ, pourালা-কফি, অ্যাড-চিনি, অ্যাড-মিল্ক, আলোড়ন কাপ, এবং বিতরণ কাপ ইন্টার্নস। ; পি
জাস্টিন সময় 2 মনিকা পুনরায় ইনস্টল করুন

12
ওপি এর সমস্যা মূল কারণ ফাংশন যা একটি একক সম্পাদন করা উচিত মধ্যে পার্থক্য ভুল বুঝা হবে বলে মনে হচ্ছে কাজের, যা একটি একক থাকা উচিত এবং শ্রেণীর দায়িত্ব।
alephzero

6
"বিধিগুলি জ্ঞানী লোকদের দিকনির্দেশনা এবং মূর্খদের আনুগত্যের জন্য" " - ডগলাস বদর
ক্যালানাস

29

যে টাস্কগুলিতে 5-10 ফাইল নেওয়া হত এখন 70-100 লাগতে পারে!

এটি একক-দায়িত্ব নীতি (এসআরপি) এর বিপরীত । যে বিন্দু থেকে পেতে, আপনি একটি খুব সুন্দর-জ্ঞানের উপায়ে আপনার কার্যকারিতা বিভক্ত থাকতে হবে, কিন্তু যে কি SRP সম্পর্কে নয় - করছেন যে চাবি ধারণা উপেক্ষা করে সংসক্তিপ্রবণতা

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

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

একই কারণে পরিবর্তিত জিনিসগুলি একত্রিত করুন । বিভিন্ন কারণে পরিবর্তিত সেই জিনিসগুলি আলাদা করুন।

(জোর আমার)। SRP হয় না ক্ষুদ্রতম সম্ভব টুকরা আপ বিভাজন জিনিস সম্পর্কে। এটি ভাল নকশা নয় এবং আপনার দলটি প্রতিরোধ করা ঠিক। এটি আপনার কোড বেসকে আপডেট করা এবং বজায় রাখা আরও শক্ত করে তোলে। দেখে মনে হচ্ছে আপনি ইউনিট পরীক্ষার বিবেচনার ভিত্তিতে আপনার দলটি এটির উপর বিক্রি করার চেষ্টা করছেন তবে এটি ঘোড়ার আগে কার্টটি রাখবে।

একইভাবে, ইন্টারফেস পৃথককরণের নীতিটিকে পরম হিসাবে গ্রহণ করা উচিত নয়। আপনার কোডটি এসআরপি-র তুলনায় এত সূক্ষ্মভাবে বিভাজন করার কোনও কারণ নয় এবং এটি সাধারণত এসআরপি-র সাথে খুব ভালভাবে সারিবদ্ধ হয়। ইন্টারফেসে এমন কিছু পদ্ধতি রয়েছে যা কিছু ক্লায়েন্ট ব্যবহার করে না এটি ভেঙে ফেলার কারণ নয়। আপনি আবার সংহতি খুঁজছেন।

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


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

3
আবার, @ জেডিডিভিস, কেবলমাত্র পরীক্ষার যোগ্যতার জন্য একের অধিক ক্লাস বেছে নেওয়া ঘোড়ার সামনে কার্টটি রেখে দেওয়া হয়েছে এবং এটি সরাসরি এসআরপি-র বিরুদ্ধে চলে যায়, যা একত্রে সমন্বিত কার্যকারিতা গোষ্ঠীকরণের আহ্বান জানিয়েছিল। আমি আপনাকে বিশদ সম্পর্কিত পরামর্শ দিতে পারছি না, তবে স্বতন্ত্র ক্রিয়ামূলক পরিবর্তনগুলির জন্য অনেকগুলি ফাইল সংশোধন করা দরকার এমন একটি সমস্যা যা আপনার মোকাবেলা করা উচিত (এবং এড়াতে চাইছেন), এমন একটি নয় যা আপনাকে ন্যায়সঙ্গত করার চেষ্টা করা উচিত।
জন বলিঞ্জার

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

12

যে টাস্কগুলিতে 5-10 ফাইল নেওয়া হত এখন 70-100 লাগতে পারে!

এটি একটি মিথ্যা. কার্যগুলি কেবল 5-10 ফাইলই নেয় নি।

আপনি 10 টিরও কম ফাইল দিয়ে কোনও কাজ সমাধান করছেন না। কেন? কারণ আপনি সি # ব্যবহার করছেন। সি # একটি উচ্চ স্তরের ভাষা। আপনি হ্যালো ওয়ার্ল্ড তৈরি করতে আপনি 10 টিরও বেশি ফাইল ব্যবহার করছেন।

ওহ নিশ্চিত যে আপনি সেগুলি খেয়াল করেন না কারণ আপনি তাদের লেখেন নি। সুতরাং আপনি তাদের মধ্যে তাকান না। আপনি তাদের বিশ্বাস।

সমস্যাটি ফাইল সংখ্যা নয়। আপনার এখন এতটা চলছে যে আপনি বিশ্বাস করেন না।

সুতরাং এই পরীক্ষাগুলি কীভাবে কার্যনির্বাহী তা নির্ধারণ করুন যে একবার তারা পাস করার পরে আপনি এই ফাইলগুলিকে NET- তে যেভাবে ফাইলগুলিতে বিশ্বাস করেন সেইভাবে trust ইউনিট টেস্টিংয়ের বিষয়টি তা করা। কেউ ফাইলের সংখ্যা সম্পর্কে চিন্তা করে না। তারা নির্ভর করতে পারে না এমন কতগুলি বিষয় তারা যত্নশীল।

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

পরিবর্তনগুলি খুব বড় আকারের অ্যাপ্লিকেশনগুলিতে কঠোর হয় আপনি যা করেন তা কোনও ম্যাটর নয়। এখানে প্রয়োগ করার সবচেয়ে ভাল জ্ঞান চাচা বব থেকে আসে না। এটি লিগ্যাসি কোড সহ কার্যকরীভাবে তাঁর বইয়ে মাইকেল পালকের কাছ থেকে এসেছে।

পুনর্লিখন ফেস্ট শুরু করবেন না। পুরানো কোডটি হার্ড উইন্ডোজ জ্ঞানের প্রতিনিধিত্ব করে। এটি টস আউট করায় কারণ এতে সমস্যা রয়েছে এবং এটি নতুন এবং উন্নত দৃষ্টান্তে প্রকাশিত হয়নি এক্স কেবল নতুন সেট সমস্যার জন্য জিজ্ঞাসা করছেন এবং কোনও শক্ত বিজয়ী জ্ঞান নেই।

পরিবর্তে আপনার পুরানো অকেটেস্টেবল কোড পরীক্ষারযোগ্য করার জন্য উপায়গুলি আবিষ্কার করুন (পালকের ভাষায় লিগ্যাসি কোড)। এই রূপক কোডটি শার্টের মতো। বৃহত্তর অংশগুলি প্রাকৃতিক seams এ যোগদান করেছে যা আপনি যেভাবে seams মুছে ফেলবেন সেভাবে কোডটি পৃথক করতে পারে না। আপনাকে পরীক্ষা "স্লিভস" সংযুক্ত করার অনুমতি দেওয়ার জন্য এটি করুন যা আপনাকে বাকী কোডটি বিচ্ছিন্ন করতে দেয়। এখন আপনি যখন পরীক্ষার হাতা তৈরি করেন তখন আপনার হাতাতে আস্থা থাকে কারণ আপনি একটি ওয়ার্কিং শার্ট দিয়ে এটি করেছিলেন did (বাহ, এই রূপকটি আঘাত পেতে শুরু করছে)।

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

এর কোনওটির সাথে কী সম্পর্ক রয়েছে:

সলআইডিতে স্যুইচ করার পরে ব্যাপক বর্ধিত ক্লাস পরিচালনা ও পরিচালনা করছেন?

বিমূর্ততা।

আপনি খারাপ অ্যাস্ট্রাকশন সহ যে কোনও কোড বেসকে ঘৃণা করতে পারেন। একটি খারাপ বিমূর্ততা এমন একটি জিনিস যা আমাকে ভিতরে দেখতে look আমি ভিতরে তাকালে আমাকে অবাক করবেন না। আমি যা প্রত্যাশা করছিলাম তা অনেক সুন্দর হয়ে উঠুন।

আমাকে একটি ভাল নাম দিন, পঠনযোগ্য পরীক্ষা (উদাহরণ) যা ইন্টারফেসটি কীভাবে ব্যবহার করতে হয় তা দেখায় এবং এটি সংগঠিত করে যাতে আমি জিনিসগুলি খুঁজে পেতে পারি এবং যদি আমরা 10, 100 বা 1000 ফাইল ব্যবহার করি তবে আমি যত্ন নেব না।

আপনি ভাল বর্ণনামূলক নামের সাথে জিনিসগুলি খুঁজতে আমাকে সহায়তা করুন। ভাল নাম দিয়ে জিনিসগুলিতে ভাল নাম রাখুন।

আপনি যদি এই সমস্ত কিছু সঠিকভাবে করেন তবে আপনি কেবলমাত্র 3 থেকে 5 টি ফাইলের উপর নির্ভর করে কোনও কাজ শেষ করার সাথে সাথে ফাইলগুলি বিমূর্ত করবেন। 70-100 ফাইল এখনও আছে। তবে তারা 3 থেকে 5 এর আড়ালে লুকিয়ে রয়েছে এটি কেবল তখনই কাজ করে যদি আপনি 3 থেকে 5 টি সঠিকভাবে কাজ করতে বিশ্বাস করেন।

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

@ ডেলিওথ ক্রমবর্ধমান ব্যথা সম্পর্কে একটি ভাল বক্তব্য রাখে । আপনি যখন ডিশ ওয়াশারের উপরে আলমারিতে থাকা খাবারগুলি অভ্যস্ত হন তখন নাস্তা দণ্ডের ওপরে থাকার জন্য কিছুটা অভ্যস্ত হয়ে যায়। কিছু জিনিস শক্ত করে তোলে। কিছু জিনিস সহজ করে তোলে। তবে খাবারগুলি যেখানে যায় সেখানে লোকেরা রাজি না হলে এটি সমস্ত ধরণের দুঃস্বপ্নের কারণ হয়। একটি বৃহত কোড বেসে সমস্যা হ'ল আপনি একবারে কেবল কিছু খাবার রান্না করতে পারেন। সুতরাং এখন আপনি দুটি জায়গায় থালা - বাসন আছে। এটা বিভ্রান্তিকর. এটি বিশ্বাস করা শক্ত করে তোলে যে থালাভোজনাগুলি যেখানে রয়েছে বলে মনে করা হচ্ছে। আপনি যদি এটি অতীত করতে চান তবে কেবল একমাত্র কাজটি হ'ল থালা বাসনগুলি সরানো।

এই সমস্যাটি হ'ল আপনি যদি সত্যিই জানতে চান যে প্রাতঃরাশের বারের উপর থালা বাসনগুলি রাখার পক্ষে এই সমস্ত বাজে কথা বলার আগে তা মূল্যবান কিনা। ভাল যে জন্য আমি সুপারিশ করতে পারেন সব শিবির যেতে।

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

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


3
এটি উল্লেখ করার মতো হতে পারে যে প্রশ্নের কিছুটা ব্যথা সম্ভবত কেবল বেড়ে যাওয়ার ব্যথাও রয়েছে - তবে হ্যাঁ, তাদের এই একটি জিনিসের জন্য 15 টি ফাইল তৈরি করতে হতে পারে ... এখন তাদের আর কোনও জিইউইডিপিপ্রাইডার বা কোনও বেসপ্যাথপ্রোভাইডার লিখতে হবে না now , বা একটি এক্সটেনশনপ্রাইডার ইত্যাদি you আপনি নতুন গ্রিনফিল্ড প্রকল্প শুরু করার সময় আপনি একই ধরণের প্রতিবন্ধকতা তৈরি করেন - সমর্থনযোগ্য বৈশিষ্ট্যগুলির গুচ্ছ যা বেশিরভাগ ক্ষেত্রে তুচ্ছ, বোকামি, এবং এখনও লেখার দরকার পড়ে। এগুলি তৈরি করতে ব্যর্থ হয়, তবে তারা একবার সেখানে গেলে আপনার তাদের সম্পর্কে কখনও ভাবার দরকার নেই।
16-17

@ ডেলিওথ আমি বিশ্বাস করতে অবিশ্বাস্যভাবে ঝুঁকছি এই ঘটনাটি। পূর্বে, যদি আমাদের কার্যকারিতার কিছু উপসেটের প্রয়োজন হয় (আসুন আমরা বলতে পারি যে আমরা কেবল অ্যাপসেটিংগুলিতে একটি ইউআরএল চাইছিলাম), আমাদের কেবল একটি বৃহত শ্রেণি ছিল যা চারপাশে পাস এবং ব্যবহৃত হয়েছিল। নতুন পদ্ধতির সাথে, AppSettingsকেবল একটি ইউআরএল বা ফাইলের পাথ পাওয়ার জন্য পুরোপুরি অতিক্রম করার কোনও কারণ নেই ।
জেডি ডেভিস

1
পুনর্লিখন ফেস্ট শুরু করবেন না। পুরানো কোডটি হার্ড উইন্ডোজ জ্ঞানের প্রতিনিধিত্ব করে। এটি টস আউট করায় কারণ এতে সমস্যা আছে এবং এটি নতুন এবং উন্নত দৃষ্টান্তে প্রকাশিত হয়নি এক্স কেবল নতুন সেট সমস্যার জন্য জিজ্ঞাসা করছেন এবং কোনও শক্ত বিজয়ী জ্ঞান নেই। এই. একেবারে।
ফ্লোট ২০১১

10

দেখে মনে হচ্ছে আপনার কোডটি খুব ভাল ডিকোপলড নয় এবং / বা আপনার টাস্কের আকারগুলি অনেক বড়।

কোড পরিবর্তনগুলি 5-10 ফাইল হওয়া উচিত যদি না আপনি কোডমড বা বড় আকারের রিফ্যাক্টরিং করছেন। যদি একক পরিবর্তনটি অনেকগুলি ফাইলকে স্পর্শ করে তবে এর অর্থ সম্ভবত আপনার পরিবর্তনগুলি ক্যাসকেড। কিছু উন্নত বিমূর্ততা (আরও একক দায়িত্ব, ইন্টারফেস বিভাজন, নির্ভরতা বিপরীতে) সহায়তা করা উচিত। এছাড়া সম্ভব আপনি হয়তো গিয়েছিলাম খুব একক দায়িত্ব এবং একটি বিট আরো প্রয়োগবাদ ব্যবহার করতে পারে - ছোট অথবা পাতলা টাইপ শ্রেণীবিন্যাসের। কোডটি খুব সহজে বোঝা উচিত যেহেতু কোডটি কী করছে তা জানতে আপনার কয়েক ডজন ফাইল বুঝতে হবে না।

এটি আপনার লক্ষণ খুব বড় যে একটি চিহ্ন হতে পারে। "আরে, এই বৈশিষ্ট্যটি যুক্ত করুন" এর পরিবর্তে (যার জন্য ইউআই পরিবর্তন এবং এপিআই পরিবর্তন এবং ডেটা অ্যাক্সেস পরিবর্তন এবং সুরক্ষা পরিবর্তন এবং পরীক্ষার পরিবর্তন এবং ...) এটিকে আরও বেশি সেবাযোগ্য অংশে বিভক্ত করে। এটি পর্যালোচনা করা সহজ এবং বুঝতে সহজ হয় কারণ এর জন্য আপনাকে বিটের মধ্যে শালীন চুক্তি স্থাপন করতে হবে।

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


2
5-10 ফাইল থেকে 70-100 ফাইল একটি অনুমানের চেয়ে কিছুটা বেশি। আমার শেষ কাজটি ছিল আমাদের একটি নতুন মাইক্রোসার্চিসে কিছু কার্যকারিতা তৈরি করা। নতুন পরিষেবাটির জন্য একটি অনুরোধ গ্রহণ করা এবং একটি দস্তাবেজ সংরক্ষণ করার কথা ছিল। এটি করার জন্য, প্রত্যেকের জন্য 2 টি পৃথক ডেটাবেস এবং রেপোগুলিতে ব্যবহারকারী সত্তাদের উপস্থাপন করার জন্য আমার ক্লাস প্রয়োজন। আমার লিখতে হবে এমন অন্যান্য সারণীর প্রতিনিধিত্ব করতে রেপস। ফাইল-ডেটা চেকিং এবং নাম উত্পন্নকরণ পরিচালনা করতে উত্সর্গীকৃত ক্লাস। এবং তালিকাতে আরও অনেক কিছুই আছে. উল্লেখ করার মতো নয়, যুক্তিযুক্ত প্রতিটি শ্রেণি একটি ইন্টারফেস দ্বারা প্রতিনিধিত্ব করা হত যাতে এটি ইউনিট পরীক্ষার জন্য উপহাস করা যায়।
জেডি ডেভিস

1
আমাদের পুরানো কোডবেসগুলি হিসাবে, এগুলি সমস্ত দৃ coup়ভাবে সংযুক্ত এবং অবিশ্বাস্যরকম একতরফা। SOLID পদ্ধতির সাথে, ক্লাসগুলির মধ্যে একমাত্র মিলনটি POCOs এর ক্ষেত্রে হয়েছে, বাকি সমস্ত কিছুই ডিআই এবং ইন্টারফেসের মধ্য দিয়ে যায়।
জেডি ডেভিস

3
@ জেডিডিভিস - অপেক্ষা করুন, কেন একটি মাইক্রোসার্ভিস সরাসরি একাধিক ডাটাবেসের সাথে কাজ করছে?
টেলাস্টিন

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

4

আমি এখানে ইতিমধ্যে উল্লিখিত কিছু বিষয়গুলিতে ব্যাখ্যা করতে চাই, তবে যেখানে অবজেক্টের সীমানা আঁকা হয়েছে তার দৃষ্টিকোণ থেকে আরও অনেক কিছু। আপনি যদি ডোমেন-চালিত ডিজাইনের অনুরূপ কিছু অনুসরণ করছেন তবে আপনার অবজেক্টগুলি সম্ভবত আপনার ব্যবসায়ের দিকগুলি উপস্থাপন করতে চলেছে। Customerএবং Order, উদাহরণস্বরূপ, বস্তু হতে হবে। এখন, আমি যদি আপনার প্রারম্ভিক পয়েন্ট হিসাবে ক্লাসের নামগুলির উপর ভিত্তি করে অনুমান করি তবে আপনার AccountLogicক্লাসে এমন কোড রয়েছে যা কোনও অ্যাকাউন্টের জন্য চলবে । ওওতে, প্রতিটি শ্রেণি বোঝায় প্রসঙ্গ এবং পরিচয়। আপনার কোনও Accountবস্তু পাওয়া উচিত নয় এবং তারপরে এটি একটি AccountLogicশ্রেণিতে পাস করা উচিত এবং সেই শ্রেণিটি Accountঅবজেক্টে পরিবর্তন আনতে হবে । এটিকেই অ্যানিমিক মডেল বলা হয় এবং এটি ওওকে খুব ভালভাবে উপস্থাপন করে না। পরিবর্তে, আপনারAccountশ্রেণীর আচরণ যেমন, Account.Close()বা হওয়া উচিত Account.UpdateEmail()এবং সেই আচরণগুলি অ্যাকাউন্টের কেবলমাত্র সেই উদাহরণটিকেই প্রভাবিত করে।

এখন, কীভাবে এই আচরণগুলি পরিচালনা করা হয় (এবং অনেক ক্ষেত্রে হওয়া উচিত) অ্যাবস্ট্রাকশনগুলি (যেমন ইন্টারফেস) দ্বারা প্রতিনিধিত্বশীল নির্ভরতাগুলিতে অফ-লোড হওয়া যায়। Account.UpdateEmailউদাহরণস্বরূপ, কোনও ডাটাবেস, বা একটি ফাইল আপডেট করতে বা কোনও সার্ভিস বাসে একটি বার্তা প্রেরণ করতে পারে ইত্যাদি And ভবিষ্যতে এটি পরিবর্তন হতে পারে। সুতরাং আপনার Accountশ্রেণীর উপর নির্ভরতা থাকতে পারে, উদাহরণস্বরূপ, একটি IEmailUpdate, যা কোনও AccountRepositoryঅবজেক্ট দ্বারা প্রয়োগ করা অনেক ইন্টারফেসগুলির মধ্যে একটি হতে পারে । আপনি সামগ্রীতে একটি পুরো IAccountRepositoryইন্টারফেসটি পাস করতে চাইবেন না Accountকারণ এটি সম্ভবত খুব বেশি করবে যেমন যেমন অনুসন্ধান এবং অন্যান্য (কোনও) অ্যাকাউন্ট সন্ধান করা, যা আপনি Accountঅবজেক্টটিতে অ্যাক্সেস পেতে চান না , তবে এটি AccountRepositoryউভয়ই বাস্তবায়ন করতে পারে IAccountRepositoryএবং IEmailUpdateইন্টারফেস,Accountঅবজেক্টটির কেবলমাত্র প্রয়োজনীয় ছোট অংশগুলিতে অ্যাক্সেস থাকবে। এটি আপনাকে ইন্টারফেস বিভাজন নীতি বজায় রাখতে সহায়তা করে ।

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

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


2

সুতরাং মোট 15 টি ক্লাস (পিওসিও এবং স্ক্যাফোल्डিং বাদে) মোটামুটি সরল সাফল্য সঞ্চালনের জন্য।

পাগল .... তবে এই ক্লাসগুলি এমন কিছু শোনাচ্ছে যা আমি নিজে লিখি। সুতরাং আসুন তাদের এক নজর দেওয়া যাক। আপাতত ইন্টারফেস এবং পরীক্ষা উপেক্ষা করা যাক।

  • BasePathProvider- আইএমএইচও ফাইলগুলির সাথে কাজ করা কোনও তুচ্ছ প্রকল্পের এটি প্রয়োজন। সুতরাং আমি ধরে নিই, ইতিমধ্যে এমন কিছু আছে এবং আপনি এটি যেমনটি ব্যবহার করতে পারেন।
  • UniqueFilenameProvider - অবশ্যই, আপনি এটি ইতিমধ্যে আছে, তাই না?
  • NewGuidProvider - একই ক্ষেত্রে, যদি না আপনি কেবল জিইউইডি ব্যবহার শুরু করেন।
  • FileExtensionCombiner - একই মামলা।
  • PatientFileWriter - আমার ধারণা, এটি বর্তমান কাজের মূল ক্লাস।

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


পরীক্ষার ক্লাস সম্পর্কিত, অবশ্যই, যখন আপনি একটি নতুন ক্লাস তৈরি করেন বা আপডেট করেন, এটি পরীক্ষা করা উচিত। সুতরাং পাঁচটি ক্লাস লেখার অর্থ পাঁচটি পরীক্ষার ক্লাসও লেখা। তবে এটি নকশাটিকে আরও জটিল করে তোলে না:

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

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


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

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

@ জেডিডাভিস এবং সমস্ত কিছুই আপনার সরঞ্জামগুলির মানের উপর নির্ভর করে। উদাহরণ: এমন লোকেরা আছে যে দাবি করছে যে ডিআই এন্টারপ্রাইজ এবং জটিল, আমি দাবি করছি যে এটি বেশিরভাগই বিনামূল্যে+++নিয়ম ভাঙার বিষয়ে: এখানে চারটি ক্লাস রয়েছে, আমার জায়গাগুলিতে প্রয়োজন, যেখানে কোডটি আরও কুশ্রী তৈরি করার জন্য আমি কেবলমাত্র তাদের সংশোধন করতে পারলাম (কমপক্ষে আমার চোখের জন্য), তাই আমি তাদের সিদ্ধান্ত নিয়েছিলাম সিলেটনে পরিণত করার জন্য (আরও ভাল প্রোগ্রামার) আরও ভাল উপায় খুঁজে পেতে পারে, তবে আমি এতে সন্তুষ্ট; যুগে যুগে এই একক সিলেটের সংখ্যা পরিবর্তিত হয়নি)।
মার্টিনাস

এই উত্তরটি যখন ওপি প্রশ্নের উদাহরণটিতে উদাহরণ যুক্ত করেছিল তখন আমি কী ভাবছিলাম তা প্রকাশিত করে। @ জেডিডিভিস আমাকে যোগ করতে দিন যে আপনি সহজ ক্ষেত্রে কার্যকরী সরঞ্জাম ব্যবহার করে কিছু বয়লারপ্লিট কোড / ক্লাস সংরক্ষণ করতে পারেন। একটি জিইউআই সরবরাহকারী, উদাহরণস্বরূপ - নতুন ইন্টারফেসটির জন্য এটির জন্য একটি নতুন ক্লাস চালু করার পরিবর্তে কেন কেবল এটির জন্য ব্যবহার Func<Guid>করবেন না এবং নির্মাতাদের মতো বেনাম পদ্ধতিতে ইনজেক্ট করবেন না কেন ()=>Guid.NewGuid()? এবং এটি পরীক্ষা করার দরকার নেই। নেট ফ্রেমওয়ার্ক ফাংশন, এটি মাইক্রোসফ্ট আপনার জন্য কিছু করেছে। মোট, এটি আপনাকে 4 টি ক্লাস বাঁচাবে।
ডক ব্রাউন

... এবং আপনার উপস্থাপন করা অন্যান্য মামলাগুলিও একইভাবে সরল করা যেতে পারে কিনা তা সম্ভবত পরীক্ষা করা উচিত (সম্ভবত সবগুলিই নয়)।
ডক ব্রাউন

2

বিমূর্তনের উপর নির্ভর করে, একক-দায়িত্বের ক্লাস তৈরি করা এবং ইউনিট পরীক্ষাগুলি লেখাই সঠিক বিজ্ঞান নয়। শেখার সময় একদিকে খুব বেশি দুলতে চলা একেবারে স্বাভাবিক, চূড়ান্ত দিকে যান এবং তারপরে এমন একটি আদর্শ খুঁজে পান যা অর্থবোধ করে। আপনার পেন্ডুলামটি খুব বেশি দুলিয়ে গেছে বলে মনে হচ্ছে, এবং এটি আটকেও থাকতে পারে।

আমি এখানে সন্দেহ করি যেখানে এটি রেল বন্ধ করে দিচ্ছে:

ইউনিট পরীক্ষাগুলি দলে একটি অবিশ্বাস্যভাবে কঠোর বিক্রয় হয়েছে কারণ তারা সকলেই বিশ্বাস করে যে তারা সময় নষ্ট করে এবং তারা পৃথকভাবে প্রতিটি টুকরো থেকে পুরোপুরি তাদের কোডটি হ্যান্ডেল-টেস্ট করতে সক্ষম। সলিডের পক্ষে প্রস্তাব হিসাবে ইউনিট পরীক্ষাগুলি ব্যবহার করা বেশিরভাগ ক্ষেত্রে নিরর্থক এবং বেশিরভাগ সময়েই এটি একটি রসিকতায় পরিণত হয়েছে।

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

যদি আপনার দল ইউনিট পরীক্ষা লিখছে না, তবে দুটি সম্পর্কিত জিনিস ঘটছে:

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

উদাহরণস্বরূপ, যখন তাদের রিফ্যাক্টর প্রয়োজন হয় তখন কী ঘটে? যদি তারা একশো ছোট্ট ক্লাস পেয়ে থাকে তবে তাদের পরিবর্তনগুলি কার্যকর হবে কি না তা জানানোর জন্য কোনও পরীক্ষা না করে, সেই অতিরিক্ত ক্লাস এবং ইন্টারফেসগুলি বোঝা হিসাবে দেখাবে, কোনও উন্নতি নয়।

দ্বিতীয়ত, ইউনিট পরীক্ষাগুলি লেখার মাধ্যমে আপনার কোডটি আসলে কী বিমূর্ততার প্রয়োজন তা বুঝতে আপনাকে সহায়তা করতে পারে। যেমনটি আমি বলেছিলাম, এটি কোনও বিজ্ঞান নয়। আমরা খারাপভাবে শুরু করি, পুরো জায়গা জুড়ে ঘোরাঘুরি করি এবং আরও ভাল get ইউনিট পরীক্ষায় সোলিড পরিপূরক করার এক অদ্ভুত উপায় রয়েছে। আপনি কীভাবে জানবেন যখন আপনাকে কোনও বিমূর্ততা যুক্ত করতে হবে বা কিছু আলাদা করতে হবে? অন্য কথায়, আপনি কীভাবে জানবেন যখন আপনি "যথেষ্ট পরিমাণে স্বল্প"? প্রায়শই উত্তরটি যখন আপনি কোনও কিছু পরীক্ষা করতে পারবেন না।

হয়তো আপনার কোডটি এত ছোট ছোট বিমূর্ততা এবং ক্লাস না তৈরি করে পরীক্ষাযোগ্য হবে। আপনি যদি পরীক্ষা না লিখে থাকেন তবে কীভাবে বলতে পারেন? আমরা কতদূর যেতে পারি? আমরা ছোট এবং ছোট জিনিসগুলি ভেঙে আবেশে পরিণত হতে পারি। এটি একটি খরগোশের গর্ত। আমাদের কোডের জন্য পরীক্ষার লেখার দক্ষতা আমাদের লক্ষ্যটি কার্যকর করতে সক্ষম হতে সাহায্য করে যাতে আমরা অধিষ্ঠিত হওয়া বন্ধ করে দিতে পারি, আরও কোড লিখতে মজা করতে পারি।

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

তার উপরে, একবার আমরা এটির হ্যাঙ্গ পেয়ে গেলে ইউনিট পরীক্ষাগুলি লেখার ফলে কোড বিকাশমান দ্রুত হয়, ধীর হয় না। খড়ের খড়ের সূঁচের মতো সমস্যাগুলি খুঁজতে আমরা পুরানো কোডটি পুনর্বিবেচনা করতে বা ডিবাগিংয়ে কম সময় ব্যয় করি।

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

স্যুইচটি তৈরি করার পরে, বিকাশকারীদের কাছ থেকে সবচেয়ে বড় অভিযোগ হ'ল তারা পিয়ার পর্যালোচনা এবং কয়েক ডজন এবং কয়েক ডজন ফাইল ট্র্যাভার করে দাঁড়াতে পারবেন না যেখানে আগে প্রতিটি কার্যেই কেবল বিকাশকারীকে 5-10 ফাইল স্পর্শ করা প্রয়োজন।

পিয়ার পর্যালোচনা অনেক সহজ যখন ইউনিট পরীক্ষার সমস্ত পাস করে এবং সেই পর্যালোচনার একটি বড় অংশ পরীক্ষার অর্থবহ তা নিশ্চিত করে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.