ভবিষ্যতে প্রয়োজনের প্রয়োজনে এখনই কি আমি রিডানড্যান্ট কোড যুক্ত করব?


114

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

উদাহরণস্বরূপ, আমি বর্তমানে এমন একটি মোবাইল অ্যাপ্লিকেশন নিয়ে কাজ করছি যাতে এই কোডটির এই অংশ রয়েছে:

public static CalendarRow AssignAppointmentToRow(Appointment app, List<CalendarRow> rows)
{
    //1. Is rows equal to null? - This will be the case if this is the first appointment.
    if (rows == null) {
        rows = new List<CalendarRow> ();
    }

    //2. Is rows empty? - This will be the case if this is the first appointment / some other unknown reason.
    if(rows.Count == 0)
    {
        rows.Add (new CalendarRow (0));
        rows [0].Appointments.Add (app);
    }

    //blah...
}

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

তবে, ভবিষ্যতে এমন একটি মামলা থাকতে পারে যেখানে এই দ্বিতীয় ifবিবৃতিটি সত্যই প্রয়োজন, এবং একটি জ্ঞাত কারণে।

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

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

এই ধরণের কোডের জন্য কোনও সাধারণ নিয়ম-নীতির নির্দেশিকা রয়েছে? (এটিকে ভাল বা খারাপ অনুশীলন হিসাবে বিবেচনা করা হবে কিনা তাও আমি শুনতে আগ্রহী?)

নোট: এটি এই প্রশ্নের অনুরূপ বিবেচনা করা যেতে পারে , তবে সেই প্রশ্নের বিপরীতে, আমি কোনও উত্তর নির্দিষ্ট সময়সীমা না বলে ধরে নিয়ে উত্তর চাই like

টিএলডিআর: ভবিষ্যতে সম্ভাব্য আরও শক্তিশালী করার জন্য আমার কি এলোমেলো কোড যুক্ত করা উচিত?



95
সফ্টওয়্যার বিকাশে এমন জিনিস যা কখনই ঘটে না।
রোমান রেইনার

34
যদি আপনি জানেন if(rows.Count == 0)যে কখনই ঘটবে না, তবে এটি হওয়ার পরে আপনি একটি ব্যতিক্রম বাড়াতে পারেন - এবং আপনার অনুমান কেন ভুল হয়ে গেছে তা পরীক্ষা করে দেখুন।
নট

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

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

উত্তর:


176

অনুশীলন হিসাবে প্রথমে আপনার যুক্তি যাচাই করা যাক। যদিও আমরা দেখতে পাব, আপনার যে কোনও যৌক্তিক সমস্যার চেয়ে বড় সমস্যা রয়েছে।

প্রথম শর্তটি এ এবং দ্বিতীয় শর্ত বি কে কল করুন B.

আপনি প্রথমে বলেছেন:

বিভাগ দুটি বিশেষভাবে খুঁজছেন, আমি জানি যে বিভাগটি যদি সত্য হয়, তবে বিভাগ দুটিও সত্য হবে।

এটি হ'ল: একটি খ বি বোঝায় বা আরও মূল শর্তে (NOT A) OR B

এবং তারপর:

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

যে: NOT((NOT A) AND B)। ডেমোরগানের আইন প্রয়োগ করুন (NOT B) OR Aযা বি বোঝায় এ।

অতএব, যদি আপনার উভয় বক্তব্য সত্য হয় তবে A সূচিত করে B এবং B এর A বোঝায়, যার অর্থ তারা অবশ্যই সমান হবে।

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

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

ঘোষণাটি দেখুন:

public static CalendarRow AssignAppointmentToRow(
    Appointment app,    
    List<CalendarRow> rows)

এটি সর্বজনীন, সুতরাং এটি নির্বিচারে কলকারীদের কাছ থেকে খারাপ ডেটা শক্ত হতে হবে।

এটি একটি মান প্রদান করে, সুতরাং এটির পার্শ্ব প্রতিক্রিয়ার জন্য নয়, এটির ফেরতের মূল্যের জন্য কার্যকর হওয়া উচিত।

এবং তবুও পদ্ধতির নামটি একটি ক্রিয়াপদ যা এটি এর পার্শ্ব প্রতিক্রিয়ার জন্য দরকারী।

তালিকার প্যারামিটারের চুক্তিটি হ'ল:

  • একটি নাল তালিকা ঠিক আছে
  • এতে এক বা একাধিক উপাদান সহ একটি তালিকা ঠিক আছে
  • এতে কোনও উপাদানবিহীন একটি তালিকা ভুল এবং এটি হওয়া উচিত নয়।

এই চুক্তি উন্মাদ । এর জন্য ডকুমেন্টেশন লেখার কল্পনা করুন! কল্পনা করুন পরীক্ষার কেসগুলি লিখুন!

আমার পরামর্শ: আবার শুরু করুন। এই এপিআই এর পুরো জুড়ে লেখা ক্যান্ডি মেশিন ইন্টারফেস রয়েছে। (অভিব্যক্তিটি মাইক্রোসফ্টের ক্যান্ডি মেশিনগুলির সম্পর্কে একটি পুরানো কাহিনী থেকে এসেছে যেখানে দাম এবং নির্বাচন উভয়ই দুই-অঙ্কের সংখ্যা এবং এটি "85" টাইপ করা অত্যন্ত সহজ যা আইটেমের দাম 75 এবং আপনি পান ভুল জিনিস। মজাদার ঘটনা: হ্যাঁ, আমি যখন মাইক্রোসফ্টে কোনও ভেন্ডিং মেশিন থেকে গাম বের করার চেষ্টা করছিলাম তখন ভুল করে আমি আসলে এটি করেছি!)

একটি বুদ্ধিমান চুক্তি কীভাবে ডিজাইন করা যায় তা এখানে:

আপনার পদ্ধতিটিকে এর পার্শ্ব প্রতিক্রিয়া বা এর রিটার্ন মান, উভয়ের জন্যই কার্যকর করুন।

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

কখনও নাল গ্রহণ করবেন না; একটি নাল ক্রম একটি ঘৃণা। কলকারীকে যদি খালি অনুক্রমটি পাস করার জন্য প্রয়োজনীয় হয় তবে এটি কখনই বাতিল হবে না।

কলকারী যদি আপনার চুক্তি লঙ্ঘন করে, আপনার ব্যবসাকে বোঝাতে চাইছে তা শিখুন এবং যাতে তারা পরীক্ষায় তাদের বাগগুলি ধরেন, উত্পাদন নয় not

চুক্তিটি প্রথমে যথাসম্ভব বুদ্ধিমান হওয়ার জন্য ডিজাইন করুন এবং তারপরে চুক্তিটি স্পষ্টভাবে বাস্তবায়ন করুন। এটি হ'ল ভবিষ্যতের প্রমাণের জন্য একটি নকশা।

এখন, আমি কেবল আপনার নির্দিষ্ট ক্ষেত্রে সম্পর্কে কথা বলেছি এবং আপনি একটি সাধারণ প্রশ্ন জিজ্ঞাসা করেছেন। সুতরাং এখানে কিছু অতিরিক্ত সাধারণ পরামর্শ দেওয়া হল:

  • যদি কোনও সত্যতা থাকে যে আপনি বিকাশকারী হিসাবে কমানো করতে পারেন তবে সংকলকটি পারেন না, তবে সেই সত্যটি দলিল করার জন্য একটি দৃser়তা ব্যবহার করুন। ভবিষ্যতে আপনি বা আপনার সহকর্মীদের মধ্যে যেমন অন্য কোনও বিকাশকারী এই অনুমানকে লঙ্ঘন করে তবে জোর দেওয়া আপনাকে বলবে।

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

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

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


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

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

5
@ কিডকোড হ্যাঁ, কিছু স্পষ্টত জটিল বিষয় এমনকি স্পষ্টভাবে বিষয়গুলি ব্যাখ্যা করার ক্ষেত্রে এরিকের পক্ষে খুব ভাল। :)
ম্যাসন হুইলার

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

5
এটি প্রায় সবার জন্য একটি খুব দরকারী পোস্ট!
অ্যাড্রিয়ান বুজিয়া

89

আপনি উপরে যে কোডটি দেখিয়ে দিচ্ছেন তাতে আপনি যা করছেন তা ভবিষ্যতের প্রুফিং যতটা রক্ষণাত্মক কোডিংয়ের মতো নয়

উভয় ifবিবৃতি বিভিন্ন জিনিস জন্য পরীক্ষা। উভয়ই আপনার প্রয়োজনের উপর নির্ভর করে উপযুক্ত পরীক্ষা।

বিভাগ 1 কোনও nullবস্তুর জন্য পরীক্ষা করে এবং সংশোধন করে । পার্শ্ব নোট: তালিকা তৈরি করা কোনও শিশু আইটেম তৈরি করে না (যেমন, CalendarRow)।

বিভাগ এবং 2 এবং ব্যবহারকারী এবং / বা প্রয়োগের ত্রুটিগুলি সংশোধন করে। কেবলমাত্র আপনার কাছে একটি List<CalendarRow>অর্থ এই নয় যে তালিকায় আপনার কোনও আইটেম রয়েছে। ব্যবহারকারী এবং বাস্তবায়নকারীরা এমন কিছু করবে যা আপনি কল্পনাও করতে পারবেন না কারণ এটি করার অনুমতি দেওয়া হয়েছে, এটি আপনার কাছে বোধগম্য হোক বা না হোক।


1
আসলে আমি ইনপুট মানে 'বোকা ব্যবহারকারীর কৌশল' নিচ্ছি। হ্যাঁ আপনার কখনই ইনপুট বিশ্বাস করবেন না। এমনকি আপনার ক্লাসের বাইরে থেকেও। যাচাই করুন! আপনি যদি ভাবেন এটি কেবল ভবিষ্যতের উদ্বেগ তবে আমি আপনাকে আজ হ্যাক করে খুশি হব।
candied_orange 20

1
@ ক্যান্ডিওড ওরেঞ্জ, এটি ছিল অভিপ্রায়, তবে শব্দবন্ধটি চেষ্টা করা রসিকতা প্রকাশ করে নি। আমি শব্দ পরিবর্তন করেছি।
অ্যাডাম জুকারম্যান

3
এখানে কেবল একটি দ্রুত প্রশ্ন, যদি এটি বাস্তবায়নের ত্রুটি / খারাপ ডেটা হয় তবে তাদের ত্রুটিগুলি ঠিক করার চেষ্টা করার পরিবর্তে আমি কি কেবল ক্রাশ করব না?
কিডকোড

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

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

35

আমার ধারণা, এই প্রশ্নটি মূলত স্বাদে নিচে। হ্যাঁ, দৃ rob় কোডটি লেখা ভাল ধারণা, তবুও আপনার উদাহরণের কোডটি KISS নীতিটির সামান্য লঙ্ঘন (যেমন "ভবিষ্যতের প্রুফ" কোডটি অনেকটা হবে)।

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

পরিবর্তে, আমি একটি পৃথক পদ্ধতির পছন্দ করব: assert()ম্যাক্রো বা অনুরূপ সুবিধাদি ব্যবহার করে আপনি যে অনুমানগুলি সুস্পষ্ট করেছেন তা করুন । এইভাবে, ভবিষ্যতের দ্বার ঘিরে যখন আসবে তখন এটি আপনাকে অবিকল বলবে যেখানে আপনার অনুমানগুলি আর ধারণ করে না।


4
ভবিষ্যতে কী ধারণ করে তা না জেনে আমি আপনার বক্তব্যটি পছন্দ করি। এই মুহুর্তে আমি যা করছি তা হ'ল সমস্যাটি কী হতে পারে অনুমান করা, তারপরে সমাধানের জন্য আবার অনুমান করা।
কিডকোড

3
@ কিডকোড: ভাল পর্যবেক্ষণ। আপনি এখানে স্বীকার করেছেন এমন উত্তর সহ এখানে আপনার নিজের চিন্তাভাবনা আসলে অনেকগুলি উত্তরের চেয়ে অনেক বেশি স্মার্ট।
জ্যাকবিবি

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

23

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

এটিকে সাহসের সাথে বলতে গেলে, যদি আপনার প্রোগ্রামে একটি ছোট্ট ত্রুটিও রয়েছে, আপনি যখন দেখছেন তখন এটি সম্পূর্ণ ক্র্যাশ হয়ে যায়!

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

আরও চিন্তাভাবনার জন্য, এই সংক্ষিপ্ত রচনাটি পড়ুন: সোজা অবস্থানে আপনার প্রোগ্রামটি পেরেক করবেন না


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

// Calculates the nth Fibonacci number
int fibonacci(int n) {
    int a = 0;
    int b = 1;

    for(int i = 0; i < n; i++) {
        int temp = b;
        b = a + b;
        a = temp;
    }

    return b;
}

এটি কাজ করে, তবে কেউ যদি আপনার কার্যক্রমে কোনও নেতিবাচক নম্বর পাস করে? এটা তখন কাজ করবে না! সুতরাং আপনি একটি চেক যোগ করতে চান তা নিশ্চিত করতে যে ফাংশনটি একটি nonnegative ইনপুট দিয়ে ডাকা হয়েছে তা নিশ্চিত করতে।

এটি এইভাবে ফাংশনটি লিখতে লোভনীয় হতে পারে:

// Calculates the nth Fibonacci number
int fibonacci(int n) {
    int a = 0;
    int b = 1;

    // Make sure the input is nonnegative
    if(n < 0) {
        n = 1; // Replace the negative input with an input that will work
    }

    for(int i = 0; i < n; i++) {
        int temp = b;
        b = a + b;
        a = temp;
    }

    return b;
}

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

পরিবর্তে, এটির মতো চেক লেখাই ভাল:

// Calculates the nth Fibonacci number
int fibonacci(int n) {
    int a = 0;
    int b = 1;

    // Make sure the input is nonnegative
    if(n < 0) {
        throw new ArgumentException("Can't have negative inputs to Fibonacci");
    }

    for(int i = 0; i < n; i++) {
        int temp = b;
        b = a + b;
        a = temp;
    }

    return b;
}

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


1
অবৈধ আর্গুমেন্ট বা সীমার বাইরে যুক্তি নির্দেশ করার জন্য সি # এর কি কোনও বিশেষ ধরনের ব্যতিক্রম নেই?
জেডিগোগস

@ জেডিগোগস ইয়েপ! সি # এর একটি আর্গুমেন্টএক্সসেপশন রয়েছে এবং জাভাতে একটি অবৈধআর্গুমেন্টএক্সসেপশন রয়েছে
কেভিন

প্রশ্নটি সি # ব্যবহার করছিল। সম্পূর্ণতার জন্য এখানে সি ++ (সংক্ষিপ্তসার লিঙ্ক)
জেডিগোগোস

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

2
@ লুয়ান: যদিও এটি উদাহরণের কাজটির দায়িত্ব নয়।
হোয়াইসনাম

11

আপনার কি অতিরিক্ত কাজ করা কোড যুক্ত করা উচিত? না।

তবে, আপনি যা বর্ণনা করছেন তা রিডান্ট্যান্ট কোড নয়

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

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

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

যদি আমাকে একটি সাধারণ নিয়ম নিয়ে আসতে হয় (যদিও, একটি সাধারণ নিয়ম হিসাবে আমি সেগুলি এড়াতে চেষ্টা করি), আমি বলব যে এমন একটি ফাংশন যা নিম্নলিখিত যে কোনওটিকে সন্তুষ্ট করে:

  • একটি উচ্চ-উচ্চ-স্তরের ভাষায় বাস করে (বলে সি এর চেয়ে জাভাস্ক্রিপ্ট)
  • একটি ইন্টারফেস সীমানায় বসে
  • কর্মক্ষমতা-সমালোচনামূলক নয়
  • সরাসরি ব্যবহারকারী ইনপুট গ্রহণ করে

... রক্ষণাত্মক প্রোগ্রামিং থেকে উপকৃত হতে পারে। অন্যান্য ক্ষেত্রে, আপনি assertবাগের সন্ধানের দক্ষতা আরও বাড়ানোর জন্য, পরীক্ষার সময় আগুন লাগিয়ে দেওয়া মুক্তির অক্ষরে অক্ষম থাকা আপনি এখনও আয়নগুলি লিখতে পারেন ।

এই বিষয়টি আরও উইকিপিডিয়াতে অনুসন্ধান করা হয়েছে ( https://en.wikedia.org/wiki/Defensive_programming )।


9

দশটি প্রোগ্রামিং কমান্ডের মধ্যে দুটি এখানে প্রাসঙ্গিক:

  • আপনি অনুমান করবেন না যে ইনপুটটি সঠিক

  • ভবিষ্যতে ব্যবহারের জন্য আপনি কোড তৈরি করবেন না

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

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


5
কোথায় এই প্রোগ্রামিং কমান্ড। আপনার কি লিংক আছে? আমি কৌতূহলী কারণ আমি বেশ কয়েকটি প্রোগ্রামে কাজ করেছি যা এই আদেশগুলির দ্বিতীয়টির সাবস্ক্রাইব করে, এবং যারা না করেন তাদের বেশ কয়েকটি not অবিশ্বাস্যভাবে, যারা আদেশের সাবস্ক্রাইব করেছেন তারা আদেশের স্বজ্ঞাত যুক্তি সত্ত্বেও Thou shall not make code for future useরক্ষণাবেক্ষণের বিষয়গুলিতে তাড়াতাড়ি দৌড়েছিলেন । আমি খুঁজে পেয়েছি, বাস্তব জীবনের কোডিংয়ে, আদেশটি কেবলমাত্র কোডে কার্যকর যেখানে আপনি বৈশিষ্ট্য তালিকা এবং সময়সীমা নিয়ন্ত্রণ করেন এবং নিশ্চিত হন যে আপনার ভবিষ্যতে কোডগুলি পৌঁছানোর দরকার নেই ... যা বলা যায় না, তা কখনও নয়।
কর্ট আম্মোন

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

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

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

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

7

'অপ্রয়োজনীয় কোড' এবং 'YAGNI' এর সংজ্ঞা প্রায়শই নির্ভর করে আমি আপনাকে কতদূর এগিয়ে দেখি তার উপরে খুঁজে পাই।

যদি আপনি কোনও সমস্যা অনুভব করেন তবে আপনি ভবিষ্যত কোডটি এমনভাবে লেখার ঝোঁক রাখেন যাতে সেই সমস্যাটি এড়ানো যায়। অন্য কোনও প্রোগ্রামার যিনি সেই নির্দিষ্ট সমস্যাটির মুখোমুখি হননি তারা আপনার কোডকে রিডানড্যান্ট ওভারকিল বিবেচনা করতে পারে।

আমার পরামর্শটি হ'ল যে 'যে জিনিসগুলি এখনও ভ্রষ্ট হয়েছে না' তার জন্য আপনি কতটা সময় ব্যয় করেছেন তা যদি আপনার ভারসাম্য এবং আপনার সহকর্মীরা আপনার চেয়ে আরও দ্রুত বৈশিষ্ট্যগুলিকে খুঁজে বেড়াচ্ছে তবে তা কমিয়ে দিন track

তবে, আপনি যদি আমার মতো হন তবে আমি আশা করি আপনি এটি 'ডিফল্টরূপে' টাইপ করে ফেলেছেন এবং এটি আপনাকে আর গ্রহণ করতে পারে নি।


6

পরামিতিগুলি সম্পর্কে কোনও অনুমান নথিভুক্ত করা ভাল ধারণা। এবং আপনার ক্লায়েন্ট কোড সেই অনুমানগুলি লঙ্ঘন করে না তা যাচাই করা ভাল ধারণা। আমি এটি করব:

/** ...
*   Precondition: rows is null or nonempty
*/
public static CalendarRow AssignAppointmentToRow(Appointment app, List<CalendarRow> rows)
{
    Assert( rows==null || rows.Count > 0 )
    //1. Is rows equal to null? - This will be the case if this is the first appointment.
    if (rows == null) {
        rows = new List<CalendarRow> ();
        rows.Add (new CalendarRow (0));
        rows [0].Appointments.Add (app);
    }

    //blah...
}

[এটি সি # হিসাবে ধরে নেওয়া, জোড় করা কাজের জন্য সেরা সরঞ্জাম নাও হতে পারে, কারণ এটি প্রকাশিত কোডে সংকলিত হয়নি। তবে এটি অন্য দিনের জন্য বিতর্ক]]

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


5

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

যখন প্রয়োজন হবে তখন কোড যুক্ত করার ব্যয়টি অনুমান করুন। এটি আরও ব্যয়বহুল হবে, কারণ আপনাকে কোডটিতে ফিরে আসতে হবে, সব মনে রাখবেন, এবং এটি আরও শক্ত।

অতিরিক্ত কোডটি আসলে প্রয়োজন হবে এমন সম্ভাবনাটি অনুমান করুন। তারপরে গণিত করুন।

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


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

আপনার বাগের দামটি অনুমান করতে হবে যা প্রোগ্রামে ক্রিম হতে পারে কারণ আপনি অবৈধ ইনপুটটিতে ব্যর্থ হন না। সংজ্ঞা অনুসারে সেগুলি অপ্রত্যাশিত থেকে আপনি ব্যয়ের মূল্য অনুমান করতে পারবেন না। সুতরাং পুরো "দ্য গণিত" আলাদা হয়ে যায়।
জ্যাকবিবি

3

এখানে প্রাথমিক প্রশ্নটি হল "আপনি কি করবেন / না করলে কি হবে"?

অন্যরা যেমন উল্লেখ করেছে যে এই ধরণের প্রতিরক্ষামূলক প্রোগ্রামিং ভাল তবে এটি মাঝে মাঝে বিপজ্জনকও বটে।

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

আমার কাছে চাবিকাঠি হ'ল কখনই ডেটা দূষিত হয় । আমাকে যে পুনরাবৃত্তি; না। বিকৃত। ডেটা। যদি আপনার প্রোগ্রাম ব্যতিক্রম হয়, আপনি প্যাচ করতে পারেন এমন একটি বাগ রিপোর্ট পান; যদি এটি কোনও ফাইলে খারাপ ডেটা লিখে থাকে যা এটি পরে আসে তবে আপনাকে লবণ দিয়ে মাটি বপন করতে হবে।

আপনার সমস্ত "অপ্রয়োজনীয়" সিদ্ধান্ত সেই সিদ্ধান্তটি মাথায় রেখেই করা উচিত।


2

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

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

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

if (rows == null) throw new ArgumentNullException(nameof(rows));

নাল যেখানে আপনি একটি ইনপুট চান না rowsএবং আপনি যত তাড়াতাড়ি সম্ভব আপনার সমস্ত কলকারীদের জন্য ত্রুটিটি সুস্পষ্ট করতে চান ।

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

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

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

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

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


1

আমি আপনার অনুমানের ভিত্তিতে এর উত্তর দিতে যাচ্ছি যে এখন থেকে শক্তিশালী কোড আপনাকে "বছর" উপকার করবে। যদি দীর্ঘমেয়াদী সুবিধাগুলি আপনার লক্ষ্য হয় তবে আমি দৃ design়তার চেয়ে নকশা এবং রক্ষণাবেক্ষণকে অগ্রাধিকার দেব।

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

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

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


1

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

আপনি rowsআর্গুমেন্ট সম্পর্কে আপনার বর্তমান প্রত্যাশাগুলি বর্ণনা করুন : হয় এটি বাতিল বা অন্যথায় এটির অন্তত একটি আইটেম রয়েছে। সুতরাং প্রশ্নটি হ'ল rowsশূন্য আইটেমগুলি রয়েছে এমন অপ্রত্যাশিত তৃতীয় ক্ষেত্রে অতিরিক্তভাবে পরিচালনা করার জন্য কোডটি লিখতে ভাল ধারণা কি ?

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

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

সুতরাং আপনার কোডটি দেখতে এমন হওয়া উচিত:

public static CalendarRow AssignAppointmentToRow(Appointment app, List<CalendarRow> rows)
{
    if (rows != null && rows.Count == 0) throw new ArgumentException("Rows is empty."); 

    //1. Is rows equal to null? - This will be the case if this is the first appointment.
    if (rows == null) {
        rows = new List<CalendarRow> ();
        rows.Add (new CalendarRow (0));
        rows [0].Appointments.Add (app);
    }

    //blah...
}

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


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


1

ভবিষ্যতে প্রয়োজনের প্রয়োজনে এখনই কি আমি রিডানড্যান্ট কোড যুক্ত করব?

আপনার কোনও সময় রিলান্ড্যান্ট কোড যুক্ত করা উচিত নয়।

আপনার ভবিষ্যতে কেবল প্রয়োজনীয় কোডটি যুক্ত করা উচিত নয়।

আপনার কোডটি নিশ্চিত হওয়া উচিত যে যাই ঘটুক না কেন আপনার কোডটি ভাল আচরণ করে।

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

সিউডো কোড উদাহরণ:

file = File.open(">", "bla")  or raise "Paranoia: cannot open file 'bla'"

file.write("xytz") or raise "Paranoia: disk full?"

file.close()  or raise "Paranoia: huh?!?!?"

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

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

একটি খুব গুরুত্বপূর্ণ সম্পর্কিত অনুসন্ধান শব্দটি হবে "দ্রুত ব্যর্থ", যেমন অন্যান্য উত্তরে উল্লিখিত এবং শক্তিশালী সফ্টওয়্যার তৈরি করতে খুব দরকারী।


-1

এখানে প্রচুর পরিমাণে জটিল উত্তর রয়েছে। আপনি সম্ভবত এই প্রশ্নটি জিজ্ঞাসা করেছেন কারণ আপনি এই টুকরা কোডটি সম্পর্কে সঠিক মনে করেন নি তবে কেন বা কীভাবে এটি ঠিক করবেন তা নিশ্চিত ছিলেন না। সুতরাং আমার উত্তরটি হ'ল সমস্যাটি কোড স্ট্রাকচারে (বরাবরের মতো) খুব সম্ভবত।

প্রথমত, পদ্ধতি শিরোনাম:

public static CalendarRow AssignAppointmentToRow(Appointment app, List<CalendarRow> rows)

কোন সারিতে অ্যাপয়েন্টমেন্ট বরাদ্দ করবেন ? এটি প্যারামিটার তালিকা থেকে অবিলম্বে পরিষ্কার হওয়া উচিত। কোনও জ্ঞান ছাড়া, আমি পদ্ধতি প্যারাম ভালো চেহারা আশা হবে: (Appointment app, CalendarRow row)

এরপরে, "ইনপুট চেকস":

//1. Is rows equal to null? - This will be the case if this is the first appointment.
if (rows == null) {
    rows = new List<CalendarRow> ();
}

//2. Is rows empty? - This will be the case if this is the first appointment / some other unknown reason.
if(rows.Count == 0)
{
    rows.Add (new CalendarRow (0));
    rows [0].Appointments.Add (app);
}

এটি বুলশিট

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

তবে কোথাও নিয়োগ বরাদ্দের পুরো ধারণাটি অদ্ভুত (যদি না এটি কোডের একটি জিইউআই অংশ থাকে)। আপনার কোডটিতে মনে হয় (বা কমপক্ষে এটি চেষ্টা করে) একটি ক্যালেন্ডার উপস্থাপন করে এমন একটি স্পষ্ট ডেটা কাঠামো (যা List<CalendarRows><- এটি Calendarকোনও জায়গায় সংজ্ঞায়িত করা উচিত যদি আপনি এই পথে যেতে চান তবে আপনি Calendar calendarআপনার পদ্ধতিতে চলে যাবেন )। আপনি যদি এই পথে যান তবে আমি আশা করব যে calendarআপনি যে স্লটগুলি নিয়োগ করেছেন (সুনির্দিষ্ট) তার পরে অ্যাপয়েন্টমেন্টগুলি স্থাপন calendar[month][day] = appointmentকরবেন (যেমন উপযুক্ত কোড হবে)। তবে আপনি মূল যুক্তি থেকে পুরোপুরি ক্যালেন্ডার কাঠামোটি খাঁজতে এবং ঠিক রাখতে পারেন List<Appointment>যেখানে Appointmentবস্তুগুলির বৈশিষ্ট্য রয়েছেdate। এবং তারপরে আপনি যদি জিইউআই-র কোথাও কোনও ক্যালেন্ডার রেন্ডার করতে চান তবে আপনি রেন্ডারিংয়ের ঠিক আগে এই 'স্পষ্টত ক্যালেন্ডার' কাঠামোটি তৈরি করতে পারেন।

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


-2

সরলতার জন্য, ধরে নেওয়া যাক হয় শেষ পর্যন্ত আপনার এই কোডের টুকরোটি এন দিনগুলিতে (পরে বা পূর্ববর্তী নয়) প্রয়োজন হবে বা প্রয়োজন নেই।

সুডোকোড:

let C_now   = cost of implementing the piece of code now
let C_later = ... later
let C_maint = cost of maintaining the piece of code one day
              (note that it can be negative)
let P_need  = probability that you will need the code after N days

if C_now + C_maint * N < P_need*C_later then implement the code else omit it.

এর জন্য উপাদানগুলি C_maint:

  • এটি কি সাধারণভাবে কোডটিকে উন্নত করে, আরও স্ব-ডকুমেন্টিং করে তোলে, যাচাই করা সহজ? যদি হ্যাঁ, নেতিবাচক C_maintপ্রত্যাশিত
  • এটি কি কোডকে বড় করে তোলে (তাই পড়ার পক্ষে আরও দীর্ঘতর, সংকলন করা, পরীক্ষাগুলি বাস্তবায়ন করা ইত্যাদি)?
  • কোনও রিফ্যাক্টরিংস / পুনর্নির্দেশগুলি মুলতুবি রয়েছে? যদি হ্যাঁ, গলদ C_maint। এই ক্ষেত্রে আরও জটিল সূত্রের প্রয়োজন, আরও বেশি বারের মতো চলকগুলির মতো N

এত বড় বিষয় যা কেবল কোডটি ওজন করে এবং মাত্র 2 বছরে কম সম্ভাবনার সাথে প্রয়োজন হতে পারে, তবে একটি সামান্য জিনিস যা দরকারী দৃser়তার প্রতিশ্রুতি দেয় এবং 50% যে এটি 3 মাসের মধ্যে প্রয়োজন হবে, এটি বাস্তবায়ন করা উচিত ।


আপনার বাগের ব্যয়ও ফ্যাক্ট করতে হবে যা প্রোগ্রামে ক্রিম হতে পারে কারণ আপনি অবৈধ ইনপুট প্রত্যাখ্যান করছেন না। সুতরাং আপনি কীভাবে সম্ভাব্য হার্ড-টু-সন্ধানের বাগগুলির ব্যয়টি অনুমান করবেন?
জ্যাকবিবি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.