কিভাবে একটি শূন্য-বাগ প্রোগ্রামার হতে? [বন্ধ]


168

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

আমি কীভাবে শূন্য-বাগ প্রোগ্রামার হতে পারি এবং কীভাবে আমার কোডের প্রতিটি চরিত্রের কারণ এবং প্রভাব ফেলবে তা জানতে পারি?


আমাকে ছাড়া আর কেউই প্রথমবারের মতো নিখুঁত কোড তৈরি করে না। তবে আমার মধ্যে একজনই আছে। - টেক টক: লিনাস টরভাল্ডস গিট, গুগল, 15 আগস্ট 2007 izquotes.com/quote/273558
জেনসজি


0-বাগ প্রোগ্রামিংয়ের মতো কোনও জিনিস নেই। কেন তা বোঝার জন্য গণিতবিদ গডেল পড়ুন।
মাইকেল মার্টিনেজ 21

এটি একটি ভুল লক্ষ্য, দেখুন: yegor256.com/2015/06/18/good-programmers-bug-free.html
yegor256

উত্তর:


365

মোটেই কোড করবেন না।

আপনি একমাত্র শূন্য-বাগ প্রোগ্রামার হতে পারেন।

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


73
+1 অনুসরণ করুন: বা আপনি একটি নন-কোডিং (আইভরি টাওয়ার) স্থপতি হতে পারেন এবং এখনও প্রচুর অর্থ প্রদান করতে পারেন! এটাই সেরা।
মার্টিন উইকম্যান

26
ত্রুটিযুক্ত হওয়া মানব, আপনার বাগগুলি divineশ্বরিকভাবে ঠিক করা।
ওয়ার্ড মুয়িলার্ট

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

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

8
আরও ভাল: একজন বস হন এবং কোনও কিছুর দায় না নিয়ে আপনার অন্তর্বাসকে দু: খিত মনে করুন।
বিজিক্লপ

124

জিরো বাগগুলি একটি তুচ্ছ তুচ্ছ প্রোগ্রামের জন্য অসম্ভব।

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

এই সফ্টওয়্যারটি বাগ-মুক্ত। এটি নিখুঁত, যতটা মানুষ অর্জন করেছে তত নিখুঁত। এই পরিসংখ্যানগুলি বিবেচনা করুন: প্রোগ্রামটির শেষ তিনটি সংস্করণ - প্রতিটি 420,000 লাইনের দীর্ঘ - প্রতিটিটিতে একটি মাত্র ত্রুটি ছিল। এই সফ্টওয়্যারটির সর্বশেষ 11 সংস্করণগুলিতে মোট 17 টি ত্রুটি ছিল।

গ্লোবাল পজিশনিং স্যাটেলাইটের সাথে চলাচল করতে শাটলটিকে অনুমতি দেওয়ার জন্য সফ্টওয়্যারটির আপগ্রেড নিন, যা প্রোগ্রামের মাত্র 1.5% বা কোডের 6,366 লাইনের সাথে জড়িত একটি পরিবর্তন। এই পরিবর্তনের জন্য নির্দিষ্টকরণগুলি 2,500 পৃষ্ঠাগুলি চালায় যা একটি ফোন বইয়ের চেয়ে ভলিউম ঘন। বর্তমান প্রোগ্রামের স্পেসিফিকেশনগুলি 30 টি ভলিউম পূরণ করে 40,000 পৃষ্ঠা চালায়।


3
অসম্ভব না. তবে অত্যন্ত সম্ভাবনা নেই।
বিলি ওনিল

36
এফবি বাগ বাগমুক্ত বলে কী ভাবছে? ফেসবুকের সুরক্ষা এবং গোপনীয়তার মডেল একটি বিশাল বাগ। উদাহরণস্বরূপ, নিরাপত্তা দুর্বলতার কারণে গত সপ্তাহে ফেসবুকের মালিকরা ফেসবুক অ্যাকাউন্ট হ্যাক হয়ে গেছে।
স্টিফেন সি

6
@ ইলাইন ফেসবুকের দর্শন হল "দ্রুত যান এবং জিনিসগুলি ভাঙ্গুন " ( geek.com / আর্টিকেলস / নিউজ/… ) এবং তাদের হাতে রয়েছে অসংখ্য বাগ ( ফেসবুক. com / board.php?uid=74769995908 ), যার মধ্যে আমি চালিয়েছি আমার মধ্যে টুইটার এর চেয়ে আলাদা নয়, প্রায়শই ডাউন ( ইঞ্জিনিয়ারিং.টিউইটি.টি.ভিটার .২০১০ / ২ / একাটমি- অফ-হোয়েল এইচটিএমএল ) এবং "ফলো বাগ" ( স্ট্যাটাস.টিউইউটার.কম / পোষ্ট /587210796/… এর মতো বাগের জন্য পরিচিত ) )।
ইয়াভেগেনি ব্রিকম্যান

9
চলমান গোলপোস্টগুলি ভুলে যাবেন না। আপনার পারফেক্টপ্রগ্রাম ০.০ এর বৈশিষ্ট্যটি 2.0
কার্লোস

4
@ কোডসইনচাওস: তত্ত্বটি বলে যে এমন কিছু প্রোগ্রাম রয়েছে যার জন্য তাদের আচরণ প্রমাণ করা অসম্ভব। এটি বলে না যে সমস্ত প্রোগ্রামের আচরণ প্রমাণ করা অসম্ভব । আমি অনুমান করব যে প্রচলিত প্রচলিত প্রোগ্রামগুলি প্রবণতাজনক টাইপের, এবং "থামানো সমস্যার কারণে আমার কোডটি বাগ-মুক্ত হওয়া অসম্ভব" দাবি করা তত্ত্বের একটি অপব্যবহার is
এন্ডোলিথ

98

"জিরো-বাগ প্রোগ্রামার" একটি নিরব গায়কের মতো একটি অক্সিমারন, তবে গত 60০ বা তার দশক ধরে প্রোগ্রামিং কিছু বুদ্ধিমানের বিচ্ছুরিত বিট তৈরি করেছে, যা আপনাকে আরও ভাল প্রোগ্রামার হিসাবে তৈরি করবে যেমন:

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

2
আমি প্রমাণ করতে পেরে খুশি হব যে আমার কোডটি কাজ করছে ... তবে পরীক্ষাগুলি কেবল প্রমাণ করতে পারে এটি তা নয়। আপনি কি এখানে আনুষ্ঠানিক প্রমাণের কথা বলছেন বা ডিবাগিংয়ের কাজটি কল্পনা করছেন এখানে?
ম্যাথিউ এম।

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

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

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

"প্লেগের মতো চালাক কৌশলগুলি এড়ান" - এই একা এই উত্তম উত্তরটি দিত। যেমনটি - এটি দুর্দান্ত।
BЈовић

25

TDD- এ

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

টিডিডি পদ্ধতি কমপক্ষে দুটি সুবিধা দেয়।

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

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

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

আমি বিশ্বাস করি যে টিডিডিতে উন্নত দলগুলি খুব কম ত্রুটিযুক্ত কোড সরবরাহ করে।


19

জিনিসটি হ'ল বাগগুলি এমন জিনিস যা আপনি চিনতে পারবেন না । প্রোগ্রামিং ভাষা / সংকলক পাশাপাশি আপনার অ্যাপ্লিকেশন যে সমস্ত পরিবেশে চালিত হবে সেগুলি সম্পর্কে আপনার কাছে এক ধরণের এনসাইক্লোপিডিক জ্ঞান না থাকলে আপনি সত্যই 100% বাগ-মুক্ত কোড তৈরি করতে পারবেন না।

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


1
+1 টি। পাকানো বোনের কথায়, আপনি যা জানেন না তা আপনাকে ক্ষতি করতে পারে / যা আপনি দেখতে পাচ্ছেন না তা আপনাকে চিৎকার করে তোলে।
ইঞ্জিনিয়ার

17

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

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

8

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

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

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

আপনি কতটি পেশার নাম রাখতে পারেন যা সর্বদা প্রথমবারের মতো সমাপ্তির সাথে পর্যালোচনা এবং / অথবা পরীক্ষা ছাড়াই তাদের কাজটি সম্পন্ন করে?


8

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

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

আপনি যতটা পারেন কোডটি তত সহজ রাখার ফলে আপনি বাগগুলি এড়াতে সহায়তা করবেন।

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


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

আমি বলব আপনার অ্যাডা দরকার তবে লিস্প আরও মজাদার। ;-)
শে

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

@ গ্যারি রো, আমি এই প্রতিক্রিয়াগুলি বুঝতে পেরেছি, হ্যাঁ, আমি কখনই কোনও সংস্থায় ছিলাম যেখানে একজন QA বিভাগ ছিল, '(আমি কিনা তারা Findbugs / PMD মত কিছু সরঞ্জাম ব্যবহার করা হয়েছে সম্পর্কে কোন ধারণা আছে), কিন্তু এটা পদক্ষেপ যে আপনি আছেন মত একটি সামান্য বিট শোনাচ্ছে।
এলেন

1
@ গ্যারি: আমার পক্ষ থেকে কোনও তর্ক নেই, তবে বেশ কয়েকটি জায়গায় আমি শৈলীর লঙ্ঘনকে বাগের সমতুল্য হিসাবে বিবেচনা করেছি। এবং তাদের স্টাইলের নিয়ম রয়েছে যেমন "প্রতিটি শ্রেণীর স্ট্যাটিক ক্ষেত্রগুলি CLS_PKG এবং সিএলএস_NAME যেমন প্যাকেজ এবং শ্রেণীর নাম ধারণ করে তা ঘোষণা করতে হবে"। আমি সাধারণত কোডিং মানগুলিকে সমর্থন করি তবে তারা যখন এ জাতীয় জিনিসগুলিতে পরিণত হয় তখন নয়!
টিএমএন

8

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

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

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

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


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

7

অন্য মন্তব্যগুলি ইতিমধ্যে সঠিকভাবে নির্দেশিত হিসাবে, বাগগুলি ব্যতীত তুচ্ছ কোনও সফ্টওয়্যার নেই।

আপনি যদি সফ্টওয়্যারটিকে সর্বদা মনে রাখতে চান তা পরীক্ষা করতে চান, এই পরীক্ষাগুলি কেবল ত্রুটিগুলির উপস্থিতি প্রমাণ করতে পারে তাদের অনুপস্থিতি নয়।

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

অবশ্যই এটির অর্থ এই নয় যে সফ্টওয়্যারটি আপনি যা চান ঠিক তা করেন। সম্পূর্ণ স্পেসিফিকেশন লেখা প্রায় সব ক্ষেত্রেই সম্ভব নয় possible এটি মূলত সেই জায়গাটিকে স্থানান্তরিত করে যেখানে ত্রুটিগুলি বাস্তবায়ন থেকে শুরু করে নির্দিষ্টকরণে যেতে পারে।

সুতরাং আপনার "বাগগুলির সংজ্ঞা" এর উপর নির্ভর করে আপনি আনুষ্ঠানিক যাচাইকরণ চেষ্টা করতে পারেন বা আপনার সফ্টওয়্যারটিতে যতগুলি বাগ পেতে পারেন সন্ধান করতে পারেন।


6

হয় "হ্যালো ওয়ার্ল্ড!" এর চেয়ে জটিল কিছু লিখবেন না! বা আপনি যদি প্রত্যেককে বলেন তবে এটি কখনই ব্যবহার করবেন না।

আপনার বসকে এই তথাকথিত বাগ ফ্রি কোডের কয়েকটি উদাহরণের জন্য জিজ্ঞাসা করুন।


5

আমি অন্যদের সাথে একমত আমি কীভাবে সমস্যাটির কাছে যাব তা এখানে

  • পরীক্ষক পান। কেন জোয়েল টেস্ট দেখুন।
  • গ্রন্থাগারগুলি ব্যাপকভাবে ব্যবহার করুন; সম্ভবত আরও ভাল ডিবাগ করা হয়েছে। আমি পার্লের সিপিএএন-এর একটি বড় অনুরাগী।

1
… তবে আপনি যদি লাইব্রেরি ব্যবহার করেন তবে নিশ্চিত হয়ে নিন যে তাদের বাগগুলি আপনাকে নীচে টেনে আনতে পারে না (উদাহরণস্বরূপ, উত্সটি রেখে যাতে আপনি এটি নিরীক্ষণ করতে পারেন বা প্রয়োজনে বাগগুলি নিজেই ঠিক করতে পারেন)।
সহস্রাব্দ

5

আপনি একটি শূন্য বাগ প্রোগ্রামার হতে চেষ্টা করতে পারেন। আমি যখনই কোড লিখছি তখন আমি শূন্য বাগ প্রোগ্রামার হওয়ার চেষ্টা করি। তবে, আমি না

  • একাধিক পরীক্ষার কৌশল নিযুক্ত করুন (এটিটিডিডি অন্য যেটি)
  • আমাদের সফ্টওয়্যারের আনুষ্ঠানিক যাচাইকরণ তৈরি করুন
  • একটি পৃথক কিউএ দল আছে
  • কোড বেসে করা প্রতিটি পরিবর্তন সম্পর্কে কঠোর বিশ্লেষণ করুন
  • এমন একটি ভাষা ব্যবহার করুন যা সুরক্ষা এবং সাবধানতার দিকে আরও ঝুঁকবে

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

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

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


4

আমি মনে করি যে "জিরো-বাগ" প্রোগ্রামার হওয়ার দিকে প্রথমে একটি ভাল পদক্ষেপ হ'ল বাগগুলির প্রতি আপনার দৃষ্টিভঙ্গি পরিবর্তন করা। "সেগুলি ঘটে", বলার পরিবর্তে আরও ভাল QA এবং পরীক্ষকগণ পান, "বা" বিকাশকারীরা পরীক্ষায় চুষেন, "বলুন:

ত্রুটি গ্রহণযোগ্য নয় এবং এগুলি দূর করার জন্য আমি আমার ক্ষমতার ভিতরে সবকিছু করব।

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


2

এক অর্থে, আপনার বস ঠিক আছে। শূন্য বাগগুলিতে আসা সফ্টওয়্যারটি লেখা সম্ভব।

কিন্তু সমস্যা হল খরচ লেখা (প্রায়) শূন্য বাগ প্রোগ্রাম করছেন হল নিষেধাজ্ঞামূলকভাবে উচ্চ । আপনার মতো কাজগুলি করা দরকার:

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

  • আপনার প্রোগ্রাম স্পেসিফিকেশন প্রয়োগ করে তা আনুষ্ঠানিকভাবে প্রমাণ করার জন্য উপপাদ্য প্রমাণকারী কৌশলগুলি ব্যবহার করুন।

  • বাগগুলির যে কোনও উপায়ে পরীক্ষা করার জন্য বিস্তৃত ইউনিট, রিগ্রেশন এবং সিস্টেম টেস্ট স্যুট এবং হারনেস তৈরি করুন। (এবং এটি নিজের মধ্যে যথেষ্ট নয়।)

  • হয়েছে অনেক মানুষ প্রয়োজনীয়তা (আনুষ্ঠানিক ও অনানুষ্ঠানিক), সফ্টওয়্যার (এবং প্রমাণগুলি) পর্যালোচনা করুন। পরীক্ষা, এবং মোতায়েন।

আপনার বস এই সমস্ত কিছুর জন্য অর্থ প্রদানের জন্য প্রস্তুত কিনা তা অত্যন্ত অসম্ভব বা ...


1

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


1

বাগ-ফ্রি-প্রোগ্রাম করার পদক্ষেপগুলি এখানে:

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

পরীক্ষা কেবল প্রমাণ করতে পারে যে আপনার কাছে বাগ রয়েছে তবে এটি অন্যথায় প্রমাণ করা সাধারণত অকেজো। প্রতিক্রিয়া সম্পর্কে - আপনার যদি মুদ্রা তৈরির মেশিন থাকে যা মুদ্রা তৈরি করে এবং প্রতি দশকের দশকের মুদ্রায় একটি ত্রুটি থাকে। আপনি এই মুদ্রাটি নিতে পারেন, এটিকে সমতল করুন এবং আবার মেশিনে প্রবেশ করতে পারেন। মুদ্রা যা পুনর্ব্যবহারযোগ্য ফাঁকা তৈরি করেছে তা তেমন ভাল হবে না, তবে সম্ভবত গ্রহণযোগ্য। প্রতি 100s মুদ্রা 2 বার আবার স্ট্যাম্প করতে হবে। মেশিন ঠিক করা কি সহজ হবে?

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

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


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

0

ডিফেন্সিয়ালি প্রোগ্রাম: http://en.wikedia.org/wiki/Defensive_programming

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


0

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

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

এটি বর্তমানে এমন সূক্ষ্ম করা বাগ, যতদিন আপনি পারেন এটি তাদের এবং ঠিক তাদের (অবশ্যই, কারণ মধ্যে)।


0

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

আপনার বসকে এমন একজনের মতো মনে হচ্ছে যারা "প্রোগ্রামিং সম্পর্কে এত কঠিন কী বুঝতে পারছেন না, কারণ এটি কেবল টাইপিং"


0

আমরা যদি ধরে নিই বড় সফ্টওয়্যার ঘর জানেন শীর্ষ খাঁজ ডেভেলপারদের পেতে কিভাবে (হিসাবে শূন্য বাগ প্রোগ্রামার ) আমরা কেটে করতে পারে Microsoft এর সফ্টওয়্যার হওয়া আবশ্যক বাগ ছাড়া। তবুও আমরা জানি এটি সত্য থেকে দূরে।

তাদের সফ্টওয়্যারটি বিকাশ করুন এবং যখন তারা নিম্ন অগ্রাধিকারের বাগের নির্দিষ্ট স্তরে পৌঁছায় তারা কেবল পণ্যটি ছেড়ে দেয় এবং সেগুলি পরে সমাধান করে।

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

ত্রুটিগুলি যেমন অনিবার্য হয় তেমনি ভুল হওয়া যেমন মানুষের প্রকৃতি।

কোনও বাগ নেই 100% সুরক্ষিত সিস্টেম থাকার মতো। যদি কোনও সিস্টেম ১০০% সুরক্ষিত থাকে তবে তা অবশ্যই কার্যকরভাবে কার্যকর হয় না (এটি সম্ভবত টন এবং টন কংক্রিটের মধ্যে রয়েছে এবং এটি বাইরের সাথে মোটেই সংযুক্ত নয় w তারযুক্ত বা বেতার নয় So ঠিক তেমন কোনও সুরক্ষিত সিস্টেম নেই বলে as , কোনও জটিল বাগ-কম সিস্টেম নেই।


-1

আমি কেবল আমাদের মানব এবং ভুলের প্রবণতা সম্পর্কে উত্তরগুলি দেখতে পাই যা খুব সত্য ... তবে আমি আপনার প্রশ্নটিকে অন্য দৃষ্টিকোণ থেকে দেখছি।

আমি মনে করি আপনি বাগ-মুক্ত প্রোগ্রাম লিখতে পারেন , তবে সেগুলি সাধারণত এমন প্রোগ্রাম যা আপনি ইতিমধ্যে 10 বা 12 বার লিখেছেন। 13 তমবার আপনি একই প্রোগ্রামটি স্ক্র্যাচ থেকে লেখেন, আপনি ইতিমধ্যে এটি কীভাবে করতে হবে তা জানেন: আপনি সমস্যাটি জানেন, আপনি কৌশলগুলি জানেন, আপনি গ্রন্থাগারগুলি, ভাষা জানেন ... আপনি এটি আপনার মনে দেখেন । সমস্ত নিদর্শন সব স্তরে আছে।

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

আমার বিশ্বাস হ'ল যদি আপনি সর্বদা আপনার স্তরের থেকে অনেক বেশি প্রোগ্রাম করার চেষ্টা করে থাকেন (আমি কয়েক বছর ধরে এটি করতে পেরেছি) তবে আপনি বিভ্রান্ত হয়ে পড়বেন এবং ভুল করবেন। বড় আকারের ভুলগুলি যেমন আপনি হঠাৎ বুঝতে পারেন যে আপনার সমাধানটি কাজ করতে পারে না, যখন আপনি শেষ পর্যন্ত সমস্যাটি বুঝতে পারেন এবং এমন জটিল পরিবর্তন করতে হবে যাতে তারা আপনাকে আপনার সমস্যার সমাধান করতে বাধা দিতে বা কোডটিকে ভয়ঙ্কর করে তুলতে পারে। টিডিডি এই মামলার জন্য, আমি বিশ্বাস করি। আপনি জানেন যে আপনি যে সমস্যাটি মোকাবেলা করছেন সেটিকে আপনি আঁকেন না এবং তাই আপনার একটি শক্ত ভিত্তি রয়েছে তা নিশ্চিত করার জন্য সর্বত্র পরীক্ষা করা put যদিও টিডিডি 10,000 ফুট দৃষ্টি সমাধান করে না। আপনি সর্বদা পুরোপুরি পরিষ্কার কোড সহ চেনাশোনাগুলিতে বেড়াতে পারেন।

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

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


-1

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


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

-1

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

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

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

আমি মনে করি কোড সম্পর্কে এক ধরণের ভাল স্বাদ নেমে আসে, যা আপনি অনুশীলন এবং পর্যালোচনা দিয়ে বিকাশ করতে পারেন এবং একইরকম সমস্যাযুক্ত লোকদের সম্পর্কে পড়তে পারেন।

শেষ পর্যন্ত, কোনও বাগ আশা করা মোটেও বৃথা, তবে আপনার বাগের গণনা হ্রাস করার চেষ্টা করার কোনও ক্ষতি নেই যদি না আপনার কাছে ইতিমধ্যে কিছুটা নিম্ন স্তরে থাকে এবং এটি আপনার সময় এবং যিনি খুঁজে পান তার সময়ের মধ্যে বাণিজ্য হয়ে যায় যে বাগ আপনি ধরেন না


-2

যদি আপনি বলতে চান: "কোডটি লেখার সময় শূন্য বাগ" -> এটি একটি দুর্দান্ত লক্ষ্য তবে বেশ অসম্ভব।

তবে আপনি যদি বলতে চান: "সরবরাহিত কোডে শূন্য বাগ" -> এটি সম্ভব এবং আমি এই জাতীয় পরিবেশে কাজ করেছি।

আপনার যা প্রয়োজন তা হ'ল: অত্যন্ত উচ্চ মানের গুণমান এবং প্রায় 100% পরীক্ষার কভারেজ (ইউনিট পরীক্ষাগুলি + গ্রহণযোগ্যতা পরীক্ষা + ইন্টিগ্রেশন পরীক্ষা) tests

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

সবার আগে আপনার এমন একজন বসের দরকার যারা উচ্চমানের বিষয়ে সত্যই আগ্রহী এবং এর জন্য অর্থ দিতে আগ্রহী।


-3

প্রোগ্রামারের সমাধান:

  • প্রোগ্রামিং বন্ধ করুন।
  • একটি যান্ত্রিক কম্পিউটার তৈরি করুন।
  • প্রতি 5 বছর অন্তর এটি প্রতিস্থাপন করুন যাতে যান্ত্রিক পরিধান কার্যকর না হয়।

ব্যবহারকারীর সমাধান:

  • কম্পিউটার ব্যবহার বন্ধ করুন।
  • ম্যানুয়ালি সবকিছু করুন।
  • সর্বদা দ্বিতীয় ব্যক্তির ফলাফলগুলি ডাবল-চেক করুন।

-3

আমি সম্মত হই যে শূন্য-বাগ প্রোগ্রামার হওয়ার জন্য আপনি কেবল প্রোগ্রাম / কোড করতে পারবেন না। এটি বাগের মুখোমুখি হওয়া এবং বিকাশ করা প্রতিটি প্রোগ্রামারের জীবনের অংশ। কোনও seasonতুবিহীন বিকাশকারী হৃদয়ে হাত রাখতে পারেন না, তারা তাদের কোডটিতে কোনও ত্রুটির মুখোমুখি হয়নি।


-4

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

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