কোনও সি # বিকাশকারী মাসে মাসে কত লাইন কোড তৈরি করতে পারে? [বন্ধ]

Question

আমার কর্মক্ষেত্রে একজন নির্বাহী আমাকে এবং আমার বিকাশকারীদের গ্রুপটিকে প্রশ্ন জিজ্ঞাসা করেছেন:

কোনও সি # বিকাশকারী মাসে মাসে কত লাইন কোড তৈরি করতে পারে?

একটি পুরানো সিস্টেম সি # তে পোর্ট করা উচিত এবং তিনি প্রকল্প পরিকল্পনার অংশ হিসাবে এই ব্যবস্থাটি পছন্দ করবেন।

কিছু (আপাতভাবে বিশ্বাসযোগ্য) উত্স থেকে তাঁর কাছে "10 এসএলওসি / মাস " এর উত্তর ছিল তবে তিনি তাতে সন্তুষ্ট নন।

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

এই প্রশ্নের উত্তর দেওয়া যাবে? (অফহ্যান্ড বা কিছু বিশ্লেষণ সহ)

Comments

এই লাইনে কি কোনও মানের এমবেড থাকা দরকার? > _>

— ডাঃ হ্যানিবাল লেস্টার

এটি কি কম্পিউটার উত্পন্ন কোড হতে পারে? যদি তা হয় তবে আমি সঠিকভাবে নিশ্চিত যে আমি সঠিক হার্ডওয়্যার দিয়ে লাইনে জেটের পাওয়ার উপসর্গ (10 ^ 21) এ যেতে পারি। এটি কিছুই করবে না, মনে মনে

— গ্র্যান্ড

বিশ্বাসযোগ্য উত্স: পৌরাণিক মানুষ মাস।

— মার্টিন ইয়র্ক

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

— মার্ক ফ্রিডম্যান

প্রশ্নের উত্তর দেওয়া উচিত নয় কারণ এটি "আরও বেশি ভাল" বা "আরও কোড মানে আরও গুণমান" এর মতো মিথ্যা অনুমানের উপর ভিত্তি করে।

— টমাসএক্স

Answer 1

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

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

Comments

— হ্যানস কে st ইং

এটি সঠিক উপমা নয়। একজন ইংরেজী পাঠ্যের কত পৃষ্ঠা তিনি এক সপ্তাহে জার্মান ভাষায় অনুবাদ করতে পারবেন তার অনুবাদককে জিজ্ঞাসা করা পুরোপুরি ঠিক। এবং তারা একটি ভাষা / অন্য প্ল্যাটফর্ম থেকে অন্য একটি অ্যাপ্লিকেশন পোর্ট করছেন, অনুবাদ মতো একই জিনিস।

— এসকে-যুক্তি

@ এসকে-লজিক এটা কি? নৈমিত্তিক কথোপকথনের অনুবাদ করার চেষ্টা করুন, তারপরে দীর্ঘ আইনী দস্তাবেজটি অনুবাদ করার চেষ্টা করুন।

— ব্ল্যাকইস

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

— সিজেএমউকে

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

— এসকে-যুক্তি

Answer 2

কোনও সি # বিকাশকারী মাসে মাসে কত লাইন কোড তৈরি করতে পারে?

এগুলি ভাল হলে শূন্যের চেয়ে কম।

Comments

+1: লিগ্যাসি কোড বজায় রাখার সময়, আমরা একটি নেতিবাচক-এলওসি চেক-ইন করার জন্য প্রচেষ্টা করি (কার্যকারিতা বজায় রাখা বা উন্নত করার সময়)। আমার এক সহকর্মী একটি চেক ইনগুলিতে কোডের ২,৫০০+ লাইনের লাইন মুছে ফেলতে সক্ষম হয়েছেন। সেই রিফ্যাক্টরিং তাকে প্রায় এক সপ্তাহ লেগেছিল, তবে সামগ্রিক গড় এখনও প্রতিদিন -300 লাইনের বেশি ছিল। :-)

— পিটার কে।

কোডের হ্রাসিত রেখাগুলি দ্বারা পরিমাপ করা ঠিক ততটাই অর্থহীন it কোডটির লাইন সংখ্যাটি কোডের লাইন সংখ্যা ছাড়া অন্য যে কোনও কিছুর বৈধ পরিমাপ। যে কোনও দিন 10,000 টি লাইনের অপঠনযোগ্য, বাগ-কৃপণযুক্ত স্প্যাগেটির উপরে 40,000 লাইন ভাল কোড দিন।

— ম্যাক্সিমাস মিনিমাস

অবশ্যই এটি অর্থহীন @ এমএইচ। এটি একটি জিভ-ইন-গাল উত্তরটির বেশি

— কোয়ান্টিন-স্টারিন

Answer 3

অন্যভাবে চালান ... এখন।

এলওসি আপনি ব্যবহার করতে পারেন এমন একটি মেট্রিক met

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

কোডটির জটিলতার উপর নির্ভর করে অটোমেশন প্রক্রিয়াগুলির মাধ্যমে পোর্টিং করা যেতে পারে যার ফলস্বরূপ একদিনে হাজার হাজার + এলওসি পরিবর্তিত হতে পারে, যেখানে আরও কঠিন বিভাগ যেখানে ভাষা নির্মাতারা বন্যভাবে আলাদা কোড থাকে সেগুলিকে দিনে 100LoC এ পোর্ট করা হয়।

এসএলওসি তে উইকিপিডিয়া পৃষ্ঠাটি পড়তে তাকে পাঠান । এটি কেন এমন খারাপ মেট্রিকের কয়েকটি সুন্দর ও সাধারণ উদাহরণ দেয়।

Comments

এমএক্সগ্রাথ: এসএলওসি কেবলমাত্র অগ্রগতি পরিমাপের জন্যই খারাপ, তবে সামগ্রিক জটিলতা পরিমাপের জন্য প্রায়শই ব্যবহারযোগ্য, যেহেতু লেস হ্যাটন উল্লেখ করেছেন, "ম্যাককেব সাইক্লোমেটিক কমপ্লেক্সটির কোড লাইনের মতোই পূর্বাভাস ক্ষমতা রয়েছে।"

— পিলমুনচার

Answer 4

সঠিক উত্তর: না ...

এই নির্বাহী শিক্ষিত হওয়া উচিত, যে এসএলওসি বিশ্লেষণ অগ্রগতির জন্য একটি বৈধ মেট্রিক নয়

ঝাপটায় উত্তর: আপনি যে কোনও সংখ্যা তৈরি করতে পারেন।

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

সুন্দর নয়, তবে সক্ষম।

Comments

আমার বলতে হবে যে মন্তব্যগুলি কোডটির কার্যকারিতা বাড়িয়ে তুলতে পারে ।

— নাইট্রোডিস্ট

@ নাইট্রোডিস্ট আসলেই ভাল মন্তব্য, আমি যে মন্তব্যগুলি উল্লেখ করছি তা কেবল নির্বাহীটিকে খুশি করার জন্য ব্যবহৃত হয়। যা পুরোপুরি অকেজো হবে ...

— জেকতা চান

Answer 5

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

Comments

এটি ঠিক কী পরিমাণ কাজ করা হবে তার ইঙ্গিত? আপনার যদি 1000 লাইন কোডের পোর্ট দরকার হয় তবে উপলব্ধ লাইব্রেরি / বিদ্যমান কার্যকারিতা ইত্যাদি যদি ব্যবহার করা হয় তবে এটি 50 লাইন কোডে পোর্ট করা সম্ভব। এবং এটি বিদ্যমান কোডের 100 লাইন পোর্ট করতে 50 লাইনও নিতে পারে। পুরোপুরি কোডের উপর নির্ভরশীল।

— মার্ক ফ্রিডম্যান

আমি বলেছিলাম যে এলওসির একটি উত্স নম্বর হ'ল সঠিক মেট্রিক, আউটপুট নয়।

— এসকে-যুক্তি

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

— মম্মে

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

— এসকে-যুক্তি

Answer 6

আমার কেবল একটি কথা আছে:

"কোডের লাইনে প্রোগ্রামিংয়ের অগ্রগতি পরিমাপ করা ওজন দ্বারা বিমান তৈরির অগ্রগতি পরিমাপ করার মতো” "

-- বিল গেটস

এর পরে, আপনি যুক্তি দিতে পারেন যে বিল গেটস কীভাবে সফল সফ্টওয়্যার তৈরি করতে জানেন না;)

দ্রষ্টব্য: এসএলওসি যদিও কোড-বেস জটিলতার খুব ভাল পরিমাপ!

Answer 7

I 
can
write
large
numbers
of
lines
of
code
per
month.

আসলে শব্দের সংখ্যায় আনুপাতিক।

আপনি আমার বক্তব্য দেখুন?

Comments

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

— gbjbaanb

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

— জন হারপ

Answer 8

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

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

Answer 9

আপনার বসকে একজন নির্বোধ বলা সাধারণত খারাপ ধারণা, সুতরাং আমার পরামর্শগুলি মেট্রিকগুলি প্রত্যাখ্যান করার পরিবর্তে মেট্রিকগুলি বোঝার এবং আলোচনা করে শুরু হয়।

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

একটি উত্স থেকে এই প্রশ্নের সাথে সম্পর্কিত নির্দিষ্ট ডেটা রয়েছে যা আমাদের মধ্যে অনেকে সম্মান করে।

http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html

http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html

http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22

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

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

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

Comments

The take away here is that methodical developers will probably have quick turn around, will write compact code, and have low rework.একমত নন। এটি হয় কম শব্দ বা দ্রুত টার্নআরউন্ড। ঠিক আছে, তৃতীয় বিকল্পটি হ'ল এবং বিকাশকারীদের কেরিয়ার ছেড়ে দিন।

— নিওলিস্ক

Answer 10

তার সাথে কাজ করার জন্য আরও ভাল মেট্রিক দিন

এলওসি এর পরিবর্তে ব্যাখ্যা করুন এটি ব্যবহারের জন্য সবচেয়ে খারাপ মেট্রিক। তারপরে তাকে বিকল্প দিন:

কার্যাবলী নং / বৈশিষ্ট্য প্রতি বৈশিষ্ট্য / ফাংশন অনুরোধ -> NOFF / RFF

আপনাকে এনওএফএফ / আরএফএফের শীর্ষে ওজন / স্বাভাবিককরণ যুক্ত করতে হবে, প্রতি সপ্তাহে অনুরোধের পরিমাণ পূরণ করতে।

:) স্পষ্টত উপরোক্তটি তৈরি করা হয়েছে, তবে এসএলওসি থেকে ভাল কিছু ...

Answer 11

আমি আপনাকে বলতে পারি যে একটি বড় প্রকল্পের জন্য একটি লোড ঠিকাদার এক বছরে 15000 এলওসি (প্রতিটি) লিখেছিল। এটি একটি অবিশ্বাস্যরূপে মোটামুটি উত্তর, তবে আমাদের কাছে 400,000 বিদ্যমান সি ++ এলওসি থাকার কারণে এটি দরকারী and দাও অথবা নাও.

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

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

Answer 12

সঠিক সম্পর্কে শোনাচ্ছে।

/programming/966800/mythical-man-month-10-lines-per-developer-day-how-close-on-large-projects

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

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

Answer 13

আমার অনুমান, সি # এর মতো একটি ভাষা নিয়ে কাজ করা কোনও বিকাশকারীকে প্রায় 10 কে এলওসি / দিন লিখতে / উত্পন্ন করতে সক্ষম হওয়া উচিত। আমি মনে করি, আমি এটি করতে পারতাম। আমি শুধু কখনও না।

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

এক অর্থে কোডিং কবিতার মতো। প্রশ্নটি নয়, কবি কতগুলি লাইন লিখতে পারেন তবে তিনি সনেটের 14 লাইনে কতটা প্রকাশ করতে পারেন con

Comments

10 কে এলওসি? আইএমও যা কেবল কোনও জেনারেটর দ্বারা করা সম্ভব। হাতে লেখা এলওসি যতদূর যায়, আমি তার চেয়ে ওপরের সীমাটি 1K এলওসির সীমার মধ্যে রেখে দেব। এবং এটি একটি ব্যতিক্রমী উত্পাদনশীল দিন হতে হবে।

— ব্যবহারকারী 281377

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

— ব্যাক 2 ডস

@ back2dos: ঠিক আছে, আমি বরং কোডটি নিয়ে ভাবছিলাম যা আসলে বোঝায়।

— ব্যবহারকারী 281377

@ ইম্মকিউ: ভাল, আমি অবশ্যই এর জন্য আপনাকে দোষারোপ করব না nothing আমার

— বক্তব্যটি

Answer 14

আপনার পরিচালককে এটি পরিচালনা করতে দিন, বা চাকরির শিকার শুরু করুন।

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

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

Answer 15

অন্যান্য উত্তরগুলি সঠিক, এটি একটি বোবা প্রশ্ন এবং উত্তরগুলির অর্থ জঘন্য জিনিস নয়। এটি সমস্ত সত্য, তবে আমি জানতে পারি প্রায় এক মাসে আমি কত লাইনের কোড তৈরি করেছি।

এটি XML- ডক ছাড়াই সি # কোডের প্রায় 3000 লাইন। আমি নতুন কার্যকারিতা বাস্তবায়ন করছিলাম এবং এই পরিমাণটি এক মাস বা এক মাস এবং এক সপ্তাহের মধ্যে শেষ হয়েছিল। সোর্স কন্ট্রোল এ শেষ হয়েছে, প্রচুর কোড লেখা হয়েছিল এবং তারপরে রিফ্যাক্টর বা মুছে ফেলা হয়েছিল।

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

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

Answer 16

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

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

আরও বুদ্ধিমান পন্থাটি হ'ল: -

1. অন-স্পট আনুমানিকতার জন্য ডেভেলপারদের কোডটির সাথে সর্বাধিক অভিজ্ঞতার সাথে জিজ্ঞাসা করুন যে এটি কতক্ষণ সময় নেবে a আমি এখানে won'tুকব না এমন অনেক কারণে এটি ভুল হতে বাধ্য but তবে এটি শুরুতে তারা সক্ষম হবেন এটিই সেরা। কমপক্ষে তাদের একটি ধারণা থাকা উচিত যে এটি অতিরিক্ত সংস্থান দিয়ে এমনকি এক সপ্তাহে বা কয়েক বছর দূরে করা সহজ-পাসি হবে কিনা। যদি কোনও অনুরূপ আকারের বন্দর বা কাজের টুকরা হয়ে থাকে তবে তারা এটিকে গাইড হিসাবে ব্যবহার করতে পারে।
2. মোট আকার নির্ধারণের জন্য উপাদানটির মাধ্যমে বন্দরটি অনুমান করুন। বন্দরের সাথে সরাসরি সম্পর্কিত নয় এমন কাজগুলিকে অন্তর্ভুক্ত করা দরকার, যেমন অবকাঠামো স্থাপন (মেশিন, বিল্ড সিস্টেম, ইত্যাদি), তদন্ত এবং সফ্টওয়্যার কেনা ইত্যাদি be
3. বন্দরের ঝুঁকিপূর্ণ উপাদানগুলি সনাক্ত করুন এবং সেগুলি দিয়ে প্রথমে শুরু করুন। এগুলি সম্ভবত সবচেয়ে বেশি অনুমানটি ছড়িয়ে দিতে পারে, তাই সম্ভব হলে আপ-ফ্রন্ট করা উচিত যাতে বন্দরে দেরিতে সীমিত চমক থাকে।
4. বন্দরটির প্রত্যাশিত সময়কাল ক্রমাগত গণনা করতে পদক্ষেপ 2-এ করা আকারের বিরুদ্ধে অগ্রগতি সম্পর্কে নজর রাখুন। প্রকল্পটি এগিয়ে যাওয়ার সাথে সাথে এটি আরও সঠিক হওয়া উচিত। অবশ্যই, পোর্ট করা হয়েছে এমন কোডের লাইনগুলির সংখ্যা (মূল কোড বেসের বৈশিষ্ট্যগুলি যা এখন পোর্ট করা কোডে রয়েছে) এছাড়াও একটি মেট্রিক হিসাবে ব্যবহার করা যেতে পারে এবং এটির পরিবর্তে মূল পণ্যটি পোর্ট করা হচ্ছে কিনা তা নিশ্চিত করতে সহায়ক আসল বন্দর মোকাবেলা না করার সময় একগুচ্ছ শীতল নতুন কার্যকারিতা যুক্ত করা হচ্ছে।

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