বড় আকারের সফ্টওয়্যারগুলির জন্য কি পরম শূন্য বাগের স্থানে পৌঁছানো সম্ভব?


71

আমি উদাহরণস্বরূপ অটোডেস্ক মায়ার স্কেল এবং জটিলতায় 20-30 + মিলিয়ন কোডের লাইন, সফ্টওয়্যার সম্পর্কে বলছি।

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

কারণ কিছু ধারণা আছে যে আপনার করা প্রতিটি ফিক্স আরও বেশি বাগ তৈরি করে, তবে আমি এটি সত্য বলে মনে করি না।

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


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

51
আপনি যদি জানেন না যে একটি ত্রুটি এখনও উপস্থিত রয়েছে, তবে এটি কি এখনও বাগ রয়েছে?
Blrfl

5
@ ব্লুফ: আরও গুরুত্বপূর্ণ বিষয়, যদি শেষ ব্যবহারকারীটি বাগটি জানত না তবে কী এটি বিদ্যমান?
mattnz

40
“একটি সফ্টওয়্যার ডিজাইন তৈরির দুটি উপায় রয়েছে। একটি উপায় হ'ল এটিকে এত সহজ করা যে স্পষ্টত কোনও ঘাটতি নেই। এবং অন্য উপায় এটি এত জটিল করা যে কোনও সুস্পষ্ট ঘাটতি নেই ”" - সিএআর হোয়ার
অ্যান্ড্রু লুইস

5
এটি হ'ল, তবে অনেক লোকই তাদের মৌলিক বিশ্বাসকে প্রশ্নবিদ্ধ করতে চায় না।
জোয়ান ভেনজে

উত্তর:


92

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

মূল বক্তব্যটি হ'ল আপনি সফ্টওয়্যারটির জটিলতাটিকে ব্যাপকভাবে অবমূল্যায়ন করছেন।

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

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

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

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

নীচের লাইন: আপনি কি "বাগ ফ্রি সফটওয়্যার" লিখতে পারেন?

কোন

যে কেউ আপনাকে অন্যথায় বলে সে অবাস্তব।

কেবল এমন সফ্টওয়্যার লেখার চেষ্টা করুন যা বোঝার এবং বজায় রাখা সহজ। এটি একবার হয়ে গেলে আপনি এটিকে একদিন কল করতে পারেন।


সম্পাদনা: কিছু লোক একটি দুর্দান্ত পয়েন্ট সম্পর্কে মন্তব্য করেছিল যা আমি সম্পূর্ণরূপে উপেক্ষা করেছি: সংকলক।

আপনি যদি সমাবেশে না লিখেন তবে সম্পূর্ণরূপে সম্ভব যে সংকলকটি আপনার কোডগুলিকে গোলমাল করবে (এমনকি আপনি যদি প্রমাণ করেন যে আপনার কোডটি "নিখুঁত")।

জিসিসিতে বাগগুলির একটি তালিকা, সর্বাধিক ব্যবহৃত ব্যবহৃত সংকলকগুলির মধ্যে একটি: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---


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

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

11
@ জনআর.স্ট্রোহম আমি নিশ্চিত নই যে আপনি কেন 'ম্যাসেজ ফ্লো মডিউলেটর' প্রোগ্রাম, 556 লাইনের কোড সহ একটি প্রোগ্রাম, একটি তাত্ত্বিক 20 মিলিয়ন লাইন সিস্টেম সম্পর্কিত কোনও প্রশ্ন আছে। ক্ষুদ্র কর্মসূচির যথার্থতা প্রমাণ করা যেহেতু শক্ত ছিল তা প্রমাণ করার পরিবর্তে, জ্যোতির্বিদ্যার দিক থেকে একটি বৃহত একটির যথার্থতা প্রমাণ করা আরও শক্ত হবে।
এরিক কিং

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

4
@ জনআর.স্ট্রোহম আপনার কাগজটি আরও মনোযোগ সহকারে পড়া উচিত। তারা নিজেরাই বলে: It is important to note, however, that even all of these steps provide no guarantee of absolute security. It is tempting to believe that a formally specified and proved program should be absolutely correct, but there are several reasons why a proved program may not behave exactly as expected.- অর্থ, এটি বাগ মুক্ত হিসাবে প্রমাণিত হতে পারে না, তবে বাগগুলি থাকার সম্ভাবনা কম less বরং টিডিডির মতো।
ইজকাটা

27

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

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

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

ব্যবহারযোগ্য: সিস্টেম এটির জন্য ডিজাইন করা প্রয়োজনীয় প্রয়োজনীয়তা পূরণ করে। ত্রুটি থাকতে পারে - তবে সেগুলি 'এজ কেসস'-এ হতে পারে - বিদেশী বা বিরক্তিকর, সিস্টেমের মৌলিক বিষয়গুলিকে সমঝোতা করে এমন বাগগুলি নয় - শক্তিশালী।

রক্ষণাবেক্ষণযোগ্য: বাগগুলি সহজেই বিচ্ছিন্ন এবং স্থির করা যায় এবং নতুন বাগ তৈরি করা যায় না।

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

ভাল ডিজাইনের অনুশীলন, ভাল নিয়ন্ত্রণের অনুশীলন, ভাল টিম ওয়ার্ক, বিবেকবান বিকাশকারী - এটি ভাল সফটওয়ারের সূত্র । ( পারফেক্ট নয় - তবে ভাল )


3
"এটি প্রমাণ করাও গাণিতিকভাবে সম্ভব, একটি টেস্ট সিস্টেম ডিজাইন করে যা প্রতিটি সম্ভাব্য পদ্ধতিতে প্রতিটি লাইন কোডের অনুশীলন করে।": এই জাতীয় প্রোগ্রামটি সাধারণত বিদ্যমান নেই (এবং এটি প্রমাণিত হতে পারে!)। সুতরাং সঠিকতা প্রমাণের জন্য একটি সাধারণ অ্যালগরিদম বিদ্যমান নেই।
জর্জিও

3
সংশোধন: ত্রুটি-মুক্ত সফটওয়্যার, সংক্ষিপ্ততার ফর্মাল ম্যাথমেটিকাল প্রুফ সহ সম্পূর্ণ করা হয়েছে। এটি 1982 সালে করা হয়েছিল Google গুগল "বার্তা প্রবাহ মডুলার"।
জন আর স্ট্রোহম

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

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

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

27

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

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

বাজেট কোনও সমস্যা ছিল না - প্রতি বছরে i 35 মিলিয়ন ডলারে তারা জিনিসগুলি সঠিকভাবে করতে পারে।


25
এক সনাক্ত করা ত্রুটি প্রতিটি। কয়টি সনাক্ত করা ত্রুটি জানে? :)
এন্ড্রেস এফ

8
"এক ত্রুটি" এটি একটি বিশেষ কেস ছিল। শাটলটি মূলত দুটি রোবটের অস্ত্রের জন্য ডিজাইন করা হয়েছিল এবং সফ্টওয়্যারটি নির্দিষ্ট করা হয়েছিল। "ত্রুটি "টি ছিল যে দ্বিতীয় বাহুটিকে সমর্থন করার জন্য সেখানে এখনও কোড ছিল।
জন আর স্ট্রোহম

4
1981 থেকে 2011 পর্যন্ত 135 মিশনের জন্য ত্রুটিবিহীন +1
দৌড়েছিল

5
@ মারকজে: স্পেস শাটলে আসলে ত্রুটি না থাকলে আমরা সম্ভবত জানতাম না। প্রতিটি স্পেস শাটল মিশন ক্রমাগত, বেশ কয়েক'শ লোক দ্বারা তদারকি করা হয়, এবং কোডিংয়ের কোনও ত্রুটি ম্যানুয়ালি সংশোধন / ওভাররাইড করা হত।
মিথ্যা রায়ান

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

15

মূলত, না তবে আপনাকে যাইহোক সেরা চেষ্টা করা উচিত। আমি ব্যাখ্যা করব কেন (বা আপনার যদি যথেষ্ট ধৈর্য না থাকে তবে উপসংহারে চলে যান)

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

যে কোনও উপায়ে আমরা একটি বিশাল প্রোগ্রামের আশা করতে পারি যে কতগুলি বাগ রয়েছে? আমি খুঁজে পেয়েছি একটি নম্বর ছিল "1000 লাইন প্রতি 10 ত্রুটি" (কোড সম্পূর্ণ দ্বিতীয় সংস্করণ, পৃষ্ঠা 517 - নিছক উদাহরণ ব্যবহার করা হয়েছে, কোনও তথ্য উদ্ধৃত না করে) যা আমাদের সফ্টওয়্যারটিতে প্রায় 200 000 থেকে 300 000 বাগ দেয়। ভাগ্যক্রমে, আমাদের প্রোগ্রামের মান উন্নত করার উপায় আছে। ইউনিট পরীক্ষা, কোড পর্যালোচনা এবং সাধারণ ম্যানুয়াল টেস্টিং বাগের সংখ্যা হ্রাস করার জন্য পরিচিত known তবুও, সংখ্যাটি এখনও বেশি থাকবে।

যদি আমরা সমস্ত বাগের 95% সমাধান করতে পারি যা অবিশ্বাস্য হবে। এবং এখনও আমাদের সফ্টওয়্যারটিতে 10 000 থেকে 15 000 বাগ রয়েছে।

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

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

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

সুতরাং স্পষ্টতই, আমরা বাগের সংখ্যা ব্যাপকভাবে হ্রাস করতে পারি, তবে সত্যিই অসম্ভব যে আমরা কখনই শূন্যতে যাব।

কারণ কিছু ধারণা আছে যে আপনার করা প্রতিটি ফিক্স আরও বেশি বাগ তৈরি করে, তবে আমি এটি সত্য বলে মনে করি না।

(সামনে জোর দাও)

আপনি সঠিক. এই বক্তব্য ভুল। এখানে একটি উদাহরণ:

int main() {
    int x[10];
    x[10] = 8; //Buffer overflow here
    return 0;
}

এখন, এই বাগটি ঠিক করা যাক:

int main() {
    int x[11];
    x[10] = 8; //No buffer overflow here
    return 0;
}

দেখা? আমরা একটি বাগ স্থির করেছি এবং নতুন কোনও পরিচয় করিয়ে দিই নি।

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

ধরা যাক যে আমি ঠিক করেছি প্রতি 100 টি বাগের জন্য, আমি ঘটনাক্রমে একটি নতুন প্রবর্তন করি। সুতরাং আমি যদি 10 000 বাগগুলি ঠিক করি তবে আমি 100 টি নতুন বাগ প্রবর্তন করব। এবং যদি আমি এই নতুন বাগগুলি ঠিক করি তবে আমি একটি বাগ প্রবর্তন করব। তবে কি? প্রোগ্রামটিতে এখন 999 টি কম বাগ রয়েছে, সুতরাং এটি সম্ভবত এটির চেয়ে ভাল better

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

আমি কয়েক শীর্ষ প্রোগ্রামার দ্বারা প্রবীণ ছিলাম যে আমি ওপিতে উল্লেখ করেছি সেই ধারণার কারণে প্রচুর বাগগুলি ঠিক করা ভাল নয় better

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

আপনারা যত কম ত্রুটি সংশোধন করবেন, ভবিষ্যতে কম ত্রুটিগুলি আপনার কাছে ফিরে আসবে

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

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

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

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

উপসংহার:

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

+1: আমি নিজেই বাইনারি অনুসন্ধানের উদাহরণটি সন্ধান করছিলাম, এতে মারধর করা হয়েছিল;) যদি বিস্তৃত আলোচিত এবং প্রচারিত কোডের 20 টি লাইন 20 বছর ধরে বাগ থাকে তবে আপনার 20 মিলিয়ন লাইন কোডবেসের জন্য কতটা সময় প্রয়োজন? বেশ কয়েক ডজন ব্যস্ত মানুষ কি কখনও তাকিয়ে থাকবেন?
scrwtp

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

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

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

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

12

বাগ-মুক্ত প্রোগ্রাম না লেখার কারণগুলি বেশিরভাগই অর্থনৈতিক।

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

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

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

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

পরিবর্তে সমস্যাটি হ'ল:

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

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

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

যদি আপনি যতক্ষণ উন্নয়ন প্রয়োজন ততক্ষণ হিমশীতল করেন, কেবলমাত্র একটি বাগ না পাওয়া অবধি আপনি কি সমস্ত বাগ ঠিক করতে পারবেন, যদি কম্পিউটারের মাধ্যমে এই জাতীয় জিনিসটি যাচাই করা যায়?

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

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


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

1
"ব্যয়বহুল" আপেক্ষিক। বাগের সন্ধান এবং ফিক্সিংয়ের ব্যয়ের সাথে তুলনা করুন যেমন একটি রেডিওথেরাপি মেশিন বেশ কয়েকটি রোগীকে মেরে ফেলেছে এবং বেশ কয়েকজনকে মাইমিং করেছে। (গুগল "থেরাক 25"।)
জন আর স্ট্রোহম

6

না।

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

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


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

প্রাসঙ্গিক তাত্ত্বিক পটভূমি উদ্ধৃত করার জন্য +1। আমি এখনও জানতাম না যে "এন্টশেডংস্প্রোব্লেম" জার্মান ভাষায় ইংরেজিতে একই বলা হয়!
পিপলওয়্যার

5
ড্যানিয়েলের সাথে একমত চ্যালেঞ্জ একক উদাহরণ সম্পর্কে; থামানো সমস্যাগুলি সমস্ত সম্ভাব্য দৃষ্টান্তগুলির সাথে সম্পর্কিত। তুচ্ছভাবে int main() { return 0; } থামে এবং বাগ-মুক্ত।
এমসাল্টার

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

6

ত্রুটিযুক্ত মানব

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

এমনকি যদি আপনি একটি আনুষ্ঠানিক নির্দিষ্টকরণের ভাষা ব্যবহার করেন,

এক বা একাধিক মস্তিষ্ক থেকে কম্পিউটারে ব্যবহারকারীর প্রয়োজনীয়তা আহরণে সর্বদা একটি মানব পদক্ষেপ থাকে।

এই মানব পদক্ষেপটি ত্রুটি-প্রবণ এবং কীটটি আপেলের মধ্যে রয়েছে।


1
এটি কি এখনও বাগ রয়েছে যখন কোনও প্রোগ্রাম যা জিজ্ঞাসিত হয়েছিল তা পরিবর্তে কী উদ্দেশ্যে করা হয়েছিল?
এমসাল্টার

আমি মনে করি এটি ..
জোয়ান ভেনজ

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

3

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

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

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

সংক্ষেপে:

না।


+1 একজন বিকাশকারী এবং গ্রাহকের কীভাবে 'বাগ' সংজ্ঞায়িত করা যায় সে সম্পর্কে বিভিন্ন মতামত থাকতে পারে।
গ্র্যান্ডমাস্টারবি

তবে কী যদি ডেভেলপারও ব্যবহারকারী হয়? আমি সেই ব্যক্তিদের কাছ থেকে ব্যবহারের দিক থেকে সর্বোত্তম সফ্টওয়্যার খুঁজে পাই কারণ তারা ঠিক কীভাবে কীভাবে কাজ করা উচিত তা জানে ইত্যাদি
জোয়ান ভেঞ্জ

2

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


1

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

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

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


1

কম্পিউটার অংশ দ্বারা যাচাইকরণ সম্পর্কে।

কম্পিউটার ব্যবহার করে একটি প্রোগ্রাম যাচাই করার দুটি উপায় রয়েছে। একটি পরীক্ষা করছে, অন্যটি প্রুফ সিস্টেম ব্যবহার করছে।

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

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


ডোনাল্ড নুথের (স্মৃতি থেকে) উদ্ধৃতি দেওয়ার জন্য: আপনি প্রমাণ করতে পারেন যে কোনও প্রোগ্রাম
বাগমুক্ত

1

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

হার্ডওয়্যার এবং ওএসকে বাদ দিয়ে সর্বাধিক উল্লেখযোগ্য অ্যাপসের নীচে এমন অনেকগুলি মিডলওয়্যার পণ্য রয়েছে যা আপনার নিয়ন্ত্রণের বাইরেও বিকশিত হবে এবং ঠিক যেমন আপনি আপনার কোডটি শূন্য ত্রুটিযুক্ত অবস্থানে পৌঁছেছেন আপনাকে নীচের স্তরগুলি EOL'ed করবে।

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

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


0

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

এটি একটি अस्पष्ट জিনিস। কয়েকটি সিস্টেম শেষ বিট নিচে নির্দিষ্ট করা আছে। যদি কোনও সিস্টেম ভালভাবে কাজ করে এবং ব্যবহারকারীদের কোনও অভিযোগ না থাকে (তারা কোনও কিছুতেই বুগ হয় না) এবং তারা এটির সাথে পুরোপুরি খাপ খায় তবে আপনি এটিকে বাগ ফ্রিও বলতে পারেন।


-2

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

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

আমার নিজস্ব যুক্তি নিম্নরূপ:

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

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

এই প্রোগ্রামাররা তাই অন্যের অর্থ প্রয়োজনীয় সফটওয়্যারগুলিতে রূপান্তর করার কাজ করে। এই অর্থটি ভাল কাজে লাগানো তাদের দায়িত্ব responsibility

আপনার প্রশ্নের সাথে এটির নীচের বিষয়গুলি রয়েছে:

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

এটি সমস্ত অর্থ সম্পর্কে এবং ঠিক তাই।


-2

হ্যাঁ.

আপনি যেমন জানেন, এটির পক্ষে এটির জন্য অনেক বেশি প্রচেষ্টা প্রয়োজন।

আমি আমার উত্তরটি রক্ষা করার আগে, আমাদের প্রথমে একটি বাগটি কী তা নির্ধারণ করতে হবে:

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

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

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

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

"তবে আমাকে দাঁড়ানোর জায়গা দিন, এবং আমি বিশ্বকে সরিয়ে নেব।" - আর্কিমিডিস


এটি প্রচেষ্টা প্রয়োজন, কিন্তু যা পরিশোধ করে pay
লরেন্ট এলএ রিজ্জা

1
যদি আপনি সমীকরণের বাইরে স্পেসিফিকেশন বাগগুলি ছেড়ে যান তবে আপনার সম্পূর্ণ সফ্টওয়্যারটি অকেজো হয়ে যায়: স্পেসিফিকেশনগুলি কেবল অপেক্ষাকৃত আনুষ্ঠানিক উপায়ে ব্যবহারকারীর প্রয়োজনগুলি লেখার জন্য সরঞ্জাম, তবে শেষ পর্যন্ত এটি ব্যবহারকারীকেই সন্তুষ্ট হওয়া দরকার, স্পেসিফিকেশন নয়। এবং স্পেসিফিকেশন তৈরি করা কোড লেখার মতো সফটওয়্যার বিকাশের অনেক অংশ। সর্বোপরি, একটি সম্পূর্ণ ফর্মাল স্পেস চূড়ান্ত কোডের মতোই সিস্টেমের আচরণের বর্ণনা দেয়, অনুমানটি কেবল দক্ষতার সাথে সম্পাদনযোগ্য নয়।
সাস্টার
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.