কোন প্রকল্প বড় করে তোলে? [বন্ধ]

Question

কৌতূহলের বাইরে একটি ছোট, মাঝারি এবং বড় আকারের প্রকল্পের মধ্যে পার্থক্য কী? এটি কোড বা জটিলতার লাইন দ্বারা পরিমাপ করা হয় বা কী?

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

Comments

হ্যাঁ ............ আরও জটিলতার অর্থ কোডের আরও লাইন।

— রবার্ট হার্ভে

প্রথম কেএলকি হ'ল সবচেয়ে শক্ত ...

এরপরে আপনাকে জিজ্ঞাসা করতে হবে "কী একটি প্রকল্পকে জটিল করে তোলে? কোডের রেখাগুলি? বিমূর্ততার স্তরগুলি?"

— স্টিভেন ইভার্স

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

— টিএমারশাল

আমি বলব যে কোনও প্রকল্পের "ব্রাইনেস" 1 টির বেশি ফ্যাক্টরের উপর নির্ভর করে ...

— কিউইক্সজ

Answer 1

জটিলতা.

আরও জটিলতা, প্রকল্পের সমস্ত কিছু শেখার পক্ষে আরও কঠিন।

Comments

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

— হেনরিক

... বা স্বাভাবিকভাবেই জটিলতার অন্য কোনও পরিমাপ।

— হেনরিক

@ হেনরিক, "জটিল সিস্টেম" "বৃহত সিস্টেম" এর সমতুল্য নয়।

না, এটি একটি প্রতিশব্দ।

— হেনরিক

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

Answer 2

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

• 2 মি + স্লোক একটি বিশাল থেকে বিশাল প্রকল্প। এগুলি সাধারণত এত জটিল যে কোনও লোক যদি পুরো সিস্টেমে 'সাবলীল' হয়; বরং দায়িত্ব কোডের কাঠামো বরাবর মডুলারাইজড হতে থাকে। এই প্রকল্পগুলি প্রায়শই প্রচুর ব্যবসায়িক মূল্য সরবরাহ করে এবং মিশন সমালোচনামূলক হতে পারে। তারা কখনও কখনও প্রযুক্তিগত debtণ এবং অন্যান্য উত্তরাধিকার সংক্রান্ত উদ্বেগগুলির মধ্যে একটি ভারী চাপের মধ্যে থাকে।

• 100 কে - 2 মি স্লোক একটি মাঝারি আকারের প্রকল্প। এটি আমার মাঝের ক্ষেত্র: কিছু বিশেষজ্ঞ জ্ঞানের প্রয়োজনে এই প্রকল্পটি যথেষ্ট জটিল এবং সম্ভবত কিছুটা প্রযুক্তিগত debtণ অর্জন করেছে; এটি সম্ভবত ব্যবসায়িক মানের কিছু ডিগ্রী সরবরাহ করে।

• 10 কে - 100 কে একটি ছোট প্রকল্প, তবে পর্যাপ্ত জটিলতা থাকা খুব কম নয় যা আপনি বিশেষজ্ঞের বিবেচনা করতে চাইবেন; আপনি যদি ওপেন সোর্স হন তবে আপনার বিশ্বাসের লোকদের আপনার কমিটগুলি পর্যালোচনা করার জন্য বিবেচনা করুন।

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

Comments

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

— এরিক অ্যান্ডারসন

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

— zxq9

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

— ইওঙ্গওয়ে উ

Answer 3

একটি প্রকল্পের আকার অপরিবর্তনীয়তার ডিগ্রি দ্বারা পরিমাপ করা হয়।

Comments

এটি হতাশাব্যঞ্জক: ডি

— হেনরিক

.... আর সেই পরিমাপ কি?

— কেসি প্যাটন

@ ক্যাসি প্যাটন পরিমাপটি আক্ষরিক রক্ষণাবেক্ষণের ব্যয়।

— মোজুবা

Answer 4

জটিলতা যা কয়েকটি উপায়ে অনুমান করা যেতে পারে:

1. বাজেট। 10,000,000 ডলার + বাজেটের একটি প্রকল্প সম্ভবত উদাহরণস্বরূপ 10,000 ডলারের নীচে থেকে একদম পৃথক। এর মধ্যে শ্রম, সফ্টওয়্যার, হার্ডওয়্যার এবং কোনও প্রকল্পে ব্যয় করা অন্যান্য ব্যয় অন্তর্ভুক্ত থাকতে পারে।
2. প্রকল্পটি শেষ করতে লোকের কাজ ঘন্টা। এটি কি এক মিলিয়ন ঘন্টা বা অন্য কিছু লাগবে? এটি একটি টাইমলাইন ফ্যাক্টর হিসাবে দেখা যেতে পারে যেখানে কিছু প্রকল্পের কয়েক বছর সময় লাগতে পারে যা আমি বলতাম অন্যদের তুলনায় এক সপ্তাহেরও কম সময় নিতে পারে were নোট করুন যে ব্যক্তির ঘন্টাগুলি বিভ্রান্তিমূলক হতে পারে কারণ কোনও ব্যক্তি কর্মীদের দ্বিগুণ করে ভাবতে পারে তাই প্রকল্পে দ্বিগুণ কাজ করার পরে তফসিলটি অর্ধেক করে কেটে নেওয়া যেতে পারে যা খুব কমই আমার মনে কাজ করবে।
3. প্রকল্পটি কী নির্মাণ করছে তা ব্যবহার করে হার্ডওয়্যার, অন্যান্য সিস্টেম এবং লোকের পরিমাণ। যদি কিছু 101 টি সিস্টেমে বাঁধা থাকে তবে এটি আরও জটিল হতে পারে যে যদি এটি একা দাঁড়িয়ে থাকে এবং অন্য কোনও কিছুতে বাঁধা না থাকে।

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

Answer 5

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

অবশ্যই, আরও প্রয়োজনীয়তার বেশিরভাগ ক্ষেত্রে আরও জটিলতা বোঝানো হয়, তবে এটি সবসময় হয় না।

Comments

এটি একটি ভাল পরিমাপ নাও হতে পারে: অন্য ধরণের পণ্যের তুলনায় সংকলক এবং ওএস কার্নেলের প্রয়োজনীয়তা তুলনামূলকভাবে বড় হতে পারে।

— মোজুবা

@ মোজুবা: "বিগ" বেশ বিস্তৃত শব্দ, আমি কল্পনা করেছিলাম যে একটি সংকলক বা একটি ওএস লেখা একটি "বড়" প্রকল্প হবে

— ডেভিড_001

@ ডেভিড_001: টার্বো পাস্কল সংকলক নিন, f.ex., যার একবিন্দুতে বাইনারি আকার 70 কিলোবাইট এবং তবুও টিপি একটি পূর্ণ-বর্ধিত অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং ভাষা ছিল। আমরা উত্সটি কখনও দেখিনি তবে একটি 70 কেবি এক্সিকিউটেবল কোনও বড় প্রকল্প হতে পারে না।

— মোজুবা

@ ডেভিড_001: সাধারণত আমি আপনার সাথে সম্পূর্ণরূপে একমত নই। "বড়" প্রকল্পের যে কোনও সংজ্ঞা নিজেই "বড়" শব্দের মতোই অস্পষ্ট হবে।

— মোজুবা

@ মোজুবা: আমি যখন টার্বো পাস্কাল ব্যবহার করতাম, তখন এটি মোটেই বস্তু-ভিত্তিক ছিল না।

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

Answer 6

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

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

Answer 7

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

Answer 8

জটিলতা এবং সুযোগ

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

আবশ্যকতা

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

সিসিএমইউর অভাব

সিসিএমইউ হ'ল আমি যাকে " Coo Ca Moo " বলি (সম্পূর্ণ পরিপূর্ণ পারস্পরিক বোঝাপড়া)। আপনার গ্রাহকের সাথে আপনার সিসিএমইউ হওয়া দরকার।

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

স্কোপ ক্রাইপ

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

Answer 9

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

Answer 10

জটিলতা সঠিক উত্তর, তবে এটি কীভাবে অনুমান করা যায়?

উপাদানগুলি হ'ল:

1. এক্সটেনশন পয়েন্ট গণনা
2. মডিউল স্তর স্তর গণনা (ফাংশন, শ্রেণি, শ্রেণি সিস্টেম, গ্রন্থাগার, শেয়ার্ড লাইব্রেরি, অ্যাপ্লিকেশন, নেটওয়ার্ক অ্যাপ্লিকেশন, ইত্যাদি)
3. নির্ভরতা গণনা (প্ল্যাটফর্ম অন্তর্ভুক্ত)
4. পারস্পরিক নির্ভরতা গণনা বৈশিষ্ট্যগুলি।
5. প্রয়োজনীয় নন-কোড সংস্থান (গ্রাফিক্স / আর্টস, ড্রাইভিং স্ক্রিপ্টগুলি - লেভেল ডিজাইনের স্ক্রিপ্টগুলির মতো - এবং অ্যাপ্লিকেশনটির কোনও সংস্করণ সম্পূর্ণ করার জন্য প্রয়োজনীয় অন্যান্য সংস্থানগুলি)

এগুলির মধ্যে আপনার যত বেশি, প্রকল্পটি তত বেশি জটিল।

Answer 11

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

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

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