কোনও সমস্যা সমাধানের জন্য প্রোগ্রামিং দৃষ্টান্ত বেছে নেওয়ার অভিজ্ঞতাগত প্রমাণ


11

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

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

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

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

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


1
জন্য ওয়েব অনুসন্ধান তথ্যপ্রমাণ ভিত্তিক সফটওয়্যার ইঞ্জিনিয়ারিং শো প্রচুর লিঙ্ক
মশা

@ গ্যাनेट ইবিএসই হ'ল নিয়মিতভাবে সাহিত্যের সংক্ষিপ্তসার এবং আমরা কীভাবে অনুশীলনকে আরও উন্নত করতে পারি সে সম্পর্কে সাধারণ সিদ্ধান্তগুলি আঁকতে। আমার প্রশ্ন সেই সাহিত্যের উপস্থিতি আছে কি না; পদ্ধতিগত পর্যালোচনা বা মেটাআনালাইসেস উত্পাদনশীল হওয়ার পক্ষে যথেষ্ট কিনা।

উত্তর:


12

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

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

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

সুতরাং, সফ্টওয়্যার ইঞ্জিনিয়ারিং এ এই ধারণা বিদ্যমান। একাডেমিয়া প্রমাণ-ভিত্তিক ধারণা সম্পর্কে অবগত এবং এটি সফলভাবে সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ে প্রয়োগ করতে পারে।

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

দৃষ্টান্ত বাছাইয়ের জন্য অবশ্যই "টার্ন ক্র্যাঙ্ক" সমাধান নেই।

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

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

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

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

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

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


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

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

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

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

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

8

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

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

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

- স্টিভ জনসন

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

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

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

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


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

+1, "দ্বিতীয় সমস্যাটি হ'ল 50% বিকাশকারীদের গড় প্রোগ্রামিং প্রতিভা কম।" এই বাক্যটি আমার জন্য স্বস্তি। আমি চেষ্টা করা অনেক
বড়িগুলির

3

প্রোগ্রামিং প্রতিযোগিতা রয়েছে যা একটি কম্পিউটার গ্রেডিং সিস্টেম ব্যবহার করে এবং আপনাকে বিভিন্ন ভাষায় লেখার এবং সমস্ত ধরণের ফলাফল এবং জিনিস পোস্ট করার অনুমতি দেয়। আমি বাজি ধরছি তাদের কাছে আপনার জন্য ভাল ডেটা রয়েছে। এখানে 8 টির একটি তালিকা রয়েছে: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

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

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

আমি অনুমান করছি যে আমি যা বলছি তা হ'ল বাস্তব বিশ্বের অ্যাপ্লিকেশনগুলির জন্য, ভাষা বা সরঞ্জামগুলিকে অর্থবহ উপায়ে তুলনা করা অত্যন্ত কঠিন - পুরানো আপেল এবং কমলা ইস্যু। শুভকামনা! আপনি যা খুঁজে পান তা দেখতে আমি পছন্দ করি।


2

আমি 30+ বছর ধরে সফ্টওয়্যার বিকাশের বিভিন্ন উপায়ে অধ্যয়ন করছি। দৃষ্টান্ত বেছে নেওয়ার বিষয়ে ভাল প্রকাশিত প্রমাণের অভাব রয়েছে।

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

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

এখন PARADIGM সন্ধান করুন এবং ট্যাগগুলি গণনা করুন

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

আপনি যদি আরও গভীর খনন করতে চান তবে http://cse.csusb.edu/dick/lab.html এবং আমি আশা করি এটি সাহায্য করবে ...


1

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

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

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

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


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

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

2
আমি আপনার উত্সাহ প্রশংসা করি। চিকিত্সা বিজ্ঞান এবং সফ্টওয়্যার বিকাশ মূলত বিভিন্ন শাখা। সাদৃশ্যটি আকর্ষণীয় হলেও এটি খুব কমই মজাদার। সম্পূর্ণ কাগজটি এখানে পাওয়া যাবে Labada.inf.utfsm.cl/~gvaldes/ESE/docs/… ধারা 5 বিমূর্তে উল্লিখিত প্রতিবন্ধকতা মেলেম্যাচ প্রতিফলিত করে। চিকিত্সা কৌশলগুলির আরও একটি সরাসরি ম্যাপিং হ'ল বিদ্যমান সিস্টেমগুলি ডিবাগ করা, নতুন তৈরি না করা। ;) আপনি আরও ভাল পণ্য বানাতে চাইলে আরও ভাল দল তৈরি করুন। লোকগুলি সরঞ্জামগুলির চেয়ে অনেক বেশি গুরুত্বপূর্ণ (সিএফ পিপলওয়্যার)
স্টিভেন এ লো।

1
সংযোজন: EBSE সাইটের কিছু দরকারী তথ্য রয়েছে, dur.ac.uk/ebse/evidence.php বিশেষত এসই ক্ষেত্রে নতুন যারা তাদের জন্য দরকারী হবে - তবে লবণ একটি ব্লক দিয়ে সমীক্ষা নিন, কারণ (1) প্রমাণ উপলব্ধ অপ্রতুল এবং (2) গড় ফলাফল অত্যন্ত বিশেষ দক্ষতা এবং দক্ষতা সহ আপনার নির্দিষ্ট ব্যক্তিদের দলের সম্পাদনের সাথে প্রাসঙ্গিক হতে পারে না।
স্টিভেন এ। লো

0

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

হালনাগাদ

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


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

@ গ্রাহামলি আমার আপডেট দেখুন
Woot4Moo

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

0

বিভিন্ন দৃষ্টান্ত বিভিন্ন সমাধানের দিকে নিয়ে যায়। 'ফিট' কোনটি ফিট তা মূলত উপর নির্ভর করে:

  • সমাধান
  • উন্নয়ন দল
  • অপারেশনাল পরিবেশ

আমি এরকম কোনও সুনির্দিষ্ট অধ্যয়ন জানি না, এবং এমন একটি থাকলেও আমি এটি বিশ্বাস করব না।

এটাই আর্কিটেক্টের কাজ।

কোনও গবেষণার সম্ভাব্য অপ্রাসঙ্গিক উপসংহারের সাথে স্থপতিটির জ্ঞানের প্রতিস্থাপন করা দুর্যোগের একটি রেসিপি।

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

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


1
তাহলে কি কোনও স্থপতি এর পরিধির বাইরে তার পূর্বের কাজ অনুসন্ধান করা উচিত যার উপর তার মতামত তৈরি করা যায়? সম্ভবত না - সুতরাং এই জাতীয় ফলাফল কোথায় এবং কোথায় পাওয়া যাবে তা নিয়ে প্রশ্ন।

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

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

1
একটি সফ্টওয়্যার পদ্ধতির গুণমান এটি স্থানীয় মানুষের প্রয়োজনের সাথে কতটা ভাল মেলে। সাধারণভাবে, এটি পদার্থবিজ্ঞানের আইন দ্বারা বাধা নয় (স্কটি)। 'সফ্টওয়্যার' [শৃঙ্খলা] এর অপরিবর্তনীয় মৌলিক আইনগুলিকে নিষ্ক্রিয় করার আগে এটি অনেক দিন হয়ে যাবে। উদাহরণস্বরূপ, "সফ্টওয়্যার কোয়ালিটি মেট্রিক্স: তিনটি ক্ষতিকারক মেট্রিকস এবং দুটি সহায়ক মেট্রিকস" পিপিআইইন্ট / নিউজলেটার
ফিলিপ দেখুন ওকলে

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