হাই টার্নওভার পরিবেশে আরও মন্তব্য কি আরও ভাল?


11

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

মন্তব্যগুলিতে আমার মতামতটি ন্যূনতম হওয়া উচিত এবং কোডটি গল্পটির বেশিরভাগ ক্ষেত্রে বলা উচিত, তবে তার যুক্তিটিও বোঝা যায়। তার যুক্তিতে কোনও ত্রুটি আছে কি? এটি কোডটিকে বিশৃঙ্খলা করতে পারে তবে সংক্ষিপ্ত থেকে মাঝারি দৌড়ে যদি এতে প্রচুর লোক কাজ করে তবে শেষ পর্যন্ত এটি বেশ সহায়ক হতে পারে।


8
আপনি যখন মনে করেন কোনও ভিন্ন প্রকল্প বা অন্য কোনও চাকরিতে চলে যান এবং অন্য কাউকে আপনার কোড বজায় রাখতে হবে তখন আপনার কী হবে মনে হয়? আপনার কোডটি কি এতটাই পরিষ্কার এবং পরিষ্কার যে অন্য কেউ সহজেই বুঝতে পারবেন যে আপনি কী করছেন এবং কেন?
কালেব

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

@ কালেব এমনকি এটি পরিষ্কার এবং পরিষ্কার না হলেও, আপনি কি সত্যিই মনে করেন যে জায়গা জুড়ে ছড়িয়ে ছিটিয়ে মন্তব্যগুলি সাহায্য করবে? বর্ণনার সাথে অন্য কোথাও কিছু ডকুমেন্টেশন কেন লিখবেন না?
joshin4colours

উত্তর:


22

মন্তব্যগুলি কোডকে বিশৃঙ্খলা করে না।

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

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

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


9
+1 Excessive commenting can only hurt when comments are concentrated on the how and not the whyছাড়া আমি এটা আরও এক ধাপ গ্রহণ করা এবং বলতে যখন তারা ব্যাখ্যা কোন মন্তব্য খারাপ হবে কিভাবে পরিবর্তে কেন
ম্যাপেল_শ্যাফ্ট

Comments don't clutter the code.এটি নির্ভর করে, বিশেষত যদি আপনি ব্যবহার করছেন #
ডায়নামিক

11

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

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

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

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


6
একটি পুঙ্খানুপুঙ্খ কোড পর্যালোচনা বিকাশকারী দ্বারা অতিরিক্ত মন্তব্য প্রশ্ন করা উচিত, কিন্তু আপনি একেবারে সঠিক যে তার দল নিয়মিত কোড পর্যালোচনা থেকে দীর্ঘমেয়াদী মন্তব্যগুলির চেয়ে অনেক বেশি উপকৃত হবে।
ম্যাপেল_শ্যাফ্ট

4
"গুণমান, পঠনযোগ্য কোডটি এটি কী করে তা ব্যাখ্যা করার জন্য কখনও অতিরিক্ত মন্তব্যের প্রয়োজন হবে না।" - যা লিখিত 90% কোডের জন্য সত্য নয়।
অলিভার ওয়েইল

1
@ অলিভারওয়েলার: সুতরাং লিখিত 90% কোড একটি ভাল কোড পর্যালোচনা দিয়ে করতে পারে। আমার দলে পাঁচ জন সিনিয়র বিকাশকারী রয়েছে যেখানে সমস্ত কোড কমপক্ষে একজন অন্য প্রবীণ দ্বারা পর্যালোচনা করা হয়েছিল এবং তারা কমপক্ষে কমেন্ট করে মন্তব্য সহ খুব পঠনযোগ্য কোড তৈরি করেছে produced
পিডিআর

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

1
@ ডেভ: আমি আপনাকে কিছু অনুমান করার পরামর্শ দিচ্ছি না। আপনি কোডটি অন্য বিকাশকারীকে দিয়ে এবং "আপনি কি এটি পড়তে এবং বুঝতে পারবেন?" বলার মাধ্যমে যাচাই করে নিন? কোনটি "আমি আশা করি এই মন্তব্যগুলি এটিকে পাঠযোগ্য করে তুলবে" এর চেয়ে অনেক বেশি নির্ভরযোগ্য গাইডলাইন এবং এটির একটি দ্রুত প্রতিক্রিয়া লুপ রয়েছে (যেমন আপনি কোডটি আবারও লিখতে পারেন, বা একটি মন্তব্য যুক্ত করতে পারেন, যদিও এটি এখনও আপনার মনে সতেজ থাকে)।
পিডিআর

6

মন্তব্যে সমস্যাটি হ'ল তারা কোডের সাথে সত্যই দ্রুত তাড়াতাড়ি বাড়তে থাকে। এর অর্থ কোডটিতে প্রায়শই বিভ্রান্তিমূলক বা ফ্ল্যাট-আউট ভুল মন্তব্য থাকে, তাই তারা সাহায্যের চেয়ে পাঠযোগ্যতার ক্ষতি করে hurt

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


5

"হাই টার্নওভার পরিবেশে আরও মন্তব্য কি আরও ভাল?"

আমার ধারণা তারা আরও খারাপ হতে পারে:

  • বিভিন্ন লেখক বিভিন্ন স্টাইল এবং বিশদের মাত্রা ব্যবহার করবেন এবং অন্যান্য ব্যক্তিদের দ্বারা মন্তব্য আপডেট করার ক্ষেত্রে কম হবে।

  • "কী মন্তব্য করা দরকার" এর মতামত ব্যক্তি থেকে একজনে পরিবর্তিত হয়।

  • তারা কোড লেখার অনুশীলন অব্যাহত রেখেছে যে বর্ণনামূলক নাম সহ কোড পড়তে সহজ বিরোধিতা হিসাবে ব্যাখ্যা করার জন্য মন্তব্য সহ পড়া শক্ত।

  • তাদের ফর্ম্যাট এবং ধারাবাহিকতা বজায় রাখা নিজেই একটি কাজ হয়ে যায়।

  • নতুন ব্যবহারকারীদের দ্রুত পরিবর্তন করতে সক্ষম হওয়ার আগে 'ফর্ম্যাট' স্ট্যান্ডার্ডটি শিখতে হবে।


3
আপনার তালিকাভুক্ত সমস্যাগুলি কেবলমাত্র মন্তব্য নয়, উচ্চ টার্নওভার পরিবেশে কোডের জন্যও সমস্যা issues এটি ... আকর্ষণীয়;) কোনও কোড / মন্তব্য সমস্যার চেয়ে আরও বেশি লোকের সমস্যা।
ইয়ানিস

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

4

পয়েন্ট 1: উচ্চ টার্নওভার পরিবেশে স্পষ্টতা গুরুত্বপূর্ণ

পয়েন্ট 2: ভার্বোসিটি স্পষ্টতা নয়

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

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

উদাহরণস্বরূপ, কোনও সম্পর্কহীন ক্ষেত্রের উচ্চ বিটটিতে একটি পতাকা স্টাফ করা কিছু পরিস্থিতিতে পুরোপুরি অনুমোদিত হতে পারে এবং এটি কিছু পরিস্থিতিতে পারফরম্যান্সের দৃষ্টিভঙ্গি থেকে বোঝার বোঝা তৈরি করতে পারে তবে স্বচ্ছতার ক্ষেত্রে এটি সর্বদা একটি খারাপ ধারণা pretty এমনকি যদি আপনি এটি থেকে দূরে মন্তব্য করেন তবেও।

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

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

1

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

আরও একটি দুর্দান্ত থ্রেড রয়েছে যা মন্তব্যগুলি ডকুমেন্টেশন কিনা তা coversেকে দেয়।


1

মন্তব্যগুলি অন্যের তুলনায় কিছু পরিস্থিতিতে বেশি সহায়ক। এটি এতটাই মৌলিক যে আমি এতগুলি উত্তরের মধ্যে কীভাবে এটি ব্যাখ্যা করব তা নিয়ে উদ্বিগ্ন যে আমি বুঝতে পেরেছি "বিরোধী মন্তব্য"।

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

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

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

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