কোড ডকুমেন্টেশনগুলি স্বয়ংক্রিয়ভাবে উত্পন্ন করার কোনও যৌক্তিক কারণ আছে কি? [বন্ধ]


60

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

/// <summary>
/// Initializes a new instance of the <see cref="Person"/> class.
/// </summary>
public Person() ...

সবচেয়ে খারাপ ক্ষেত্রে, এটি আসলে উদ্ভট ডকুমেন্টেশন উত্পন্ন করতে পারে যা নামের অর্থটি হিউরিস্টিকালি আবিষ্কার করার প্রয়াসে আসলে বিভ্রান্ত করছে:

/// <summary>
/// Riches the text selection changed.
/// </summary>
/// <param name="richTextBox">The rich text box.</param>
private void RichTextSelection_Changed(System.Windows.Controls.RichTextBox richTextBox) ...

দেখে মনে হয় যে ঘোস্টডকের সাথে মনোভাবটি হ'ল " এক প্রকার আনুষ্ঠানিক এক্সএমএল ডকুমেন্টেশন থাকা স্বতন্ত্রভাবে ভাল ", তবে যখন সেই ডকুমেন্টেশনটি 100% অপ্রয়োজনীয় তখন কেন? এটি কি সেরা এক টন জায়গা নষ্ট করে না?

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



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

11
এটি হ্রাসকারী ডকুমেন্টেশন তৈরি করে যাতে বিকাশকারীরা এতে বিরক্ত হন এবং সঠিক ডকুমেন্টেশন পূরণ করে। মাইন্ড গেমস সর্বত্র।
Kroltan

2
কখনও কখনও আপনি ডকটি দিতে পারেন তবে কোডটি নয়
লিও

2
সংক্ষিপ্ত উত্তর: না
টমাস এডিং

উত্তর:


14

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

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

আপনার কর্মক্ষেত্রে আপনাকে সমস্ত কিছু নথিভুক্ত করার সময় , মনে হচ্ছে আপনার সহকর্মীরা এটির চারপাশে নিখুঁত উপায়টি খুঁজে পেয়েছে: কেবল ভান করে।


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

14
@ ডেভিডহ্যামেন, আমি ভাল করে জানি যে পর্যাপ্ত ডকুমেন্টেশন না থাকার কারণে কোনও প্রকল্প মারা যেতে পারে। এছাড়াও, "জাস্ট প্রেজেন্ট" ওপির কাছে পরামর্শ ছিল না, তবে ওপির সহকর্মীদের একটি সমালোচনা ছিল।
utnapistim

73

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

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

যে কোনও উপায়ে, অটোজেনারেশনকে একটি সমাপ্ত পণ্য উত্পাদন হিসাবে ভাবেন না। এটিকে আপনার জন্য বয়লারপ্লেট উত্পাদন হিসাবে ভাবেন, সুতরাং ম্যানুয়ালি যে কোনও পরিবর্তন আপনি তাৎপর্যপূর্ণ।


26

কোড ডকুমেন্টেশনগুলি স্বয়ংক্রিয়ভাবে উত্পন্ন করার কোনও যৌক্তিক কারণ আছে কি?

কার দৃষ্টিকোণ থেকে?

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

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

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


1
আমার উদাহরণটি বাদ দিলে নামটি আসলে খুব খারাপ না হলেও গোস্টডক শালীন ডকুমেন্টেশন তৈরি করতে ব্যর্থ হতে পারে।
জেজ

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

3
@ জেজ - অবশ্যই, এটি কেবল একটি গন্ধ। কখনও কখনও এটা ঠিক, কখনও কখনও এটি না।
তেলস্তিন

1
একটি প্রশ্নের উত্তর দিয়ে। চমৎকার;)
পিয়ের আরলাড

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

21

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

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

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

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


আসল উত্তর: কেন স্বয়ংক্রিয় ডকুমেন্টেশন নিষ্কাশন এবং ফর্ম্যাট করা ভাল ধারণা

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

সুতরাং আমাদের ডক্সিজেন ব্যবহারের ফোকাসটি কোড থেকে নিজেই তথ্য বের করা নয়, উত্স কোডের নথিপত্রকে সোর্স কোডের কাছে যতটা সম্ভব কাছে রাখা।

এটি আমাদের সম্পূর্ণ কোডবেস এবং "রিলিজ নোটস" এর কয়েকটি সেট যা সফ্টওয়্যার পণ্যটি বর্ণনা করে তবে বাস্তবে কোনও আসল "কোড ডকুমেন্টেশন" ধারণ করে না এমন একটি "অপারেশন থিওরি" উভয় তৈরি করতে একটি একক সরঞ্জাম ব্যবহার করার অনুমতি দেয় fact সাধারণ জ্ঞান

আমাদের কোডের আচরণের কেন আমাদের নন-সোর্স-কোড ডকুমেন্টেশনের প্রয়োজন হবে, এর দুটি কারণ রয়েছে:

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

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


অক্সিজেন আউটপুট ইংরেজি দেয়, বা এটি কেবল ইংরেজিতে লেখা ডক স্ট্রিংগুলিকে বিন্যাস করে?
dcorking

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

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

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

@ dcorking _ এর দ্বারা আপনি কী বোঝাতে চান তা আমার কাছে ফোগিস্ট ধারণা নেই। ডক্সিজেন প্রোগ্রামারের মন পড়তে পারে না। অক্সিজেন কী করতে পারে তার একটি ভাল উদাহরণের জন্য, ইগেনের পরিবর্তে জনপ্রিয় সি ++ বৈজ্ঞানিক কম্পিউটিং প্যাকেজটির শীর্ষ স্তরের পৃষ্ঠাটি দেখুন । খোঁচাখুঁচি করা! আপনি কিছু ডকুমেন্টেশন দেখতে পাচ্ছেন যা স্পষ্টতই মানুষের দ্বারা লিখিত হয়েছে, অন্যটি নিখুঁতভাবে স্বয়ংক্রিয়ভাবে উত্পন্ন হয়, অন্যটি হ'ল মানব-লিখিত এবং স্বয়ংক্রিয়ভাবে উত্পন্ন উত্স। যদি তাকে বলা হয়, ডোজিজেন স্বয়ংক্রিয়ভাবে ফ্যান-ইন উত্পন্ন করবে (যারা এই ফাংশনটির উল্লেখ করে) এবং ফ্যান-আউট (এই ফাংশনটি কী বলে)।
ডেভিড হামেন

7

অবশ্যই, স্বয়ংক্রিয় ডকুমেন্টেশন বিশেষত সহায়ক যখন এটি কোড লেখক দ্বারা লিখিত অন্তর্দৃষ্টিপূর্ণ, উপযুক্ত বিবরণ পুনরুত্পাদন করতে পারে। অন্যথায়, এটি কেবল একটি গৌরবযুক্ত স্বয়ংক্রিয় বিন্যাসক।

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

সুতরাং, হ্যাঁ, স্বয়ংক্রিয় ডক জেনারেশন কিছু মান যুক্ত করে। অবশ্যই ম্যানেজাররা যতটা অনুমান করেন ততটা না, এবং সাধারণত এমনকি সত্যিকারের ভাল অনুলিপি সম্পাদক হিসাবেও না, তবে কিছুই না।


4
"উত্স কোডের মাধ্যমে ওয়াডিং" সম্পর্কে আপনার মন্তব্য আমি বুঝতে পারি না। অবশ্যই উভয় ক্ষেত্রেই আপনি 'ফ্রবনিক মিউটেটর' বা 'ফ্রবনিকমিকমিটার' এর মতো কোনও কিছু অনুসন্ধান করবেন ... কীভাবে স্বয়ংক্রিয়ভাবে উত্পাদিত ডকুমেন্টেশন সহায়তা করে?
জেজ

2
@ জিজ মিউটরদের সম্পর্কে যা জানা দরকার তা সকলেই frobnickসফ্টওয়্যার ডেভ হয়ে যাবেন না; তারা সোর্স কোডটি কীভাবে সন্ধান করতে পারে তা বুঝতে পারে না (যার জন্য grep/ cscope/ ack/ ইত্যাদির সাথে পরিচিতির প্রয়োজন হতে পারে ), এবং তারা সঠিক ফাইলটি খুঁজে পাওয়া সত্ত্বেও তারা ভাল মন্তব্য করলেও তারা আসল উত্স কোডটি সহজেই পড়তে পারে না একটি SW দৃষ্টিকোণ থেকে। কোনও সূচীটি অনুসন্ধান করার বা অনুসন্ধান বারে টাইপ করার ক্ষমতা, তারপরে পাঠ্যের মাধ্যমে ব্রাউজ করা যা এটি কোনও ওয়েবপৃষ্ঠার অংশ বলে মনে হচ্ছে, তা বেশ মূল্যবান হতে পারে।
কাইল স্ট্র্যান্ড

4
@ জিজ, অ-প্রোগ্রামার বা কমপক্ষে অ-বিশেষজ্ঞদের জন্য একটি মানব পাঠযোগ্য দলিল অপ্রয়োজনীয় নয়। এটা প্রয়োজনীয়. কোডটি কী করতে চায় তা স্পষ্টভাবে প্রকাশ করার জন্য। কোনও কোড লেখার আগে এটি ক্যাপচার করতে হবে। এবং সমস্যার জ্ঞান এবং সমাধান (গুলি) বৃদ্ধির জ্ঞান হিসাবে আপডেট হয়েছে। উদ্ধৃত উদাহরণগুলি রাখার মতো নয়, তবে 'সোর্স কোডে এটি সমস্ত' স্নানের জল দিয়ে বাচ্চাকে আউট টস করছে। "অটো জেনারেশন" খারাপ শোনাচ্ছে, "কোনও ডক্স নেই, কেবল উত্সটি পড়ুন" আরও খারাপ। এটির মতো আপনি যখন কাউকে জিজ্ঞাসা করেন, "এটি কী করে?" এবং তারা বলে, "হুম, এটি চালিয়ে যাক এবং অনুসন্ধান করুন!"
বিল IV

6

এই ফর্মটিতে এটি অকেজো থেকে খারাপ তবে কেবলমাত্র এটি একা পাবলিক স্বাক্ষরের উপর নির্ভর করে (যা জাভাডোকের ক্ষেত্রে, যে কোনওভাবে এপিআই ডকটি পড়ার জন্য দৃশ্যমান)।

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

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

সেই অভিজ্ঞতার ভিত্তিতে প্রশ্নের উত্তর হ'ল: হ্যাঁ, তবে আমাদের অনেক বেশি স্মার্ট সরঞ্জাম প্রয়োজন।

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

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


6

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

এমনকি একটি খারাপ মন্তব্য করা প্রকল্প কমপক্ষে আমাকে কোথায় জিনিস সংজ্ঞায়িত করা হয়েছে এবং সেগুলি কোথায় ব্যবহৃত হয়েছে তা সনাক্ত করতে সহায়তা করতে পারে (উদাহরণস্বরূপ রিফ্যাক্টরিং করার সময়)।

যখন ভাল মন্তব্য করা হয়, ফলাফল পৃষ্ঠাগুলি কোডবেস (যাইহোক আমার ব্যবহারের জন্য) একটি নিখুঁত বাইবেলের কাছাকাছি গঠন করে।

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

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

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

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

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

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

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

সুতরাং, কারণগুলির মধ্যে রয়েছে:

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

এছাড়াও, একটি বোতামের স্পর্শে পয়েন্টি কেশিক মালিকদের খুশি রাখার মানটিকে অবমূল্যায়ন করবেন না।

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


4

বয়লারপ্লেট বা "স্ট্যান্ড-ইন" মন্তব্যগুলি তৈরি করতে ডকুমেন্টেশন জেনারেটরগুলি ব্যবহার করা ভাল যা পরে প্রকৃত বিকাশকারীদের দ্বারা পরে সংশোধিত হয়। প্যারামিটারের ধরণের সাথে শিরোনাম মন্তব্য তৈরি করতে এবং ইতিমধ্যে ভরাট মানগুলি ফিরে আসার জন্য আমি প্রায়শই Eclipse এর Auto-JavaDoc ফাংশনটি ব্যবহার করি, তারপরে ডকুমেন্টেশনের কেবল "মাংস" যুক্ত করব।


3

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

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

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


যদিও স্টাইলোকপ নিয়মটি অক্ষম করা যায়। আমার ভুল না হলে SA1600 বিধি দিন।
জেজ

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

3

টোটোলজি এড়িয়ে চলুন

কোডের জন্য আপনার যখন কেবল কোনও ধরণের ডকুমেন্টেশনের প্রয়োজন হবে কেবল কোনও পদ্ধতি / ফাংশন কেন কিছু করছে তা ব্যাখ্যা করা , নামটি এটি যা করছে তার জন্য যথেষ্ট ।

আপনি যদি এমন কিছু করছেন যা মূio় নয়, বা সর্বনিম্ন বিস্ময়ের নীতি লঙ্ঘন করে তবে ডকুমেন্টেশন প্রয়োজন is

স্বয়ংক্রিয়ভাবে উত্পাদিত ডকুমেন্টেশন যা তথ্যের আউটপুটটির জন্য কেবলমাত্র একটি ফর্ম্যাটর হিসাবে আপনার কোডের গ্রাহকরা প্রায় দাবি করেন। জাভাদোক এটি অত্যন্ত ভাল করে।

প্রতিটি জিনিসই ম্যানুয়ালি নথিভুক্ত করা উচিত নয়

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


2

কোড ডকুমেন্টেশন, কমপক্ষে "স্বয়ংক্রিয়" ধরণের, অ্যাপ্লিকেশনটি বোঝার চেষ্টা করার জন্য লোকেদের জন্য সর্বনিম্ন সাধারণ ডিনোমিনেটর উপস্থাপন করে।

সর্বাধিক পরিশীলিত ব্যবহারকারীরা স্বয়ংক্রিয় কোড ডকুমেন্টেশনের প্রশংসা করবে না। তারা বরং "লক্ষ্যবস্তু" ডকুমেন্টেশন থাকতে পারে যা তাদের (সামান্য) কী বলা দরকার তা তাদের জানায়।

কমপক্ষে পরিশীলিত ব্যবহারকারীরা বিপরীত কারণে এটির প্রশংসা করবেন না; তারা যেভাবেই বুঝতে পারত না।

অটোমেটিক কোড ডকুমেন্টেশনের সর্বাধিক "কৃতজ্ঞ" ব্যবহারকারীরা হলেন যাদের জন্য "" সামান্য জ্ঞান "একটি বিপজ্জনক জিনিস" "তারা ডকুমেন্টেশনটি বুঝতে পারে বা নাও বুঝতে পারে (যদিও তারা সম্ভবত তারা সম্ভবত)) তবে তারা" থাকার বিষয়ে ভাল লাগবে " লুপে রাখা হয়েছে "" এই শ্রোতাদের বেশিরভাগ "ম্যানেজরিয়াল" প্রকার অন্তর্ভুক্ত that's এটি যদি আপনার প্রধান শ্রোতা হয় তবে স্বয়ংক্রিয় কোড ডকুমেন্টেশনটি একটি ভাল জিনিস হতে পারে।


0

"কেন ডকস উত্পন্ন করে" এর সহজ উত্তরটি কেবল এমএসডিএন দেখিয়ে উত্তর দেওয়া যায়।

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

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

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

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

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