সফ্টওয়্যার বিকাশে রুটিন কাজের পরিমাণ এবং অনুমানের উপর এর প্রভাব


11

আমি নিশ্চিত যে সফটওয়্যার বিকাশে রুটিন কাজের পরিমাণ হ'ল - এবং হওয়া উচিত - তুলনামূলক কম না হলে, এবং এটিই সফ্টওয়্যার অনুমানের মূল সমস্যা।

আমি কীভাবে এই উপসংহারে পৌঁছেছি তা বর্ণনা করুন এবং যুক্তিটির কোনও গুরুতর ত্রুটি আছে কিনা তা আমাকে বলুন:

  1. উচ্চ নির্ভুলতার সাথে যা অনুমান করা যায় সেগুলি হ'ল রুটিন কাজ, যার অর্থ আগে করা কাজ। গবেষণা এবং সৃজনশীলতার সাথে জড়িত অন্যান্য সমস্ত কাজের সত্যই অনুমান করা যায় না, কমপক্ষে নির্ভুলতার সাথে নয়, আসুন বলা যাক, +/- 20 শতাংশ।

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

এই দুটি বিষয় থেকে আমি উপরের উপসংহারটি আঁকছি।

আসলে আমি বেশ কিছুদিন ধরেই ভাবছিলাম যে সফটওয়্যার অনুমান সম্পর্কে প্রতিটি অন্যান্য আলোচনায়, ব্লগ পোস্টে বা নিবন্ধে এই সম্পর্কের উল্লেখ নেই কেন? এটা কি তাত্ত্বিক? আমার অনুমানগুলি কি ভুল? বা এটি খুব তুচ্ছ - তবে তবে কেন আমি জানি বেশিরভাগ বিকাশকারীরা বিশ্বাস করেন যে তারা +/- 20 শতাংশ বা তার চেয়েও বেশি নির্ভুলতার সাথে অনুমান করতে পারে?


7
কার্নেলের মতো অঞ্চলের বাইরের সমস্ত সফ্টওয়্যার বিকাশের 99% এর আগে হাজার হাজার বার করা হয়েছে। অনেক বেশি বিকাশকারী একই সাথে পুরানো সমস্যাগুলি বার বার পুনরায় উদ্ভাবন করে নতুন অভিনব উপায়ে সবকিছু করতে চান।
বেন্ট করুন

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

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

1
@ জনআর.স্ট্রোহম: আমি এই নির্দিষ্ট বইগুলি পড়ি নি তবে কোকোমোর মূল বিষয়গুলির সাথে পরিচিত - তবে বাস্তবে কখনও এটি ব্যবহার করা হয়নি। এছাড়াও আমি ডিমার্কোর দুটি বা তিনটি বই পড়েছি। আমার প্রশ্নের সাথে সম্পর্কিত কোন নির্দিষ্ট বিষয়বস্তু সম্পর্কে আপনি একটি ইঙ্গিত দিতে পারেন?
ফ্রাঙ্ক পাফার

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

উত্তর:


11

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

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

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

একইভাবে, আমার অভিজ্ঞতা হিসাবে, বেশিরভাগ প্রোগ্রামিং হ'ল ব্যবসায়িক প্রক্রিয়াগুলির অটোমেশন এবং যদিও প্রতিটি ব্যবসায় তাদের প্রসেসগুলি তাদের কাছে স্বতন্ত্র বলে মনে করতে পছন্দ করে; বাস্তবে তারা না।

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

প্রয়োজনীয়তাগুলি তিনটি বিভাগে পড়ে:

  1. লীগ, বিশদ বিকাশকারীর কাছে রেখে গেছে।

"আমাকে একটি ওয়েবসাইট করুন, এটি শীতল হতে হবে এবং আমার উইজেটগুলি বিক্রয় করতে হবে"

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

  1. খুব নির্দিষ্ট

"শিরোনামের পটভূমির রঙ করুন # ff1100"

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

  1. লীগ, বিশদ অনুমান করা হয়েছে

"আমাকে একটি ওয়েবসাইট করুন, (ঠিক ফেসবুকের মতো)"

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

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


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

স্পষ্টত এটি এর মত নয় যে আমি কখনই তৃতীয় পক্ষের জিনিস ব্যবহার করি না।
Ewan

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

কোনও 'whos the best programmer' শিখা যুদ্ধে না getুকতে দেয়। সমস্ত ইম কথাই হ'ল কম নতুন জিনিসগুলির আগে আপনি যত বেশি কাজ করেছেন। যদি আপনার সমস্ত প্রকল্পগুলি বেশিরভাগ বৈশিষ্ট্যগুলির জন্য নতুন প্রযুক্তি ব্যবহারের আদেশ দেয় তবে ... এটি অদ্ভুত বলে মনে হচ্ছে
ইওয়ান

@ ইয়ান "ধারণা বা প্রযুক্তি"। আমার জন্য প্রথমটি ব্যবসায়িক বিধি এবং / অথবা ডিজাইনার যা চায় তার সাথে সম্পর্কিত হয়। এটি কেবল নতুন প্রযুক্তি সম্পর্কে নয়।
ইজকাটা

6

কেন আমি জানি বেশিরভাগ বিকাশকারীরা বিশ্বাস করেন যে তারা +/- 20 শতাংশ বা তার চেয়েও ভাল এর নির্ভুলতার সাথে অনুমান করতে পারে?

কারণ আমরা আমাদের ধৈর্যটি আসল সমস্যার তুলনায় সমস্যার চেয়ে অনেক বেশি অনুমান করি।

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

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

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


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

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