অস্থায়ী কাজের জন্য কোনও পদ্ধতির নামে একটি বাগ নম্বর অন্তর্ভুক্ত করা কি এই অনুশীলন হিসাবে বিবেচিত?

Question

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

অস্থায়ী কাজের জন্য পদ্ধতির নামের ভিতরে বাগ নম্বর সহ কী খারাপ অভ্যাস হিসাবে বিবেচিত হবে?

Comments

কেবল একটি ব্যাখ্যা: ত্রুটি ### স্কেলক্লিয়েন্ট নামে একটি বহিরাগত উপাদানটিতে রয়েছে, এটি ২০০৮ সালে দায়ের করা হয়েছিল, সম্ভবত এটি খুব শীঘ্রই সংশোধন করা হবে না এবং এটি আমাদের ক্ষমতার বাইরে চলে গেছে, সুতরাং এই পদ্ধতিটি ডিজাইনের একটি অংশ " কাজের-আশেপাশে "এই সমস্যাটি ...

— বোজন

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

— maple_shaft

ধরে নিন অস্থায়ী কর্মক্ষেত্র স্থায়ী হয়ে যাবে। তারা সবসময় না।

— ব্যবহারকারী16764

@ ম্যাপেল_শ্যাফ্ট - প্রশ্নে দুর্দান্ত সংরক্ষণ-সম্পাদনা।

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

— এরিক পুনরায়

Answer 1

আপনার সহকর্মীর পরামর্শ অনুসারে আমি পদ্ধতির নাম রাখব না। পদ্ধতিটির নামটি পদ্ধতিটি কী করে তা নির্দেশ করে। মত নাম PerformSqlClient216147Workaroundএটি কি করে তা বোঝায় না। যদি কিছু হয় তবে এমন মন্তব্যগুলি ব্যবহার করুন যা পদ্ধতিটি বর্ণনা করে এটি উল্লেখ করে যে এটি একটি কর্মচঞ্চল। এটি নিম্নলিখিতগুলির মতো দেখতে পারে:

/**
 * Cast given right-hand SQL expression.
 *
 * Note: This is a workaround for an SQL client defect (#216147).
 */
public void CastRightExpression(SqlExpression rightExpression)
{
    ...
}

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

Comments

ডকুমেন্টেশন মন্তব্যে বাগের সাথে সরাসরি http লিঙ্ক থাকা ভাল ধারণা হবে। আপনি নিজের টীকাও সংজ্ঞায়িত করতে পারেন@Workaround(216147)

— সুলতান

বা @warning This is a temporary hack to...বাTODO: fix for ...

— 1313

@ সুলতান - অবশ্যই ... সেই ত্রুটিযুক্ত ডাটাবেসের সাথে লিঙ্ক দেয় যা কয়েক বছরের মধ্যে নাও থাকতে পারে। ত্রুটিটি বর্ণনা করুন, ত্রুটিটি # (এবং তারিখ) রাখুন, এটি একটি কার্যকরী দস্তাবেজ কিন্তু পরিবর্তিত করতে পারে এমন অভ্যন্তরীণ সরঞ্জামগুলির লিঙ্কগুলি একটি খারাপ ধারণা বলে মনে হচ্ছে।

— রামহাউন্ড

@ র‌্যামাউন্ড আপনার নিজের ত্রুটিযুক্ত ডাটাবেসটি বিবেচনা করা উচিত এবং ইতিহাসের পরিবর্তে ইতিহাসের হিসাবে মূল্যবান হিসাবে ইতিহাস পরিবর্তন করা উচিত change কেন আপনাকে কিছু করা হয়েছিল এবং কীভাবে এটি এমনটি হয়েছিল তার পুরো গল্প তারা আপনাকে জানায়। পরবর্তী ব্যক্তির জানা দরকার।

— টিম উইলিসক্রফ্ট

কোড (এই ক্ষেত্রে, পদ্ধতির নাম) এটি যা করে তা স্ব-দস্তাবেজ করা উচিত। মন্তব্যে ব্যাখ্যা করা উচিত কেন কোডটি বিদ্যমান বা একটি নির্দিষ্ট উপায়ে কাঠামোগত।

— অ্যারন কুর্তজল

Answer 2

কোনও অস্থায়ী ফিক্স যা কাজ করে তার চেয়ে বেশি স্থায়ী নয়।

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

তিনি যা প্রস্তাব দিচ্ছেন তা হ'ল আপনার QC এবং QA সিস্টেমগুলি উল্লেখযোগ্যভাবে ঘাটতির প্রমাণ দেয় lling ত্রুটিগুলি এবং ত্রুটিযুক্ত ফিক্সগুলির ট্র্যাকিং ত্রুটি ট্র্যাকিং সিস্টেমে সম্পর্কিত, উত্স কোড নয়। উত্স কোড পরিবর্তনগুলির সন্ধান করা উত্স নিয়ন্ত্রণ সিস্টেমে অন্তর্ভুক্ত। এই সিস্টেমগুলির মধ্যে ক্রস রেফারেন্সিং সোর্স কোডে ত্রুটিগুলি সনাক্ত করার অনুমতি দেয় .....

সোর্স কোডটি আজকের জন্য রয়েছে, গতকাল নয় এবং আগামীকালও নয় (যেমনটি, আপনি উত্সটিতে টাইপ করেন না যে পরের বছর কী করার পরিকল্পনা করছেন) ...

Comments

+1Nothing is more permanent than a temporary fix that works.

— ই

"ব্যাপকভাবে গৃহীত হয়েছে" [উদ্ধৃতি আবশ্যক]

@Graham: এই ভাল যথেষ্ট, বা এটা একটি পিয়ার পর্যালোচনা করা, একটি নামকরা jorunal .... প্রকাশিত কাগজ করা প্রয়োজন হয় না stackoverflow.com/questions/123936/...

— mattnz

Answer 3

সুতরাং এটি একটি অস্থায়ী সমাধান? তারপরে পর্যালোচক কর্তৃক প্রস্তাবিত নামটি ব্যবহার করুন, তবে পদ্ধতিটি অপ্রচলিত হিসাবে চিহ্নিত করুন, যাতে এটি ব্যবহার করে প্রতিবার কেউ কোডটি সংকলন করার সময় একটি সতর্কতা তৈরি করে।

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

নোট করুন এমনকি মন্তব্যগুলিতেও, বাগের নম্বরটি খুব মূল্যবান নয়। নিম্নলিখিত মন্তব্যটি কল্পনা করুন:

public IEnumerable<Report> FindReportsByDateOnly(DateTime date)
{
    // The following method replaces FindReportByDate, because of the bug 8247 in the
    // reporting system.
    var dateOnly = new DateTime(date.Year, date.Month, date.Day);
    return this.FindReportByDate(dateOnly);
}

private IEnumerable<Report> FindReportsByDate(DateTime date)
{
    Contract.Requires(date.Hour == 0);
    Contract.Requires(date.Minute == 0);
    Contract.Requires(date.Second == 0);

    // TODO: Do the actual work.
}

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

উপসংহার: এই বাগটি কী সম্পর্কে আপনার কোনও ধারণা নেই।

একই কোডটি কিছুটা ভিন্নভাবে লেখা যেতে পারে:

public IEnumerable<Report> FindReportsByDateOnly(DateTime date)
{
    // The reporting system we actually use is buggy when it comes to searching for a report
    // when the DateTime contains not only a date, but also a time.
    // For example, if looking for reports from `new DateTime(2011, 6, 9)` (June 9th, 2011)
    // gives three reports, searching for reports from `new DateTime(2011, 6, 9, 8, 32, 0)`
    // (June 9th, 2011, 8:32 AM) would always return an empty set (instead of isolating the
    // date part, or at least be kind and throw an exception).
    // See also: http://example.com/support/reporting-software/bug/8247
    var dateOnly = new DateTime(date.Year, date.Month, date.Day);
    return this.FindReportsByDate(dateOnly);
}

private IEnumerable<Report> FindReportsByDate(DateTime date)
{
    Contract.Requires(date.Hour == 0);
    Contract.Requires(date.Minute == 0);
    Contract.Requires(date.Second == 0);

    // TODO: Do the actual work.
}

এখন আপনি ইস্যুটির একটি পরিষ্কার দৃষ্টিভঙ্গি পান। এমনকি যদি মনে হয় যে মন্তব্যটির শেষে হাইপারটেক্সট লিঙ্কটি পাঁচ বছর আগে মারা গেছে তবে এটি কোনও ব্যাপার নয়, কারণ আপনি এখনও বুঝতে পারবেন কেন FindReportsByDateপ্রতিস্থাপন করা হয়েছিল FindReportsByDateOnly।

Comments

ঠিক আছে, আমরা কোথাও পাচ্ছি: আপনি কেন মনে করেন যে উত্স কোডটি বাগ সংখ্যার জন্য ভাল জায়গা নয়?

— বোজন

কারণ বাগ ট্র্যাকিং সিস্টেম এবং সংস্করণ নিয়ন্ত্রণগুলি এর জন্য আরও ভাল জায়গা। : এটা না ঠিক একই কিন্তু অনুরূপ stackoverflow.com/q/123936/240613

— আরসেনি Mourzenko

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

— বোজন

আমি যদিও কেবল বিপণনের লোকেরা অপ্রচলিত এমন কিছু নতুন যুক্ত করার যুক্তিটি নিয়ে তর্ক করতে পারে।

— mattnz

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

— ড্যান নীলি

Answer 4

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

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

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

Comments

পারফর্মস্ক্লিক্লিয়েন্ট 216147 ওয়ার্কআরউন্ড পদ্ধতিটি ঠিক কী করে তা এবং বিদ্যমান কারণগুলির কারণ উভয়ই বর্ণনা করে বলে আমি মনে করি। আমি এটিকে আপনার দোকানের জন্য এই জাতীয় জিনিসগুলির সাথে নির্দিষ্ট একটি গুণ (সি #) দিয়ে চিহ্নিত করব এবং এটি দিয়ে শেষ করব with নামগুলিতে নামগুলিতে তাদের স্থান রয়েছে ... উপরের মতো আশা করা যায় যে আপনার দোকান কেবল এই জাতীয় জিনিসগুলিকে শ্রেণিবদ্ধ করার জন্য ব্যবহার করে না। একটি টিচআপ আইএমএইচও-তে ঝড়। বিটিডব্লু কি আসল ত্রুটি কোড ?? যদি তাই হয় তবে সিনিয়র সহকর্মীর কাছে সম্ভবত এই পোস্টটি আবিষ্কারের একটি অবতীর্ণ সম্ভাবনা রয়েছে যা আপনার সমস্যা হতে পারে বা নাও হতে পারে .... ;)

— রিজম

Answer 5

আপনার সহকর্মীর পরামর্শে এর মূল্য রয়েছে; এটি কারণের সাথে কোডের পরিবর্তনগুলি সংযুক্ত করে, সেই টিকিট সংখ্যার নীচে বাগ ডাটাবেসে নথিভুক্ত, কেন পরিবর্তনটি করা হয়েছিল তা সনাক্ত করে tra

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

Comments

এটি নামটির পরিবর্তে পদ্ধতির মন্তব্যে ব্যাখ্যা করা উচিত।

— আর্সেনী মোরজেনকো

আমি আপনার উত্তরটির সাথে সাধারণভাবে একমত, তবে আমি মেন্মার সাথেও একমত: একটি পদ্ধতি সম্পর্কে মেটা-তথ্যটি মন্তব্যে হওয়া উচিত, নাম নয়।

— রবার্ট হার্ভে

Answer 6

আমি মনে করি আপনি এবং তিনি উভয়ই অনুপাতের বাইরে এই পুরো জিনিসটি অর্জন করেছেন।

আমি আপনার প্রযুক্তিগত যুক্তির সাথে একমত, তবে দিনের শেষে এটি এতটা তাত্পর্য ফেলবে না, বিশেষত যদি এটি একটি অস্থায়ী ফিক্স যা কিছু দিন / সপ্তাহ / মাসের মধ্যে কোডবেজ থেকে সরানো যেতে পারে।

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

যেভাবেই হোক, আপনার এবং তাঁর আরও ভাল কাজ করা উচিত।

Comments

পয়েন্ট নেওয়া হয়েছে। তবে আমি অহংকারের

— শক্তিটিকে হ্রাস করব

Answer 7

অস্থায়ী কাজের জন্য পদ্ধতির নামের ভিতরে বাগ নম্বর সহ কী খারাপ অভ্যাস হিসাবে বিবেচিত হবে?

হ্যাঁ।

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

যদি সেই শ্রেণীর পাবলিক এপিআইয়ের অংশটি মূলত "ডকুমেন্ট / অবস্থান এক্সে বর্ণিত অপারেশন ওয়াই করে" বলে থাকে তবে অন্যান্য লোকগুলির এপিআই বোঝার ক্ষমতা নির্ভর করবে:

1. তাদের বাহ্যিক ডকুমেন্টেশনে কী সন্ধান করতে হবে তা জেনে

2. বাহ্যিক ডকুমেন্টেশন কোথায় সন্ধান করবেন তা তাদের জানা knowing

3. তাদের সময় এবং প্রচেষ্টা গ্রহণ এবং আসলে খুঁজছেন।

তারপরে আবার, আপনার পদ্ধতির নামটিতেও এই ত্রুটির জন্য "অবস্থান এক্স" কোথায় রয়েছে তা উল্লেখ করা যায় না।

এটি কেবল ধরে নিয়েছে (কোনও বাস্তব কারণেই নয়) যে কোডটিতে অ্যাক্সেস রয়েছে তার প্রত্যেকটিরও ত্রুটিযুক্ত ট্র্যাকিং সিস্টেমে অ্যাক্সেস রয়েছে এবং স্থিতিশীল কোডটি যতদিন থাকবে ততক্ষণ ট্র্যাকিং সিস্টেমটি প্রায় থাকবে।

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

তবুও, অন্যান্য ত্রুটিগুলির জন্য কার্যকারিতা থাকতে পারে, যা এক শ্রেণির API এর চেয়ে বেশি প্রভাবিত করে। তাহলে তুমি কি করবে?

একাধিক ক্লাসে একই ত্রুটি সংখ্যার সাথে এপিআই থাকা ( data = controller.get227726FormattedData(); view.set227726FormattedData(data);আসলে আপনাকে বেশি কিছু বলে না এবং কেবল কোডটিকে আরও অস্পষ্ট করে তোলে।

আপনি সিদ্ধান্ত নিতে পারেন যে অপারেশন বর্ণনামূলক নামগুলি ব্যবহার করে অন্য সমস্ত ত্রুটিগুলি সমাধান করা হয়েছে data = controller.getEscapedAndFormattedData(); view.setEscapedAndFormattedData(data);, আপনার 216147 ত্রুটির ক্ষেত্রে (যা "ন্যূনতম উদ্বৃত্ত" এর নকশার নীতিটি ভেঙে দেয় - বা যদি আপনি সেভাবে রাখতে চান তবে) আপনার কোডের "ডাব্লুটিএফ / এলওসি" পরিমাপ বাড়িয়ে তোলে)।

টিএল; ডিআর: খারাপ অনুশীলন! তোমার ঘরে যাও!

Answer 8

প্রোগ্রামারের প্রধান লক্ষ্যগুলি হ'ল কার্য কোড এবং প্রকাশের স্বচ্ছতা হওয়া উচিত।

একটি workaround পদ্ধতির নামকরণ (.... workaround)। এই লক্ষ্য অর্জন বলে মনে হবে। আশা করি কোনও পর্যায়ে অন্তর্নিহিত সমস্যাটি ঠিক হয়ে যাবে এবং কাজের পদ্ধতিটি সরানো হবে।

Answer 9

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

যদি এসকিএলক্লিয়েন্টের সাথে কথোপকথনের অংশটির জন্য আপনাকে সঠিক অভিব্যক্তি কাস্ট সঞ্চালনের প্রয়োজন হয়, তবে আপনার কোডটি "পারফরম্যান্টরাইট এক্সপ্রেসকাস্ট ()" পড়তে হবে। কেন আপনি তা সবসময় বোঝাতে কোডটিতে মন্তব্য করতে পারেন।

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

আমার এক সহকর্মী একবার বলেছিলেন "কোনও ত্রুটি ঠিক করার সময় কোডটি যেভাবে হওয়া উচিত ছিল সেভাবে তৈরি করুন।" আমি যেভাবে এটি ব্যাখ্যা করি তা হ'ল কোডটি কীভাবে দেখতে পারা যায় যদি এই বাগটি কখনও না থাকে।

ফল:

1. সাধারণত, ফলাফল হিসাবে কম কোড।
2. সোজা কোড
3. উত্স কোডে বাগগুলির জন্য কম রেফারেন্স
4. ভবিষ্যতের প্রতিরোধের কম ঝুঁকি (একবারে কোড পরিবর্তন পুরোপুরি যাচাই হয়ে গেলে)
5. বিশ্লেষণ করা সহজ কারণ বিকাশকারীদের ইতিহাস শেখার ইতিহাসে আর বোঝা লাগবে না যা প্রাসঙ্গিক নয়।

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

সুতরাং আপনার পদ্ধতির নাম 'পারফর্মস্কুলসিলেট 216147 ওয়ার্কারআউন্ড' রাখবেন কিনা তা সিদ্ধান্ত নেওয়ার সময় নিজেকে এই প্রশ্নগুলি জিজ্ঞাসা করুন:

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