আমার ক্লায়েন্টটি আমার বর্তমান প্রকল্পে 25% মন্তব্য চায়, কীভাবে প্রতিক্রিয়া জানাবে? [বন্ধ]


96

জুনিয়র বিকাশকারী এখানে।

আমি বর্তমানে আমার সংস্থার বড় ক্লায়েন্টের জন্য ওয়েব অ্যাপ্লিকেশনটিতে একা কাজ করছি। আমি গত মাসে শুরু। ক্লায়েন্ট তার প্রতিটি সফ্টওয়্যার প্রকল্পে কমপক্ষে 25% মন্তব্য চায়।

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

  • প্রতিটি ফাইল একটি মন্তব্য ব্লক দিয়ে শুরু হয় (প্যাকেজ, শেষ আপডেটের তারিখ, আমার সংস্থার নাম এবং কপিরাইট)
  • সমস্ত ভেরিয়েবল তাদের নামের সাথে মন্তব্য করা হয় // nameOfCustomer public String nameOfCustomer

  • সমস্ত getters এবং setters মন্তব্য করা হয়

  • খুব কম দরকারী মন্তব্য

এটি দেখে মনে হয় বিকাশকারীরা কেবলমাত্র 25% প্রান্তিক হিট করতে যতটা মন্তব্য করতে পারেন, মানের এবং উপযোগিতা বিবেচনা না করেই রাখুন। আমার সংস্থা আমাকে জানিয়েছে যে "ক্লায়েন্ট এটি যেমন চায় তেমন করে"।

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

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

এই বিষয়ে আপনার পরামর্শ কি? আমি পরিস্থিতিটি কীভাবে পরিচালনা করব?


162
যে হাস্যকর. তবে, যদি ক্লায়েন্ট এটিই চায় এবং ক্লায়েন্ট এটি পাওয়ার জন্য আপনাকে ভাল অর্থ প্রদান করছে, তবে আপনি তাকে যা দিচ্ছেন তা।
রবার্ট হার্ভে

20
25% লাইন (মানে আপনি কখনও কোডের মতো একই লাইনে কোনও মন্তব্য করেননি) বা 25% বাইট ?
রনজাহান


10
এখানে ভাল থাকুন। সাধারণত এই ধরণের প্রত্যাশার পিছনে একটি কারণ থাকে ... আপনি যদি আপনার গ্রাহককে সেই মন্তব্যগুলি অকেজো বলে থাকেন তবে সে এখনও 25% মন্তব্য করতে পারে (তাদের যে কোনও কারণেই হোক) তবে এখন আপনার নামগুলি অকেজো হিসাবে রাখুন .. ... আপনি নিজেকে আরও সমস্যায় ফেলতে পারেন .... কখনও কখনও গ্রাহকের
তর্কগুলি

19
এটি একটি নিয়মের একটি অবজেক্ট পাঠ যা আপনার ক্যারিয়ারে আপনি পর্যবেক্ষণ করার যথেষ্ট সুযোগ পাবেন: আপনি যে জিনিসটি মাপেন তা হ'ল আপনি যা পান সেটিই । আপনাকে মন্তব্যের জন্য একটি মেট্রিক দেওয়া হয়েছে, এবং সুতরাং মন্তব্যগুলি হ'ল আপনি যা পাবেন। আরও বুদ্ধিমান গ্রাহক আপনাকে কর্মক্ষমতা, নির্ভুলতা, দৃust়তা এবং ব্যয়ের জন্য মেট্রিক দেবেন এবং তারপরে আপনি এই জিনিসগুলি পেয়ে যাবেন। তবে আপনার কাছে বুদ্ধিমান ক্লায়েন্ট নেই।
এরিক লিপার্ট

উত্তর:


115

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

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

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

ঠিক আছে, তাহলে ডায়ালগটি কোথায় যায় যদি এটি পয়েন্ট হয়? কথোপকথনের পরবর্তী অংশটি এরকম হয়:

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

এখানে আমি মনে করি ডায়লগটি যাওয়া উচিত নয় :

  1. নিম্ন মানের মন্তব্যে ক্লায়েন্টকে হুমকি দেবেন না। তারা ব্যয় করতে চায় এবং যে পরিমাণ অর্থ ব্যয় করতে আগ্রহী তা চয়ন করতে তাদের আপনাকে সহায়তা দিন। তাদের 25% মন্তব্যের প্রতিশ্রুতি দেবেন না এবং তারপরে তাদের অবহিত করুন যে প্রকল্পটি তৈরি হওয়ার পরে এলোমেলোভাবে স্বয়ংক্রিয়তা তৈরি করে আপনি এই প্রতিশ্রুতিটি সরবরাহ করতে চান।
  2. আপনার পরিকল্পনা গোপন করবেন না। তাদের 25% মন্তব্যের প্রতিশ্রুতি দেবেন না এবং তারপরে আপনি যা করতে যাচ্ছেন তা না জানিয়ে এলোমেলোভাবে অটোজেনারেট করুন। যখন তারা লক্ষ্য করে (না হয়) তবে আপনি উভয়ই বড় সময় হারাবেন: তারা যে পণ্যটি পেয়েছিল তাতে তারা অসন্তুষ্ট হয় এবং আপনি মুখের বিরূপ হন।
  3. তারা বোঝাতে চেষ্টা করবেন না তারা মন্তব্য চান না। তারা স্পষ্টভাবে মন্তব্য চায়। বিভিন্ন পদ্ধতির ট্রেড অফ নিয়ে আলোচনা করুন: হ্যাঁ! কোডবাসকে নবাগত বান্ধব বানানোর বিকল্প উপায়গুলি নিয়ে আলোচনা করুন: হ্যাঁ! তাদের বলুন তারা জানেন না তারা কী চায়: হ্যাঁ, না। তারা যা চায় তা পেতে আপনি তাদের সাথে কাজ করতে চান; সুতরাং এটি কী তা বুঝতে এবং তাদের কাছে যে পরিমাণ সংস্থান রয়েছে তা অপ্রতুল হলে তারা যে বৈশিষ্ট্যগুলির সর্বাধিক যত্ন নেয় তাদের অগ্রাধিকার দিয়ে বাজেটে তারা এটিকে কীভাবে সরবরাহ করতে পারে তা সবচেয়ে ভাল to
  4. কীভাবে কঠোর মন্তব্য লিখতে হয় তা সম্পর্কে অজুহাত তৈরি করবেন না। রাইটিং কোড কঠিন; ডিবাগিং কোড শক্ত; মন্তব্য লেখা শক্ত। যদি এটি সহজ হয় তবে তারা আপনাকে নিয়োগ দিবে না। কেবল অভিযোগগুলি এড়িয়ে যান এবং তারা যে বিষয়টির জন্য যত্ন নেন সেগুলিতে সরাসরি যান, যেমন অতিরিক্ত অতিরিক্ত প্রচেষ্টা তাদের কীভাবে প্রভাবিত করে।

3
প্রশ্নের উত্তম ইতিবাচক গ্রহণ :-)
মাস্টার

9
@ThorstenS। আমি যে সংস্থার জন্য কাজ করি সে প্রতিরক্ষা শিল্পের জন্য তার কাজের একটি সুপারমোজারিটি করে। আপনার মানসিক শক্তি চেক করতে পারে। এছাড়াও, আমি কখনই বলিনি "তারা কীভাবে এটি লিখেছেন তাদের শুভেচ্ছার ব্যাখ্যা করবেন না": আমি "25% মন্তব্য" কে একটি গুরুতর তবে ঘটনামূলক অনুরোধ হিসাবে বিবেচনা করব - আসল অনুরোধটি "প্রযুক্তিগত লেখার একটি বৃহত অঙ্গ", এবং 25% হ'ল তারা চেষ্টা করবেন যে স্তরের প্রবেশের প্রত্যাশা রয়েছে তার সম্পর্কে কেবল একটি ইঙ্গিত, সম্ভবত নির্বিচারে বেছে নেওয়া হয়েছে, তবে তবুও এমন একটি লক্ষ্য যা আপনাকে মিস করা উচিত নয়।
ড্যানিয়েল ওয়াগনার

12
আমি যদি একজন প্রোগ্রামার নিয়োগ করি, মিঃ ড্যানিয়েল ওয়াগনার হ'ল আমি যে ধরণের লোক ভাড়া নিতে চাই।
জো গেইটি

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

6
এটি পরিষ্কার করে দেওয়াও ভাল হবে যে এই মন্তব্যগুলি রক্ষণাবেক্ষণের ব্যয় বাড়িয়ে তুলবে । একবার তৈরি হয়ে গেলে এগুলি অবশ্যই ক্রমাগত আপডেট হওয়া উচিত , অথবা এগুলি সময় এবং অর্থের অপচয়। আপনি এটা প্রাপ্য); (+1 করতে আগামীকাল পর্যন্ত অপেক্ষা করা হচ্ছে যাতে আপনি আসলে প্রতিনিধির পেতে।)।
jpmc26

83

গ্রাহক রাজা। সুতরাং ঠিকাদার হিসাবে আপনি ক্লায়েন্টকে মানের মান হিসাবে সংজ্ঞায়িত করেছেন যা আপনি পূরণ করতে পারেন। অথবা আপনি বাইরে থাকার ঝুঁকি নিয়েছেন।

এটি বলা হচ্ছে, (এখানে নিম্নমানের) মানের মানগুলি কীভাবে সংজ্ঞায়িত করা হয় তা খুব গুরুত্বপূর্ণ:

  • চুক্তিগত মানের মান: বিতরিত কোড অবশ্যই মেনে চলতে হবে, অথবা অন্যথায় এটি চুক্তি লঙ্ঘন করেছে। কোন পছন্দ নাই.

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

  • অ্যাড-হক মানদণ্ড ক্লায়েন্টের কয়েকজন ব্যক্তির দ্বারা সংজ্ঞায়িত। এখানে আপনি আলোচনা করতে পারে। আশা আছে :-)

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

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

তবে খারাপের বিরুদ্ধে কথা বলা এবং গ্রাহকের মুখোমুখি হওয়ার পরিবর্তে আপনি আরও ভাল পদ্ধতির প্রচার করতে পারেন:

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

যদি গ্রাহক এখনও নিশ্চিত না হন তবে আপনি একটি পরীক্ষামূলক বিকল্প প্রস্তাব করতে পারেন, সরঞ্জামগুলি ব্যবহার করে মন্তব্যগুলির সাথে স্বয়ংক্রিয়ভাবে ডকুমেন্টেশন তৈরি করতে পারে যেমন javadocবা doxygen। এর সাথে পরিমাণ (কোডের 25%) থেকে মানের দিকে (একটি বোধগম্য জাভাডোক উত্পন্ন) ফোকাসটি স্থানান্তর করার প্রস্তাব করুন there


7
গ্রাহক যদি রাজা হন তবে এটি কেবল দেখায় যে এই জাতীয় গ্রাহকরা কতটা অদক্ষ!
স্টিভ

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

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

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

11
@ হামাত্তি আমি একবার একটি লাইনের পিছনে আসল উদ্দেশ্যটি বোঝার জন্য যথেষ্ট পরিমাণ সময় ব্যয় করেছিi++; // count down
TKK

18

ক্লায়েন্ট তার প্রতিটি সফ্টওয়্যার প্রকল্পে কমপক্ষে 25% মন্তব্য চায়।

ক্লায়েন্টটি কি সত্যিই 25% মন্তব্য চায় বা আপনার ক্লায়েন্ট কি আপনার কোডটি যথাসম্ভব বর্ণনামূলক হতে চান?

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

আমি অনুমান করি যে আপনার ক্লায়েন্টের কিছু ছদ্ম-জ্ঞান রয়েছে এবং কোডটি ভালভাবে নথিভুক্ত করা এবং সহজ এবং সস্তা রক্ষণাবেক্ষণের জন্য চায় এবং এর সরঞ্জামটি হল মন্তব্যগুলি (তাঁর মনে)।

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

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

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


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

2
@ গ্রাহাম হ্যাঁ, মন্তব্যগুলি সম্পূর্ণ অপরিহার্য নয়। তবে, মন্তব্যগুলি কোডের মতো: আপনি যত বেশি করেন তত বেশি রক্ষণাবেক্ষণের প্রয়োজন। সংক্ষিপ্ত থাকা আমার বিশ্বাসকে সহায়তা করে।
রবার্ট ডন্ডন

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

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

12

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

যখন এটি ঘটে তখন তর্ক করা যায় যে দুটি গ্রুপের লোক দোষে:

  1. যে সীমাটি সীমাবদ্ধ রেখেছিল তারা - স্পষ্টতই এটি অত্যধিক এবং কৃত্রিম গোলমাল না করে লোকদের সঠিকভাবে গঠিত তথ্য জমা দিতে বাধা দেয়

  2. যে সমস্ত লোক সঠিকভাবে গঠন করা হয়নি এমন তথ্য জমা দিয়েছিল , তখন সিস্টেমটি তাদের পরিবর্তে আরও প্রকৃত পদার্থ যুক্ত করার অনুরোধ জানালে কৃত্রিম গোলমাল যুক্ত করেছিল

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

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

"তবে কীভাবে আমরা 25% পেতে পারি?" পদার্থের প্রকৃত মন্তব্য লিখে। ফাংশনগুলির প্রভাব ডকুমেন্ট করতে আরও শব্দ, আরও ভাল শব্দ, সেরা শব্দ ব্যবহার করুন। আপনার ব্যাখ্যা ব্যাখ্যা। প্রান্তের কেসগুলি আরও বিশদে বর্ণনা করুন।

তবে, মূল বিন্দুতে ফিরে যাওয়া, ক্লায়েন্টটি এখানেও আংশিক দোষে রয়েছে, কারণ "উত্স কোডের 25%" অত্যন্ত স্বেচ্ছাসেবী। শেষ পর্যন্ত, যদিও তারা ক্লায়েন্ট, সুতরাং এটির সেরাটি তৈরি করুন। তবে আমার অর্থ "সেরা"। "খারাপ" নয়, যেমনটি এখন পর্যন্ত ঘটছে।


5

আমি জানি না যে এই প্রয়োজনীয়তা নিয়ে বড় ধরনের ঝামেলা কি।

কেবলমাত্র আপনার কোডের প্রাথমিক অক্সিজেনাইজেশন দ্বারা আপনি সম্ভবত ইতিমধ্যে 10% বা তার বেশি। এবং আসুন আপনি নিজের জন্য লিখেছেন আরও 5% মন্তব্যগুলি গ্রহণ করুন (কিছু আরও লেখেন, তবে 5% মনে করেন যে আপনি যদি নীরবতার প্রতিশ্রুতি না নেন তবে রক্ষণশীল অনুমানের মতো)। এই মুহুর্তে এটি প্রায় 15% (হ্যাঁ হ্যাঁ, আমি জানি, 90% এর 5% 5% এর চেয়ে কম, নিটপিক করবেন না)। যদি আপনার ডক্সিজেন 10% এরও কম হয় তবে সম্ভবত আপনার পদ্ধতিগুলি খুব দীর্ঘ; এগুলি সাধারণত ছোট (বেশিরভাগ ব্যক্তিগত / সুরক্ষিত) ভাগে ভাগ করা বা আরও জেনেরিক সহায়ক শ্রেণি ইত্যাদি ব্যবহার করা ভাল a

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

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

PS - আপনি কীভাবে পৌঁছতে পারবেন তা দেখতে স্ট্যান্ডার্ড জাভা পাত্রে কোডটি দেখুন, ওহ, 70% বা আরও ...


5

আপনার কোডে 25% মন্তব্য করা একটি দুর্দান্ত লক্ষ্য এবং এটি ক্লায়েন্টকে খুশি করে। এখন "i + = 1; // বৃদ্ধি আমি বাই 1" এর মতো 25% ক্রেপি ফিলার মন্তব্যগুলি লিখতে হবে আপনার নীচে থাকা উচিত, তাই আপনার সময় নিন, দরকারী মন্তব্য লিখুন এবং আপনার অনুভূতিটি উপভোগ করুন যে আপনাকে কিছু করার জন্য আসলেই অর্থ প্রদান করা হচ্ছে যাহাই হউক না কেন।


এটিও দুর্দান্ত একটি +1। আমি জানি না কমেন্টের হারের ক্ষেত্রে কোনও ভাল লক্ষ্য প্রকাশ করা যেতে পারে কি না, তবে আমরা অনেকেই না জেনে দরকারী উপায়ে এই '' লক্ষ্য 'পৌঁছাতে পারি ... আমি সম্প্রতি একটি পুরানো কোডের সন্ধান পেয়েছি আমি আমার ক্যারিয়ারের শুরুতে 80 এর দশকে এটিতে একটি অভিনব উচ্চ কার্যকারিতা অ্যালগরিদম দিয়ে লিখেছিলাম: এটির মধ্যে কেবল 10% মন্তব্য রয়েছে, তবে পূর্ববর্তীভাবে, আমি আশা করি যে আমি এটিতে আরও বেশি কিছু রাখি ;-)
ক্রিস্টোফ

4

আমরা সকলেই জানি এটি একটি কৃপণ প্রয়োজনীয়তা। মজার প্রশ্নটি এখানে

কিভাবে প্রতিক্রিয়া?

সমস্যাগুলি দৃশ্যমান করার ক্ষেত্রে আমি একজন বড় বিশ্বাসী। এখানে আমি অর্থের কথাবার্তাটি ব্যবহার করব।

আমাকে এটি করতে বলুন এবং আমি নিশ্চিতভাবে বলব, এটি আমার বিডে 1% যুক্ত করবে। ওহ তবে এটি ভবিষ্যতের যে কোনও রক্ষণাবেক্ষণ বিডে 20% যুক্ত করবে।

কেবল একবার তারা জিজ্ঞাসা করল কেন আমি তাদের শিখাব কেন ভাল নামগুলি হল মন্তব্য করার প্রয়োজন এড়ানো।

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


3

হ্যাঁ, আমি আপনার হতাশাকে মূর্খ নিয়ম দিয়ে বুঝতে পারি। আমি অযথা মন্তব্য সহ প্রচুর প্রোগ্রাম পড়েছি

x = x + 1; // add 1 to x

এবং আমি নিজেকে বলি, সুতরাং এটি একটি প্লাস চিহ্নের অর্থ কী !! বাহ, আমাকে বলার জন্য ধন্যবাদ, আমি এটি জানতাম না।

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

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

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

মনে রাখবেন যে আপনার সংস্থাটি যে লোকদের সাথে আলোচনা করছে তারা এই 25% নিয়মটি আবিষ্কার করেছিল বা নাও হতে পারে। এটি উপরের থেকে তাদের উপর চাপানো কোনও নিয়ম হতে পারে।

আমি পাঁচটি সম্ভাব্য প্রতিক্রিয়া দেখছি:

এক. আপনার মনিবকে বা যে ক্লায়েন্টের সাথে এই বিষয়ে তর্ক করতে negoti মতভেদ এটি কিছুই অর্জন করবে না, তবে আপনি চেষ্টা করতে পারেন।

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

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

/*
GetFoo function
Parameters:
  name: String, contains name
  num: int, the number
  add_date: date, the date added
Returns:
  foo code: int
*/
int GetFoo(String name, int num, Date add_date)

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

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

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

MOVE IA010 TO WS124

এবং তারা "ডকুমেন্টেশন" এর একটি লাইন তৈরি করবে যা বলেছিল

COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE

যাইহোক, মোটামুটি সহজেই সমান মূল্যহীন ডকুমেন্টেশন তৈরির জন্য একটি প্রোগ্রাম অবশ্যই লিখতে পারে। লাইনের মতো পড়ুন

a=b+c

এবং মন্তব্য উত্পন্ন

// add b to c and save result in a

প্রভৃতি

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

ওহ, যাইহোক, আমি যুক্ত করতে পারি যে আপনি সর্বদা মেট্রিক গেম করতে পারেন।

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

x=x+4;

পরিবর্তে আমি লিখব:

x=x+1;
x=x+1;
x=x+1;
x=x+1;

Loops? এটি ভুলে যাও, আমি কোডটি দশবার কপি করে পেস্ট করব। প্রভৃতি

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


2

যথেচ্ছ মেট্রিকগুলি অনেকগুলি প্রকল্পের জীবনের সত্য বলে মনে হচ্ছে ...

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

মন্তব্যগুলিতে কোড যুক্ত করা উচিত এবং কী চলছে তা ব্যাখ্যা করুন (এবং কেবল কোডটি পুনরাবৃত্তি করবেন না)।

এটি বলেছে, যদি আপনার গ্রাহক এটিই চান এবং আপনার সংস্থা যদি সরবরাহ করতে সম্মত হয় তবে আপনার QA পরিচালক যদি সাধারণ জ্ঞানের একটি ডোজ বিকাশ না করে তবে আপনি আটকে আছেন।


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

2

স্বল্প মেয়াদে কিছুই নেই যা আপনি সত্যিই করতে পারেন। এটি সঙ্গে বরাবর যেতে.

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

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

ক্লায়েন্টের অনুমতি ব্যতীত আপনার কোনওরকম পরিস্থিতিতেই আপনার বিরুদ্ধে যাওয়া উচিত নয়।


2

আমি এখানে আমার সহকর্মী প্রোগ্রামার দ্বারা প্রদর্শিত কল্পনা অভাব দ্বারা হতাশ।

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

এটি মোটেও বোকা বা হাস্যকর শোনায় না। যে সমস্ত লোক প্রয়োজনীয়তা লিখেছিল তারা সম্ভবত প্রোগ্রামার নয়। কোনও পূর্ববর্তী প্রকল্পের সাথে তাদের খারাপ অভিজ্ঞতা থাকতে পারে। তাদের রক্ষণাবেক্ষণের লোকেরা অভিযোগ করছেন: "এই বিষ্ঠার কোনওটিই নথিভুক্ত নয়!"! তারা পরবর্তী প্রকল্পের জন্য নতুন প্রয়োজনীয়তা লেখার সাথে সাথে এটি কানে বাজে।

আপনি যদি নিজের কোড ডকুমেন্ট করার বিষয়ে এবং রক্ষণাবেক্ষণকারী দলের জন্য প্রসঙ্গ সরবরাহ সম্পর্কে গুরুতর হন তবে এই প্রয়োজনীয়তা স্বয়ংক্রিয়ভাবে পূরণ হবে be সুতরাং এটি সম্পর্কে একটি ভগ হতে না!

শেষ পর্যন্ত, এটি 21% বা 29% হয়ে থাকুক, কেউই পাত্তা দেবে না। ক্লায়েন্টটি আপনার স্টাফকে কিছু স্বতন্ত্র বিকাশকারী দ্বারা পর্যালোচনা করবে এবং আপনি কী করেছেন তা তিনি আরও ভাল বুঝতে পারবেন।


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

0

আমি অনেক প্রোগ্রামারদের সাথে দেখা করেছি যারা এই প্রকল্পে বর্তমানে কাজ করে না এমন লোকেরা কীভাবে বিদ্যমান তা বোঝে না।

তাদের জন্য যা কিছু তারা জানে, তারা প্রত্যেকেই চেনে।

বর্তমানে যদি তারা প্রত্যেকে কিছু জানেন না, তবে সেই লোকেরা তাদের কাছে "বোকা"।

এই মানটির সাহায্যে আপনি মন্তব্যগুলি লেখার অভ্যাসে পড়তে বাধ্য করতে পারেন।

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

অবিশ্বাস্য বাগ সহ লাইনে মন্তব্য করা ভবিষ্যতের প্রোগ্রামারদের দুর্ঘটনাক্রমে কোনও প্রোগ্রাম পুরোপুরি ভাঙ্গতে এড়াতে সহায়তা করতে পারে (বিশেষত যখন দ্রুত পরীক্ষা করার সময় "ভাঙা"-পার্টটি স্পষ্ট হয় না)।


3
টাইপরাইটারগুলিতে 10000 বানরকে ধাক্কা দেওয়ার সমস্যাটি এগুলি নয় যে তারা কখনও মূল্যবান কিছু লেখেন না, তবে সেই বর্জনীয়রূপে বিরল রত্নগুলি আবর্জনার স্তূপে খুঁজে পাওয়া শক্ত।
হস্তান্তরকারী 1
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.