উত্পাদনশীলতা পরিমাপ করার জন্য কি এসএলওসি-র বৈধ ব্যবহার রয়েছে?


55

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

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

যদিও আমি মনে করি না যে এই দাবিটিকে কঠোর পরিসংখ্যান বিশ্লেষণ দ্বারা সমর্থন করা হয়েছে, তবে শিল্পে এমন কোনও প্রমাণ রয়েছে যা এই চিন্তাভাবনার সমর্থন করবে?


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

25
একজন জ্ঞানী ব্যক্তি বলেছেন যে আমাদের কোড লাইনগুলি "নির্মিত" হিসাবে নয় "ব্যয়িত" হিসাবে বিবেচনা করা উচিত; শারীরিক প্রকৌশল যখন আমরা বিওএম এর অংশ গণনা এবং দৈর্ঘ্য বিবেচনা করি তখন আরও ভাল হয় smaller
pjc50

23
বিভিন্ন ভাষার তুলনা (স্থিতিশীল বা গতিশীল যাই হোক না কেন) "একই সংস্কৃতির সাথে একই কোম্পানির মধ্যে, ব্যবসায়ের লাইন" ধারণাটিকে পরাভূত করে: ভাষার পার্থক্যগুলি এসএলওসি তুলনা অর্থহীন করে তোলে।
ছিনিয়ে নিন

4
এই পদ্ধতিটি করুণভাবে ত্রুটিযুক্ত। এমনকি একই বিকাশের পরিবেশ ব্যবহার করে একই সংস্থার দু'জন পৃথক বিকাশকারী একই বৈশিষ্ট্য সেটটি বাস্তবায়নের জন্য প্রায়শই মারাত্মকভাবে আলাদা এসএলওসি উত্পাদন করে।
26

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

উত্তর:


66

প্রবীণ স্থপতি এর যুক্তি দুটি জিনিস বোঝাতে পারে।

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

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

  2. তিনি এও বলতে পারেন যে গতিশীল ভাষা ব্যবহারের চেয়ে স্থির ভাষা ব্যবহার করার সময় সংস্থার একজন গড় বিকাশকারী কোডের কম লাইন তৈরি করে: পনেরো বিকাশকারী জাভাতে ছয় মাসে 100 কেবিএল বা পাইথনে 200 কেপিএল লিখবে।

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

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

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

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


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

10
যে জিনিসটি আমি আরও পছন্দ করি: "কখনই কেবলমাত্র একটি মেট্রিকের উপর নির্ভর করবেন না"
চোকোক্রোক

30
@ স্লেবেটম্যান আমি আপনার টিকিট তৈরির ব্যক্তির যথার্থতা / ধারাবাহিকতা নিয়ে alousর্ষা করি, তবে "2 শব্দের ফিক্স রাইটিং" থেকে "ফিচার এক্স যোগ করুন" পর্যন্ত বিষয়গুলি সমাধান করতে হবে। টিকিটের মেট্রিক আমার কাছে এলওসি-র তুলনায় কম কার্যকর। কমপক্ষে 20 এলওসি দ্বারা ক্লাস কোড হ্রাস করা আমাকে কমপক্ষে কাজটি সম্পর্কে ধারণা দেয়। 5 টি টিকিট সমাধানের কাজ এক ঘন্টা হতে পারে তবে ঠিক এক সপ্তাহ হতে পারে।
আর স্মিটজ

3
@ আর.শ্মিট্জ এটি আমার সংস্থায় একই, তবে প্রতিটি টিকিটের একটি আকারও যুক্ত রয়েছে, তাই টিকিটের আকারের সংমিশ্রণ কাজ করবে।
নিকো বার্নস

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

26

উত্পাদনশীলতা এবং এসএলওসি সম্পর্কে

এসএলওসি নিয়ে সমস্যা

এসএলওসি মেট্রিকের সমস্যাটি হ'ল এটি বিবেচনায় না নিয়ে লিখিত কোডের পরিমাণের একটি অনুমিতি পরিমাপ করে:

  • কোডটির গুণমান (অর্থাত্ প্রতি 100 এসএলওসি-র জন্য কি আপনার বাগের কারণে আরও 90 এসএলওসি যুক্ত করতে হবে তবে আপনার কোডটি সরবরাহ করার মুহুর্তে আপনি জানেন না?)
  • কোড সহ লক্ষ্যগুলি পৌঁছেছে (যেমন 10 কে এসএলওসি সমস্ত প্রত্যাশিত ব্যবহারের কেস বা ব্যবহারকারীর গল্পগুলি পরিচালনা করে? বা কেবল একটি ক্ষুদ্র উপসেট?)
  • কোডটির রক্ষণাবেক্ষণযোগ্যতা (অর্থাৎ প্রত্যাশিত বিবর্তনের প্রয়োজনীয়তার সাথে কোডটি সামঞ্জস্য করার জন্য আপনাকে কি 1% বা 50% আরও কোড যুক্ত করতে হবে?)।

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

সুতরাং এসএলওসি উত্পাদনশীলতা পরিমাপের সর্বোত্তম উপায় নয়।

আমরা কোন উত্পাদনশীলতা বিবেচনা করছি?

উত্পাদনশীলতা একটি প্রক্রিয়া জন্য পরিমাপ করা হয়। সুতরাং এসএলওসি একমাত্র কোডিং প্রক্রিয়াটির জন্য একদম বৈধ সূচক হতে পারে।

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

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

সফ্টওয়্যার বিতরণ পরিমাপ কিভাবে?

বেশ কয়েকটি পদ্ধতি বিদ্যমান:

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

স্ট্যাটিক বনাম গতিশীল টাইপিংয়ের উত্পাদনশীলতা সম্পর্কে

আমাকে স্বীকার করতে হবে যে আমি ব্যক্তিগতভাবে স্ট্যাটিকালি টাইপ করা ভাষার ভক্ত, কারণ আমার অন্তঃকরণে আমি জানি যে এটি আরও নির্ভরযোগ্য (বছরের বহু বছরের কোডিং আমাকে প্রমাণ করেছে)।

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

আপনার স্থপতি ঠিক আছে?

হয়তো, হয়তো না.

তবে তার যুক্তিগুলি বৈধ বলে মনে হয় না: স্ট্যাটিকালি টাইপ করা ভাষার উত্পাদনশীলতা লাভ উল্লেখযোগ্য সংখ্যক ত্রুটি থেকে আসে যা সংকলকটির সামনে ধরা পড়ে।

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

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

এই দাবি সমর্থন করার জন্য কোন গবেষণা?

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


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

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

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

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

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

7

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

আমি যদি এই তিনটি ক্লাস সি ++ তে লিখি তবে তা বেশ সোজা forward আমি ক্লাসগুলি ঘোষণা করি, সঠিক জায়গায় ভার্চুয়াল ব্যবহার করি এবং হয়ে যায় be

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

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

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

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


1
আপনার শেষ বাক্যটি আমার পছন্দ হয়েছে।
পিটার - মনিকা

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

6

আমি কনট্রিশিয়ান হব।

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

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

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

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

এক ব্যতিক্রম

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

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

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


4
আরও একটি ব্যতিক্রম রয়েছে: বাগ শিকার। বিশেষত কদর্য বাগের জন্য বাগ শিকারে অনেক বেশি সময় লাগতে পারে তবে সাধারণত কোড পরিবর্তনের একক লাইন থাকে।
নাথান মেরিল

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

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

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

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

6

যদিও আমি ব্যান্ডওয়্যাগনে ঝাঁপিয়েছি। আমি মনে করি প্রোগ্রামারদের আচরণের উপর প্রভাবটি হাইলাইট করা দরকার।

উত্পাদনশীল হিসাবে একটি পরিমাপ হিসাবে এসএলওসি ব্যবহার করা প্রোগ্রামার মনোবলের উপর একটি বিষাক্ত প্রভাব ফেলে। আপনার দল / সংস্থার কোনও প্রকৌশলী যে মুহূর্তে বুঝতে পারবেন যে তারা এসএলওসি-তে পরিমাপ করা হয় সেগুলি বেশ কয়েকটি ঘটে:

  1. তারা একই কাজ করতে অনেক দীর্ঘ কোড লেখা শুরু করে
  2. তারা তাদের কোডের মান সম্পর্কে কম যত্ন করবে
  3. তারা আপনার দলকে সহায়তা করে এমন অন্যান্য কাজ করা বন্ধ করবে (জুনিয়রদের নিয়োগ, ডিবাগিং, সহায়তা করা)
  4. তারা তাদের কাজের ঘৃণা করবে এবং সম্ভবত চলে যাবে

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


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

1

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

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


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

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

0

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

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

সমস্ত গুরুত্বের সাথে, দল / ভাষার উত্পাদনশীলতার তুলনা অর্থহীন কারণ অনেকগুলি অতিরিক্ত কারণ রয়েছে যা একটি দলের উত্পাদনশীলতাকে প্রভাবিত করে আপনি এ থেকে অর্থপূর্ণ সিদ্ধান্ত নিতে পারেন না।

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

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.