সফ্টওয়্যার প্রকল্পে দুর্ঘটনাজনিত জটিলতা কীভাবে পরিচালনা করবেন


74

যখন মারে জেল-মানকে জিজ্ঞাসা করা হয়েছিল যে রিচার্ড ফেনম্যান কীভাবে এতগুলি কঠিন সমস্যা সমাধান করতে পেরেছেন জেল-মান জেনার করেছিলেন যে ফেনম্যানের একটি অ্যালগোরিদম রয়েছে:

  1. সমস্যা লিখুন।
  2. সত্যিকারের কঠিন চিন্তা করুন।
  3. সমাধান লিখুন।

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

তাহলে কি দুর্ঘটনাজনিত জটিলতা পরিচালনার একমাত্র উপায় ফেনম্যান অ্যালগরিদম বা দুর্ঘটনাজনিত জটিলতায় নিয়ন্ত্রণের জন্য সফটওয়্যার ইঞ্জিনিয়াররা ধারাবাহিকভাবে প্রয়োগ করতে পারেন এমন কোন আসল পদ্ধতি রয়েছে?


32
সমস্যাটি লেখার কাজটি (এবং এটির উপর চাপ দেওয়ার জন্য যাতে আপনি অন্য কাউকে পর্যাপ্তরূপে এটি ব্যাখ্যা করতে পারেন) আপনাকে সমাধানটি সনাক্ত করতে সহায়তা করলে আমি অবাক হব না।
ররি হান্টার

@ ররিহান্টার - একমত এবং সমস্যাটি লেখার এবং কারও সাথে ভাগ করে নেওয়ার অংশটি আপনাকে বোঝায় যে আপনার কাছে এখনও কোনও সমাধান নেই have
জেফো

38
@ ররিহান্টার: এটি। প্রায় সাপ্তাহিক, আমি এমন একটি সমস্যার মুখোমুখি হয়েছি যা আমি সমাধান করতে পারি না, এটি ব্যাখ্যা করার জন্য কাউকে ইমেল লিখুন। তারপরে এটি কী তা আমি বিবেচনা করছি না, সমস্যাটি সমাধান করুন এবং ইমেলটি মুছুন realize আমি এই সাইটে প্রায় এক ডজন প্রশ্ন লিখেছি যা কখনই পাঠানো হয়নি।
পিডিআর

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

2
@ কর্টআ্যামমনটি বোঝার কথা নয় তবে এটি বেশ বোবা অন্তর্দৃষ্টি বলে মনে হচ্ছে। বিকাশকারীরা যা জানেন তা 99% আপনার তথাকথিত 'অন-ফ্লাই গ্রোথ' এর মাধ্যমে কোনও এক সময়ে শিখেছিল। একটি ভাল প্রোগ্রামার তৈরি করতে এটি একটি ভাল সমস্যা সমাধানকারী লাগে। সমস্যার সমাধান হ'ল এমন কিছু যা আমরা সহজাতভাবে আকৃষ্ট করি। যদি আপনার বিকাশকারীদের বিকাশ না হয় তবে তারা সম্ভবত প্রচুর বিরক্তিকর পুনরাবৃত্তিমূলক কাজ করছেন। কাজের ধরণ যা কোনও যুক্তিযুক্ত মেধাবী বিকাশকারীকে অসন্তুষ্ট এবং হতাশ করে তুলবে। এবং ... 'সর্পিল বিকাশ' জলপ্রপাতের মাইলফলক সহ পুনরাবৃত্তি বিকাশের মৌলিক ধারণার পুনর্বার হাশিং ছাড়া কিছুই নয়।
ইভান প্লেস

উত্তর:


104

আপনি যখন একটি ভাল পদক্ষেপ দেখেন, তখন আরও ভাল একটি সন্ধান করুন।
Manমানুয়েল লস্কর, ২ 27 বছরের বিশ্ব দাবা চ্যাম্পিয়ন

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

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

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

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


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

1
TL; ড; রিফ্যাক্টর, ভীত হই
অক্টোডো

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

46

"সফ্টওয়্যার আর্কিটেকচার দক্ষতা শেখানো যায় না" এটি একটি বিস্তৃত মিথ্যাচার।

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

আমি দৃly়ভাবে বিশ্বাস করি যে বৃহত সিস্টেমগুলি পুনর্বার অনুশীলন করা এবং অভিজ্ঞান থেকে একইভাবে শেখা যেভাবে একজন মহান সংগীতশিল্পী বা পাবলিক স্পিকার হয়ে ওঠার পক্ষে সংবেদনশীল: ন্যূনতম পরিমাণ প্রতিভা একটি পূর্বশর্ত, তবে এটি হতাশাজনকভাবে বিশাল ন্যূনতম নয় যা বাইরে নেই that সর্বাধিক অনুশীলনকারীদের নাগাল।

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


11
আমি আপনার শেষ বাক্যটি সত্যিই পছন্দ করি। আমি ইতিবাচক আমি আমার প্রথম চাকরীতে অনেক কিছু শিখেছিলাম কারণ আমার ভুলগুলি আমার সাথে ধরার জন্য আমি যথেষ্ট ছিলাম। এটি একটি মূল্যবান অভিজ্ঞতা।
মেটাফাইট

26
"ভাল রায় অভিজ্ঞতা থেকে আসে। অভিজ্ঞতা খারাপ সিদ্ধান্ত থেকে আসে।"
জোনাস কুলকার

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

4
মুল বক্তব্যটি হ'ল প্রচুর লোকেরা দাবি করেছেন যে অনেক লোক একেবারে, যে কোনও পরিস্থিতিতে ভাল স্থপতি হতে শিখতে পারে না (কোনও বক্তৃতা ঘরে হোক বা শিল্পে হোক), কারণ তারা "যা নেয় তা পায়নি"। এটাকে আমি সাধারণ তবে মিথ্যা বলে বিবেচনা করি।
কিলিয়ান ফট

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

22

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

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

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

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

কর্মক্ষেত্রের এই প্রশ্নটি প্রাসঙ্গিক এবং আইএমএইচও এই প্রসঙ্গে পড়তে আগ্রহী হবে।


3
বিশেষজ্ঞরা কীভাবে ভাবেন তার দুর্দান্ত বর্ণনা। এটি সত্যই যাদু নয়, সমস্ত বিযুক্ত এবং যৌক্তিক পদক্ষেপটি ব্যাখ্যা করা কেবল শক্ত।
মেটাফাইট


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

1
@ ডাঙ্ক, ম্যাজিক তখন হবে যখন এই "অভিজাত" অ্যাথলিটরা কোনও প্রশিক্ষণ ছাড়াই একই রকম পারফর্ম করতে পারে। মূল ধারণাটি হ'ল কোনও রূপালী বুলেট নেই। যতই প্রতিভাধর হোক না কেন, কিছু "বিযুক্ত ও যৌক্তিক পদক্ষেপ" কেবল অধ্যয়ন করে অভিজ্ঞতা অর্জন করা যায় না। যাইহোক, একই বই অনুসারে, শুধুমাত্র 1-5% লোক বিশেষজ্ঞ।
সুপারমোহর

@ সুপার: আমি এমন কোনও বই / অধ্যয়নকে প্রশ্ন করব যা এইরকম হাস্যকর দাবি করেছে যেহেতু কেবলমাত্র 1-5% মানুষ বিশেষজ্ঞ। তাদের # & # & $ # এর মধ্যে একটি নম্বর টান দেওয়ার বিষয়ে কথা বলুন। বিশেষজ্ঞরা কিসের? আমি বাজি ধরেছি যে এখানে অনেক বেশি লোক রয়েছে যা শ্বাস, হাঁটা, খাওয়ার বিষয়ে বিশেষজ্ঞ। বিশেষজ্ঞের স্তর কী তা কে স্থির করে? 1-5% এর মতো দাবী এই জাতীয় লেখকদের আরও দাবী এবং বিশ্লেষণকে অমান্য করে।
ডাঙ্ক

4

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

আমার অনেক বড় বহুবর্ষের প্রকল্পের অভিজ্ঞতা আছে "দুর্ঘটনাজনক" উপাদানটি "অপরিহার্য" দিকটি উল্লেখযোগ্যভাবে ছাড়িয়েছিল, এবং এটি যেখানে ছিল না সেগুলিও ছিল।

প্রকৃতপক্ষে, ফেনম্যান অ্যালগরিদম কিছুটা ক্ষেত্রে প্রযোজ্য, তবে এর অর্থ এই নয় যে "সত্যিকারের শক্ত মনে করুন" অর্থ এমন একমাত্র যাদু যা কোড করা যায় না।

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

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

আরও ভাল আর্কিটেকচার কী হবে তার জন্য একটি পরিকল্পনা সংজ্ঞায়িত করুন এবং নিশ্চিত করুন যে নতুন কাজ সেই পরিকল্পনার সাথে সামঞ্জস্য করে - এটি বর্ধিত পদ্ধতির।

এছাড়াও, সমস্যার ব্যয়টি স্পষ্ট করে বলুন এবং একটি রিফ্যাক্টরটিকে ন্যায়সঙ্গত করতে ব্যবসায়ের কেস তৈরি করতে এটি ব্যবহার করুন। এখানে মূল বিষয়টি হ'ল একটি ভাল আর্কিটেক্ট সিস্টেমটি আরও কার্যকর এবং পরীক্ষামূলক হতে পারে ফলে পরিবর্তনের বাস্তবায়ন করতে অনেক কম সময় (ব্যয় এবং সময়সূচী) হতে পারে - এর আসল মূল্য রয়েছে।

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

যে কোনও পদ্ধতির অন্তর্নিহিত হ'ল "দুর্ঘটনাজনিত" কে "প্রয়োজনীয়" থেকে কীভাবে পৃথক করা যায় তা জানা - যা আপনার কাছে একজন দুর্দান্ত স্থপতি (বা স্থপতিদের দল) থাকা দরকার যা সিস্টেম এবং তার উদ্দেশ্য বুঝতে পারে understand

সব বলার পরেও, আমার কাছে মূল বিষয় হ'ল স্বয়ংক্রিয় পরীক্ষা । আপনার যদি এটির যথেষ্ট পরিমাণ থাকে তবে আপনার সিস্টেম নিয়ন্ত্রণে রয়েছে। আপনি যদি না। । ।


আপনি কী ব্যাখ্যা করতে পারেন যে কীভাবে স্বয়ংক্রিয় পরীক্ষণটি দুর্ঘটনাজনিত এবং প্রয়োজনীয় জটিলতার পার্থক্য করতে পারে?
ryscl

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

3

" সবকিছু যথাসম্ভব সহজ করা উচিত, তবে কোনও সহজ নয় no "
- অ্যালবার্ট আইনস্টাইনকে দায়ী করা হয়েছে

দুর্ঘটনাজনিত জটিলতা মোকাবেলার জন্য আমাকে আমার ব্যক্তিগত অ্যালগরিদম স্কেচ করতে দিন Let

  1. একটি ব্যবহারকারী গল্প লিখুন বা ব্যবহার ক্ষেত্রে। পণ্য মালিকের সাথে পর্যালোচনা।
  2. একটি ইন্টিগ্রেশন পরীক্ষা লিখুন যা ব্যর্থ হয়েছে কারণ বৈশিষ্ট্যটি নেই। আপনার দলে যদি এমন কিছু থাকে তবে QA, বা নেতৃত্ব প্রকৌশলী দিয়ে পর্যালোচনা করুন।
  3. কিছু শ্রেণীর জন্য ইউনিট পরীক্ষা লিখুন যা ইন্টিগ্রেশন পরীক্ষায় পাস হতে পারে।
  4. ইউনিট পরীক্ষায় পাস হওয়া ক্লাসগুলির জন্য ন্যূনতম বাস্তবায়ন লিখুন ।
  5. সহকর্মী বিকাশকারী সহ ইউনিট পরীক্ষা এবং বাস্তবায়ন পর্যালোচনা। পদক্ষেপ 3 এ যান।

পুরো ডিজাইনের যাদুটি 3 য় ধাপে থাকবে: আপনি কীভাবে এই ক্লাসগুলি সেট আপ করবেন? এটি একই প্রশ্নে পরিণত হয়: আপনি কীভাবে ভাববেন যে আপনার সমস্যার সমাধান হওয়ার আগে আপনার সমস্যার সমাধান রয়েছে?

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

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

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


2

দুর্ঘটনাজনিত জটিলতা

মূল প্রশ্নটি (প্যারাফ্রেসড) ছিল:

স্থপতিরা কীভাবে সফ্টওয়্যার প্রকল্পগুলিতে দুর্ঘটনাজনিত জটিলতা পরিচালনা করে?

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

দুর্ঘটনাজনিত জটিলতা নেতৃত্বের দ্বারা স্থির করা যেতে পারে যা কৌশলটি থেকে ইচ্ছাকৃতভাবে প্রস্থান হওয়া আপাতত প্রয়োজনীয় হয়ে ওঠার আগ পর্যন্ত তাদের মূল কৌশলকে আঁকড়ে ধরে।

অপ্রয়োজনীয় জটিলতা এড়ানো

প্রশ্নের মূলধারার উপর ভিত্তি করে, আমি এটি আবার পুনঃব্যবহার করব:

স্থপতিরা কীভাবে সফ্টওয়্যার প্রকল্পগুলিতে জটিলতা পরিচালনা করে?

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

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

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

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

সমাধান বিল্ডিং

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

নির্দিষ্ট চূড়ান্ত প্রশ্নে ফিরে যান:

দুর্ঘটনাজনিত জটিলতা নিয়ন্ত্রণের জন্য নির্দিষ্ট পদ্ধতিগুলি নিম্নলিখিত ধরণের উত্সগুলিতে পাওয়া যাবে।

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


"জিস্টাল্ট" বলতে কী বোঝ? আমি দেখতে পেয়েছি যে এটি অনেকটা "দৃষ্টান্ত" এর মতো - সাধারণত অপব্যবহার করা হয় বা কোনও কিছুকে একাডেমির বায়ু দিতেন।

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

0

কয়েক বছর আগে এটি একটি কঠিন প্রশ্ন হতে পারে তবে আজকাল দুর্ঘটনাজনিত জটিলতা দূর করা আইএমওর পক্ষে আর কঠিন নয়।

কেন্ট বেকসইড নিজেকে সম্পর্কে কী বলেছিলেন, এক পর্যায়ে: "আমি কোনও দুর্দান্ত প্রোগ্রামার নই; আমি দুর্দান্ত অভ্যাস সহ কেবল একজন ভাল প্রোগ্রামার mer"

দুটি বিষয় হাইলাইট করার যোগ্য, আইএমও: তিনি নিজেকে একজন প্রোগ্রামার হিসাবে বিবেচনা করেন , কোনও স্থপতি নয়, এবং তাঁর দৃষ্টিভঙ্গি অভ্যাসের দিকে, জ্ঞান নয়।

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

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

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

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

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