আপনি কী সফ্টওয়্যার ত্রুটিগুলির প্রধান কারণ হিসাবে বিবেচনা করেন (এবং কীভাবে এটি হ্রাস করবেন) [বন্ধ]

14

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

8 বছর আগে বন্ধ ছিল ।

আমি ত্রুটিটিকে সংজ্ঞায়িত করি :

"অ্যাপ্লিকেশন ডিজাইন বা কোডের মধ্যে এমন কিছু যা এটি প্রয়োজনীয়তা অনুসারে কাজ করতে বাধা দেয়" "

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

experience programming-practices bug

— ক্রিস বালতি
সূত্র

5

এমনকি "প্রয়োজনীয়তাগুলি" "ব্যবহারকারীর প্রয়োজনগুলি" বা "প্রত্যাশিত আচরণ" দ্বারা প্রতিস্থাপন করব যেহেতু প্রয়োজনীয়তাগুলিও ভুল হতে পারে।

— mouviciel

প্রয়োজনীয়তা ভুল যে? (এবং কোডটি সঠিক?)

13

সফ্টওয়্যার ত্রুটিগুলির প্রধান কারণটি হ'ল ব্যাখ্যা।

কোনও বৈশিষ্ট্যের গ্রাহক ব্যাখ্যা ডিজাইনারের ব্যাখ্যার থেকে পৃথক।

ডিজাইনার ব্যাখ্যা প্রোগ্রামার ব্যাখ্যার থেকে পৃথক।

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

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

— তুন কৃজেতে
সূত্র

যদি আমি কেবল সেই ডার্ন মাইন্ড-রিডার মডিউলটি কাজ করতে পারি তবে সমস্ত ঠিক আছে।

— এইচএলজিইএম

@ গেম্যাক্যাট: সারা বিশ্বের মানুষের সাথে কাজ করার সময় এটি আরও খারাপ হয়। কেবলমাত্র একটি ভাষা বাধা নেই (প্রায়শই অংশগ্রহীনের মধ্যে অন্তত একজন ইংরেজিতে দক্ষ হন না) তবে সাংস্কৃতিক পার্থক্যও রয়েছে।

— ম্যাথিউ এম।

2

আপনি একটি মিস করেছেন - "প্রোগ্রামারটির ব্যাখ্যা সংকলকের ব্যাখ্যার থেকে পৃথক" ...;)

— অ্যালেক্স ফেনম্যান

@ অ্যালেক্স: আমি জানি কোডটি আমার সাথে সংকলকটি কী করবে। এই জ্ঞান অর্জন করা সহজ ছিল না, তবে আমি তা করেছিলাম did সংকলক এবং রানটাইম ডেটার বিপরীতে এখন, আমি যে কোডটি লিখি না তার সম্পর্কে আমাদের ব্যাখ্যা রয়েছে।

— ডেভিড থর্নলি

@ ডেভিড, আপনি যদি লেখেন না এবং সংকলকটি বজায় না রাখেন তবে আভ্যন্তরীণরা কী করছে সে সম্পর্কে আপনার জ্ঞানটি আসলে কী চলছে তার বিমূর্ততা - এবং এটি সম্ভবত সেরাটির জন্য, কারণ এটি আপনাকে আসল অ্যাপ্লিকেশনটিতে ব্রেইনস্পেস ব্যয় করতে দেয়।

— অ্যালেক্স ফেইনম্যান

8

আমি সফ্টওয়্যার ত্রুটিগুলির প্রধান কারণটিকে প্রোগ্রামার হিসাবে বিবেচনা করি।

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

এর একটি অংশ শেষ ব্যবহারকারীটির পরিভাষা শিখতে / বুঝতে ইচ্ছুক না হওয়া থেকে ভুল বোঝাবুঝির কারণ আসে।

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

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

— AnonJr
সূত্র

8

ত্রুটিগুলির প্রাথমিক কারণটি হ'ল খারাপ পরিচালনা ;)

সিরিয়াসলি, এমন একটি বিকাশকারী যা ভাল অবস্থায় কাজ করে, তাকে অতিরিক্ত কাজ করতে বলা হয় না, গুণমানকে কাটাতে বলা হয়, সঠিক সরঞ্জামাদি থাকে, শান্ত কাজের পরিস্থিতি থাকে এবং এর ফলে কঠোর চাপে কাজ করা ব্যক্তির চেয়ে কম বাগ তৈরি করতে পারে।

এছাড়াও খারাপ বিকাশকারীদের নিয়োগের ব্যবস্থাপনাগুলি বাগের সংখ্যা বাড়াতে সহায়তা করে।

খারাপ পরিচালনা ।

(অস্বীকৃতি: আমি বিকাশকারীদের পরিচালনা ও পরিচালনা করার কথা)

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

— radekg

1

বেশিরভাগ ডেভস কীভাবে শান্ত অবস্থায় কাজ করে? গত এক বছরে আমি ডজন ডজন সংস্থাগুলি ঘুরেছি, কোনওটিই শান্ত ছিল না।

ভাল পরিচালনা আপনাকে দূরে নিয়ে যেতে পারে, খারাপ পরিচালনা আপনাকে কোনও স্থানে নিয়ে যেতে পারে!

— ক্রিস

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

— ববি টেবিলগুলি

5

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

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

— অ্যালেক্স ফেনম্যান
সূত্র

4

সব কিছু ভাবতে অক্ষমতা।

— JeffO
সূত্র

4

Incomplet হচ্ছে

— ওঙ্কো দ্য সনে
সূত্র

4

যোগাযোগের ব্যবধান। প্রয়োজনীয়তা সংগ্রহে। সময়সূচীতে। নকশা নথিতে। কার্যকরী স্পেসিফিকেশন। কোডে (প্রোগ্রামার কী চায় এবং কম্পাইলারকে কী বলে তার মধ্যে ফাঁক)।

সামাজিক শিষ্টাচার. কাউকে অক্ষম বলা সামাজিকভাবে অগ্রহণযোগ্য।

— aufather
সূত্র

3

সম্পূর্ণরূপে না বুঝে জিনিসগুলিতে ছুটে যাওয়া। কার্যকরী প্রয়োজনীয়তা বা প্রযুক্তিগত আর্কিটেকচারকে পুরোপুরি না বুঝেই কোড লেখা শুরু করা।

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

— জোয়েরি সেব্রেচটস
সূত্র

চার মাস একটি নতুন কাজের জন্য, আমি এখনও কিছুতেই "সম্পূর্ণ বোঝার" মধ্যে খুব কম মাত্র% আমি ছুটে যাচ্ছি না; আপনি কি বলতে সত্য. যদিও এত দীর্ঘ সময় ধরে অনুপাতহীন হতে চাই।

— DarenW

আমি যে সিস্টেমে কাজ করি (2 মিলিয়ন লাইন সিস্টেম) তার সম্পূর্ণ গতি পেতে আমার এক বা দুই বছর সময় লেগেছিল। তারপরেও এর বৃহত অংশগুলি রয়েছে যা আমি কেবল জানি না।

— জোয়ারি সেব্রেচটস

2

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

— mouviciel
সূত্র

2

তফসিল চাপ সত্যই শক্তিশালী উত্স।

রাশযুক্ত বিকাশকারীরা প্রয়োজনীয়তাগুলি সম্পূর্ণরূপে নির্দিষ্ট করতে, প্রয়োজনীয়তার পিছনে উদ্দেশ্যটি সম্পূর্ণরূপে বুঝতে, বা সর্বোত্তম সমাধান খুঁজতে বিকল্পগুলি সম্পূর্ণ তদন্ত করতে, বা সমস্ত প্রান্তের কেস এবং তারা যে পরিবর্তনগুলি করছে তার পারস্পরিক ক্রিয়া সম্পর্কে পুরোপুরি চিন্তা করে না, বা পরীক্ষার কেসগুলির একটি সম্পূর্ণ সেট বিকাশ করুন, বা সমস্ত ইউনিট পরীক্ষা সম্পূর্ণরূপে সম্পাদন করুন, বা একটি সম্পূর্ণ ইন্টিগ্রেশন পরীক্ষা করুন, বা প্ল্যাটফর্ম নির্ভরতা পুরোপুরি বিবেচনা করুন, বা ইনস্টলারকে পুরোপুরি পরীক্ষা করুন, বা তারা কী করেছে তা সম্পূর্ণ নথিভুক্ত করুন যাতে পরবর্তী বিকাশকারী বুঝতে পারে ....

— AShelly
সূত্র

2

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

— HLGEM
সূত্র

2

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

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

— পিটার আইসেন্ট্রাট
সূত্র

1

সফ্টওয়্যারকে রাষ্ট্রীয় মেশিনগুলির একটি নেটওয়ার্ক হিসাবে বোঝার ব্যর্থতা, তাদের ক্রিয়াকলাপের নীতির নীতিগুলি (রাজ্যগুলি, তাদের সংকল্প এবং স্থানান্তরগুলি) এবং রাষ্ট্রীয় মেশিনগুলির মিথস্ক্রিয়া।

— Huperniketes
সূত্র

1

লিখিত কোড যা নিঃশব্দে বনাম বনাম কোড যা সমস্ত ত্রুটির প্রতিবেদন করে।

— bjornl
সূত্র

1

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

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

— dsimcha
সূত্র

1

সফ্টওয়্যার ত্রুটিগুলির প্রধান কারণ হ'ল কোড লেখা।

কম কোড লিখুন এবং আপনার কাছে কম বাগ রয়েছে ;-)

— nlawalker
সূত্র

0

এক পর্যায়ে, ব্যবস্থাপনা। তবে এটি কেবল পিএইচবি নয়। এটি কোডের নিজেই পরিচালনা, যা কর্পোরেট পরিচালনার প্রতিচ্ছবি হতে পারে বা নাও হতে পারে।

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

— পল নাথান
সূত্র