পৌরাণিক পুরুষ মাসে 10 বিকাশকারী প্রতি 10 লাইন - বড় প্রকল্পগুলির কতটা কাছাকাছি? [বন্ধ]

129

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

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

প্রত্যেকেই সর্বদা বলে যে তারা "পৌরাণিক ম্যান মাস" থেকে "প্রতি বিকাশকারী প্রতি 10 টি লাইন" পরাজিত করতে পারে এবং একটি প্রকল্প শুরু করে, আমি সাধারণত দিনে কয়েক'শ লাইন পেতে পারি।

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

অন্য লোকেরা কী করছে? এবং আপনি কী ধরণের প্রয়োজনীয়তার মুখোমুখি হন (আমি এর একটি ফ্যাক্টরটি কল্পনা করি)?

metrics

— ম্যাথিয়াস ওয়ান্ডেল
সূত্র

13

সম্প্রদায় উইকি হওয়া উচিত।

— মালফিস্ট

24

"10" বাইনারি থাকলে এটি চিহ্নের কাছাকাছি থাকত।

— জিওফ্টনজ

2

খুব মজার প্রশ্ন। :)

— এমিল এইচ

9

আমি এই সুন্দর উক্তিটি পেয়েছি "কোডের লাইনে প্রোগ্রামিংয়ের অগ্রগতি পরিমাপ করা ওজন দ্বারা বিমানের বিল্ডিংয়ের অগ্রগতি পরিমাপ করার মতো is" এই ওয়েবসাইটে [লিংক] ( devtopics.com/101- গ্রেট- কম্পিউটার কম্পিউটার

— প্রোগ্রামিং-

2

@ গ্রেগ বেকন, বিল দ্য টিকটিকি: আমি সত্যিই এই প্রশ্নটি আবার খুলতে চাই। এটি ঠিক এসও এর নিয়মগুলির সাথে উপযুক্ত নয়, তবে এটি অবশ্যই দর্শকদের আকর্ষণ করে। (এখনও অবধি 35875 জন দর্শক)

— Skippy Fastol

46

আমি মনে করি সংযুক্ত লাইনের সংখ্যা প্রকল্পের অবস্থার উপর নির্ভরশীল, একটি নতুন প্রকল্পে যুক্ত হওয়ার হার একটি প্রারম্ভিক প্রকল্পের হারের চেয়ে অনেক বেশি হবে।

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

— লিরান ওরেভি
সূত্র

প্রকৃতপক্ষে. প্রথমদিকে ইন প্রকল্পে নেট বিজ্ঞাপনটি অনেক বড় ছিল।

— ম্যাথিয়াস ওয়ান্ডেল

1

সুতরাং, এটি বৃহত্তর প্রকল্পকে অনেকগুলি স্বতন্ত্র অংশে বিভক্ত করার তত্ত্বটি বজায় রাখে (এমনকি স্বতন্ত্র প্রকল্পগুলিও হতে পারে) - ডিউপুলিংয়ের জন্য।

— sergzach

108

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

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

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

— চার্লস বেইলি
সূত্র

49

নেতিবাচক লাইনের অবদানের জন্য +1। আমি একবার একটি ছোট প্রকল্পে কাজ করেছি যেখানে আমি নতুন বৈশিষ্ট্যগুলি যুক্ত করার সময় 15K থেকে 5K পর্যন্ত লাইন সংখ্যা সঙ্কুচিত করেছি (এবং ত্রুটির সংখ্যা বাড়ছে এবং গতি বাড়ছে)।

— rmeador

55

আমি এই উদ্ধৃতি পছন্দ:

আমরা যদি কোডের রেখাগুলি গণনা করতে চাই তবে আমাদের সেগুলিকে "উত্পাদিত লাইন" না হিসাবে "ব্যয় করা লাইনের" হিসাবে বিবেচনা করা উচিত। - এডজার ডিজকস্ট্রা

কিছু সময় আপনি যুক্ত করার চেয়ে কোড সরিয়ে আরও বেশি অবদান রেখেছেন

— rlovtang
সূত্র

30

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

— ওটাভিও ডেসিও
সূত্র

25

আমি এটি উত্পাদনশীলতা মেট্রিক হিসাবে ব্যবহার করছিলাম না। এটি আমার নিজের কৌতূহলের জন্য একটি ব্যক্তিগত অনুশীলন ছিল।

— ম্যাথিয়াস ওয়ান্ডেল

3

যথেষ্ট ফর্সা। তবুও কোডের একটি লাইন হিসাবে বিবেচনা করা উচিত তার আরও সুনির্দিষ্ট সংজ্ঞা ছাড়াই উত্তর দেওয়া শক্ত।

— ওটোভিও ডাসিও

1

@ মাথিয়াস: আমাকে ওপিতে এডিট করা উচিত যদি আমি আপনি থাকতাম তবে আমি একজনের পক্ষে কম হত ... আক্রমণাত্মক: পি

— আনাকাটা

28

অন্য লোকেরা কী করছে?

আমি আমাদের কোম্পানির একমাত্র ফুলটাইম দেব এবং গত 7 বছরে 500,000 লাইন ওক্যামেল এবং এফ # কোড লিখেছি, যা প্রতিদিন প্রায় 200 লাইনের কোডের সমান হয়। যাইহোক, এই কোডটির বিশাল অংশটি হ'ল টিউটোরিয়াল উদাহরণ যা কয়েকশ লাইন দীর্ঘ দীর্ঘ প্রতিটি প্রকল্পের সমন্বয়ে গঠিত। এছাড়াও, ওসিএএমএল এবং এফ # এর মধ্যে প্রচুর নকল রয়েছে। আমরা 50kLOC এর চেয়ে বড় ইন-হাউস কোড বেসগুলি বজায় রাখছি না।

আমাদের নিজস্ব সফ্টওয়্যারটি বিকাশ ও বজায় রাখার পাশাপাশি আমি গত 7 বছরে শিল্পের অনেক ক্লায়েন্টের সাথেও পরামর্শ করেছি। জন্য প্রথম ক্লায়েন্ট , আমি 3 মাসের যা দিন প্রতি কোডের 20 লাইন ধরে OCaml এর 2,000 লাইন লিখেছে। জন্য পরবর্তী ক্লায়েন্ট , আমাদের চার কম্পাইলার লিখেছিলেন 6 মাসের যা প্রতি ডেভেলপার দিন প্রতি কোডের 2,000 লাইন হয় সি / সি ++ / পাইথন / জাভা / OCaml কোড সেইসাথে নথিপত্রের লাইনের উত্পন্ন লক্ষ লক্ষ। অন্য ক্লায়েন্টের জন্য, আমি 6 মাসের মধ্যে এফ # এর 6 কিলোবাইটের সাথে সি ++ এর 50kLOC প্রতিস্থাপন করেছি যা প্রতিদিন -352 লাইনের কোড হয় is জন্য এখনও অন্য ক্লায়েন্ট , আই এফ এ # যা দিন প্রতি কোডের 0 লাইন একই আকারের হতে হবে OCaml এর 15kLOC rewriting করছি।

জন্য আমাদের বর্তমান ক্লায়েন্ট , আমি যা দিন প্রতি কোডের -6.000 লাইন হতে হবে (ক ফরমাশী কম্পাইলার লিখে) সি ++ এবং 1 বছরের মধ্যে এফ # টির ~ 160kLOC সঙ্গে ম্যাথামেটিকাল কোডের 1.600.000 লাইন প্রতিস্থাপন করবে। এটি এখন অবধি আমার সবচেয়ে সফল প্রকল্প এবং আমাদের ক্লায়েন্টকে এক বছরে কয়েক মিলিয়ন ডলার সাশ্রয় করবে। আমি মনে করি প্রত্যেকের প্রতিদিনের 6,000 লাইনের কোড লেখার লক্ষ্য করা উচিত।

— জে ডি
সূত্র

1

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

— এমএম 24

7

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

— জেডি

7

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

— জেডি

7

@ মিম ২৪ চতুর্থত, বিশাল কর্মক্ষমতা উন্নতি ments এফ # হ'ল ম্যাথমেটিকার চেয়ে তীব্রতার অর্ডার এবং এফ # তে তাদের প্রুফ-অফ কনসেপ্ট কোডটি তাদের উত্পাদনের সি ++ কোডের চেয়ে 5x দ্রুত। এর অর্থ হ'ল পরীক্ষাগুলি কয়েক ঘন্টা না হয়ে সেকেন্ডে চালিত হয়, যার পর্যায়ে পরীক্ষা নাটকীয়ভাবে উত্পাদনশীলতার উন্নতি করে বিকাশের একটি অবিচ্ছেদ্য অঙ্গ হয়ে যায়।

— জেডি

7

@ মিমি 24 পঞ্চম, ক্ষমতা বৃদ্ধি করেছে। তারা ডেড কোড বিলোপ করতে এবং তাদের পরীক্ষাগুলির কোড কভারেজ পরিমাপ করতে চায় তবে তারা যে সরঞ্জামগুলিতে চলছে তার সাহায্যে তারা এটি করতে পারে না। .NET এ সরানো এটিকে (এবং আরও বেশি!) সহজ করে তোলে।

— জেডি

13

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

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

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

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

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

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

— ডেভিড থর্নলি
সূত্র

3

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

— ম্যাথিয়াস ওয়ান্ডেল

11

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

— জেফ্রি হাইনস
সূত্র

প্রকৃতপক্ষে. কিন্তু প্রকল্পটি বড় হওয়ার সাথে সাথে আপনি সেই দৃশ্যের প্রায়শই বেশি আঘাত হানবেন। আমি নিখুঁত 10 লাইন প্রোগ্রাম লিখেছি যার কোনও বাগ নেই। এটি সমস্ত স্কেল ব্যাপার।

— ম্যাথিয়াস ওয়ান্ডেল

1

এমন কোনও প্রোগ্রাম নেই যা কোনও বাগ নেই।

— ড্যানিয়েল মৌরা

14

বাঃ! আপনার ব্যাকরণে বাগ রয়েছে ...

— রাল

3

@DanielMoura ওহ, আমি যে ... একটি "ওহে দুনিয়া" প্রোগ্রামের সাথে অসম্মতি খুব দরকারী হতে পারে না অনুভব করি, কিন্তু আপনি সুন্দর অসংশয়ে বলতে চাই যে এটা কোন বাগ :) ছিল না সক্ষম হতে চাই

— WendiKidd

10

কোডের শারীরিক লাইনের কথা বলা বেশ অর্থহীন তা উপলব্ধি করা আরও ভাল হবে। কোডের শারীরিক রেখার সংখ্যা (এলওসি) কোডিং শৈলীর উপর এতটা নির্ভরশীল যে এটি এক বিকাশকারী থেকে অন্য একজনের আকারের ক্রমের পরিবর্তিত হতে পারে।

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

উদাহরণস্বরূপ, এখানে একটি 8 এলওসি পদ্ধতি রয়েছে (শুরু এবং শেষ বন্ধনী ক্রমের পয়েন্টগুলি বিবেচনা করা হয় না):

বিকল্প পাঠ

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

ব্যক্তিগতভাবে, আমি কেবলমাত্র আমার নিজস্ব উত্পাদনশীলতার স্কোরগুলিতে একটি একক এলওসি গণনা করি যখন:

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

এই অবস্থায়, নেট বিকাশকারীদের জন্য এনডিপেন্ডার সরঞ্জামকে কোডিংয়ের জন্য গত 5 বছরে আমার ব্যক্তিগত স্কোর কোনও কোডের গুণমান ছাড়াই ত্যাগ ছাড়াই প্রতিদিন গড়ে 80 টি শারীরিক এলওসি হয় । ছন্দ টিকিয়ে রাখা এবং আমি শীঘ্রই এটি কোনও সময় হ্রাস করতে দেখছি না। সব মিলিয়ে এনডিপেন্ডেন্ট একটি সি # কোড বেস যা বর্তমানে 115 কে শারীরিক এলওসি-র ওজনের

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

— রেভেট প্যাট্রিক
সূত্র

1

আপনার পোস্টটি মৌলিক এবং আরও অনেক বেশি মূল্যবান দাবিদার।

— Skippy Fastol

9

সিলভার বুলেট বলে কিছুই নেই।

এর মতো একটি একক মেট্রিক নিজেই অকেজো।

উদাহরণস্বরূপ, আমার নিজস্ব ক্লাস লাইব্রেরি আছে। বর্তমানে, নিম্নলিখিত পরিসংখ্যানগুলি সত্য:

মোট লাইন: 252.682
কোড লাইন: 127.323
মন্তব্য: 99.538
খালি লাইন: 25.821

আসুন ধরে নেওয়া যাক আমি মোটেও কোনও মন্তব্য লিখি না, তা হচ্ছে কোডের 127.323 লাইন। আপনার অনুপাতের সাথে, সেই কোড লাইব্রেরিটি লিখতে আমাকে প্রায় 10610 দিন সময় নেয়। এটা 29 বছর।

আমি অবশ্যই কোডটি লেখার জন্য 29 বছর ব্যয় করিনি, যেহেতু এটি সমস্ত সি #, এবং সি # এতদিন হয়নি।

এখন, আপনি তর্ক করতে পারেন যে কোডটি এতটা ভাল নয়, যেহেতু অবশ্যই অবশ্যই আমি আপনার 12 লাইনকে এক দিনের মেট্রিককে ছাড়িয়ে যেতে পেরেছি, এবং হ্যাঁ, আমি তাতে সম্মত হব, তবে যদি আমি সময়রেখাকে নীচে নামিয়ে আনতে পারি তবে ১.০ প্রকাশিত হওয়ার পরে (এবং ২.০ প্রকাশিত হওয়ার আগ পর্যন্ত আমি এটি তৈরি করা শুরু করি না), যা ২০০২-০২-১৩, প্রায় 2600 দিন, গড়ে দিনে 48 লাইন কোড থাকে।

কোড লাইন সব লাইন ভাল? হেক নং কিন্তু একদিনে 12 টি লাইনের কোড?

হেক নং

সবকিছু নির্ভর করে।

আপনার পক্ষে একটি শীর্ষ খাঁজ প্রোগ্রামার দিনে কয়েক হাজার লাইনের ক্রমযুক্ত কোড মন্থন করতে পারে এবং একটি মিডিয়াম প্রোগ্রামার দিনে কয়েকশ লাইনের ক্রমযুক্ত কোড মন্থন করে এবং মানটি একই is

এবং হ্যাঁ, বাগ থাকবে।

মোট আপনি চান ব্যালেন্স। কোডের পরিমাণ পরিবর্তন করে, পাওয়া বাগের সংখ্যা বনাম কোডের জটিলতা, বনাম সেই বাগগুলি ঠিক করার অসুবিধা।

— ল্যাসে ভি কার্লসেন
সূত্র

আমেন! (15 টি চার মিনিট পূরণের জন্য স্পেস)

— নট

দ্রষ্টব্য, এই পরিসংখ্যানগুলি ডিপ্যাক ( usysware.com/dpack ) দ্বারা গণনা করা হয়েছিল ।

— লাসে ভি কার্লসেন

5

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

— জে। পোলফার

6

স্টিভ ম্যাককনেল তাঁর "সফটওয়্যার এসটিমেশন" বইতে একটি আকর্ষণীয় পরিসংখ্যান দিয়েছেন (পি 62 সারণী 5.2) তিনি প্রকল্পের ধরণের (অ্যাভিওনিক, ব্যবসায়, টেলকো, ইত্যাদি) এবং প্রকল্পের আকার 10 কেজিএল, 100 কেবিএল, 250 কেবিএল মধ্যে পার্থক্য করেন। নম্বরগুলি এলওসি / স্টাফমন্টে প্রতিটি সংমিশ্রণের জন্য দেওয়া হয়। ইজি এভিওনিক: 200, 50, 40 ইন্ট্রানেট সিস্টেম (অভ্যন্তরীণ): 4000, 800, 600 এমবেডড সিস্টেম: 300, 70, 60

যার অর্থ: উদা। অ্যাভিওনিক 250-কেএলপি প্রকল্পের জন্য 40 (এলওসি / মাস) / 22 (দিন / মাস) == <2LOC / দিন রয়েছে!

— ভ্যালেন্টিন হেইনিজ
সূত্র

1

250 টি টেরার লাইনের কোড? কেএলওসি-তে কী হয়েছে?

— fadebee

4

আমি মনে করি এটি জলপ্রপাত বিকাশের দিনগুলি থেকে এসেছে , যেখানে কোনও প্রকল্পের প্রকৃত বিকাশ পর্ব মোট প্রকল্প সময়ের 20-30% এর চেয়ে কম হতে পারে। কোডের মোট লাইনগুলি নিন এবং পুরো প্রকল্পের সময় দিয়ে ভাগ করুন এবং আপনি প্রায় 10 লাইন / দিন পাবেন get কেবল কোডিং পিরিয়ড দ্বারা ভাগ করুন এবং লোকেরা যা উদ্ধৃত করছে তা আপনি আরও কাছে পাবেন।

— পিভিএস
সূত্র

3

আমাদের কোডবেস প্রায় দেড়শো বছর ধরে চালিত প্রচেষ্টার জন্য প্রায় 2.2MLoC। প্রকল্পের পুরো জীবন জুড়ে এটি প্রতিদিন বিকাশকারীকে প্রায় 75+ লাইন সি ++ বা সি # করে তোলে ।

— স্টিভ কুপার
সূত্র

2

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

— লরেন পেচটেল
সূত্র

1

ছোট প্রকল্পগুলি একাকীকরণে সহায়তা করে। আমি প্রাথমিকভাবে হতবাক হয়ে দেখেছিলাম যে আমরা এই historicalতিহাসিক ব্যক্তিত্বটিকে কমপক্ষে বর্ধিতভাবে আঘাত করি। উক্ত প্রকল্পের শুরুতে, আমার উত্পাদনশীলতা কমপক্ষে 10x বেশি ছিল।

— ম্যাথিয়াস ওয়ান্ডেল

2

ভাল পরিকল্পনা, ভাল ডিজাইন এবং ভাল প্রোগ্রামার। আপনি যে সমস্ত টগিটার পান এবং আপনি একটি লাইন লিখতে 30 মিনিট ব্যয় করবেন না। হ্যাঁ, সমস্ত প্রকল্পের জন্য আপনার থামানো এবং পরিকল্পনা করা, চিন্তাভাবনা করা, আলোচনা করা, পরীক্ষা করা এবং ডিবাগ করা প্রয়োজন তবে প্রতিদিন দুটি সংস্থায় টেট্রিসকে কাজ করার জন্য সেনাবাহিনীর প্রয়োজন হবে ...

নীচের লাইন, আপনি যদি আমার জন্য ঘন্টা 2 লাইনে কাজ করে থাকেন তবে আপনি আমাকে প্রচুর কফ পেতে এবং আমার পায়ে ম্যাসেজ করা ভাল যাতে আপনি বরখাস্ত না হন।

— lcabral
সূত্র

1

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

এটা অকাজের.

— annakata
সূত্র

আপনি তখন কোনও প্রকল্পের আকারটি কীভাবে বর্ণনা করবেন?

— ম্যাথিয়াস ওয়ান্ডেল

1

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

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

2

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

— জন রুডি

2

@ ডেভিড: আমি জানি এটি কোথা থেকে এসেছে, আমি প্রশ্নটি পড়তে পারি এবং এখনই আমার সামনে তাকের সামনে বইটি পেয়েছি got মজার বিষয় হল প্রথম প্রকাশিত তারিখটিও এটি পোস্ট করেছে সি এর মাধ্যমে 3 বছর। আমার বক্তব্য - পরিষ্কারভাবে খারাপভাবে তৈরি করা হয়েছিল - এটি হ'ল এটি প্রত্নতাত্ত্বিক এবং আরও এটির ধারণাটি অকেজো। Hah! এটা সত্যিই বাইবেলের হয়।

— অন্নাকাটা

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

— ম্যাথিয়াস ওয়ান্ডেল