"ব্যান্ডেজ" সমাধানগুলি কতটা সাধারণ? [বন্ধ]


18

নিম্নলিখিত পরিস্থিতিতে কল্পনা করুন:

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

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

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

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

উত্তর:


19

সময় / সময়সীমা চাপ এক কারণ।

যদি আপনি একটি শক্ত সময়সীমার বিরুদ্ধে থাকেন এবং আপনার বস আপনার ঘাড়ে নিঃশ্বাস ফেলেছেন (সম্ভবত আক্ষরিক অর্থে!) তবে এটি করছেন এবং "আমি ফিরে আসব এবং পরে এটি ঠিক করব" ভাবনা খুব লোভনীয় এবং সম্ভবত আপনিই হতে পারেন পারব.

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


10

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

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


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

কখনও কখনও কোডের চূড়ান্ত প্রকাশে প্রকৃত ফিক্সের চেয়ে বেশি ব্যান্ডেজ থাকে। এমনকি প্রোগ্রামারদের কেউ কেউ অন্য প্রকল্পগুলিতে সেই ব্যান্ডেজগুলি অনুলিপি করতে শুরু করেছিলেন।
প্রশম

7

সময়

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


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

5

আমরা তাদের ব্যতিক্রমীভাবে করি।


উন্নয়নের সময় সংশোধন করার জন্য, আমরা নিশ্চিত করছি যে মূল কারণটি না জেনে কোনও ফিক্স সম্পন্ন করা হচ্ছে না। যাহোক:

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

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


রক্ষণাবেক্ষণের প্রবাহে ফিক্সগুলির জন্য, আমরা নিশ্চিত করছি যে মূল কারণটি না জেনে কোনও ফিক্স সম্পন্ন করা হয়নি। যাহোক:

  • খুব ব্যতিক্রমী মূল কারণ অনুসন্ধান অনুসন্ধান বন্ধ হবে,
  • ব্যতিক্রমীভাবে এটি ঘটতে পারে যে মূল কারণটি ঠিক করা কৌশলগতভাবে সম্ভব নয় (পরিবর্তনটি তাত্পর্যপূর্ণ নয় এবং গ্রাহককে গতকালই ফিক্সটির প্রয়োজন ছিল)।

এই ক্ষেত্রে আমরা প্রথমে "ব্যান্ডেজ" অস্থায়ী ফিক্সটি বেছে নিই এবং গ্রাহকরা খুশি হয়ে গেলে আমরা সঠিক ফিক্সে কাজ করি এবং কেবল তখনই ত্রুটিটি সমাধান করা হয়।


4

দ্ব্যর্থতা নিরসন।

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

প্রথমত, "ব্যান্ডেজ" সংশোধন করার ফ্রিকোয়েন্সি সম্পর্কিত :

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

দ্বিতীয়ত, আমার পরামর্শ:

যদি কোনও উন্নয়ন দলের নিজস্ব উত্স কোডে বাগটি ঘটে থাকে:

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

যদি অন্য দলের উত্স কোডে বাগটি ঘটে থাকে:

  • তাদের বাগ ঠিক করতে সেই দলটিকে চাপ দিন।
  • সর্বদা অন্য দলের ত্রুটিযুক্ত ট্র্যাকিং সিস্টেমের সাথে সেই বাগটি ফাইল করুন ।

বাগটি যদি অন্য কোনও কোম্পানির (বা কোনও সংস্থার) পণ্যতে ঘটে থাকে:

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

2

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


2

আমি বলব এটি খুব সাধারণ।

জোয়েল স্পলস্কির ব্লগ পোস্টটি দেখুন: ড্যাক্ট টেপ প্রোগ্রামার

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

একাডেমিক জগত এবং বাস্তব বিশ্বের যেখানে পার্থক্য রয়েছে সেখানে সফ্টওয়্যারকে আসলে সময় এবং ব্যবসায়ের সংকোচনের আওতায় পাঠানো দরকার।

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


1

আরও প্রসঙ্গ ছাড়াই বলা শক্ত - আপনার উদাহরণস্বরূপ, যদি বিবৃতিটি সঠিক ফিক্স না করে যুক্ত করা হয় কেন? এটি কি কারণ কোথাও কোথাও কোডের অন্য কোনও ব্লক রয়েছে যা সেই ইনপুটটির সাথে ডিল করবে বলে মনে করা হচ্ছে?

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

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


ifকারন যদি ত্রুটিপূর্ণ তাঁবেদার ফাংশন বিবৃতি সঠিক নয়।
জোশ কে

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

1

এমন কিছু ঘটনা রয়েছে যেখানে এই ধরণের সংশোধনটি সত্যই ঠিক আছে এবং সম্ভবত আদর্শ (এটি ডিবাগ করতে যত সময় লাগে তার সাথে সম্পর্কিত)।

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

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

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

ifঅন্য কারও কার্যকারিতা ভিতরে ofোকানোর পরিবর্তে , আমি ফাংশনটি {$ifdef}প্রায় লাগিয়ে দেব - এইভাবে কেউ তাকে এমন কিছু দিয়ে বিভ্রান্ত করে যা সেখানে থাকা উচিত।

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