কত ডকুমেন্টেশন যথেষ্ট?


15

কতগুলি প্রযুক্তিগত (ভবিষ্যতের বিকাশকারীদের জন্য) ডকুমেন্টেশন যথেষ্ট ? ঘন্টা উপযুক্ত কোডিং এবং ঘন্টা উপযুক্ত যে ডকুমেন্টিং মধ্যে একটি অনুপাত আছে?

পাপাদিমুলিস যুক্তি দেখান যে আপনার উচিত

সর্বাধিক বোঝার সুবিধার্থে প্রয়োজনীয় ন্যূনতম পরিমাণ ডকুমেন্টেশন তৈরি করুন,

এটি কি একটি ভাল গাইডলাইন, বা আমার তৈরি করা উচিত এমন কোনও নির্দিষ্ট জিনিস রয়েছে?


1
শেষ ব্যবহারকারী / ইউআই বা প্রযুক্তিগত / উত্স কোড ডকুমেন্টেশন?

2
উত্স কোডের পরামর্শের জন্য, আমাদের সাইটের প্রথম প্রশ্নটি দেখুন: প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার
ক্রোয়েশনস / ১ / ২

উত্তর:


24

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


1
+1 আমিও এই ধারণাটি পছন্দ করি। আপনার সফ্টওয়্যারটি বিকাশ করুন যাতে এটি এত স্বজ্ঞাত যে ডকুমেন্টেশন প্রয়োজন হয় না।

12

লা পারফেকশন এস্ট এটিনটি নন পাস কোয়ান্ড ইল এন 'এ প্লাস রিয়েন à আজউটার, মাইস কোয়ান্ড ইল এন'এই প্লাস রিয়েন à অবসরপ্রাপ্ত।
এন্টোইন ডি সেন্ট-এক্সুপুয়ারি

(ইংরাজীতে: সংযোজন করার মতো আরও কিছু না থাকলে সিদ্ধি পৌঁছায় না, তবে যখন অপসারণের মতো আরও কিছু থাকে না)।

1
সুতরাং এমন একটি প্রকল্প যেখানে সমস্ত ডকুমেন্টেশন সরানো হয়েছে, সঠিক?

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

1
@ সিজেএমউকে এবং সেই ব্যাখ্যাটি জিজ্ঞাসা করা প্রশ্নের উত্তর কীভাবে দেয়?

@ ThorbjørnRavnAndersen। এটা না; এটি আপনার মন্তব্যের জবাবে একটি মন্তব্য ছিল - যা রেকর্ডের জন্য আমার সন্দেহ হয়েছিল যে বেনোইটের উত্তরটির ভুল ব্যাখ্যা ছিল। শুধুমাত্র বেনোইট নিশ্চিতভাবে উত্তর দিতে পারে। যাইহোক, আমার উত্তর অন্য কোথাও তালিকাভুক্ত ...
সিজেএমউকে

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

3

আমি এই বিষয়টি নিয়ে কিছুক্ষণ ভাবছিলাম।

আমার উপসংহারটি হ'ল - এটি পরিমাণের বিষয় নয়, তবে গুণমান এবং প্রসঙ্গে।

উদাহরণস্বরূপ, একটি যথাযথ প্রকল্প কাঠামো ফাইলগুলি কোথায় রয়েছে তা ব্যাখ্যা করে মন্তব্যগুলিকে মারধর করে (বাস্তবায়ন বনাম ইনটেনশন)

একইভাবে, প্রসঙ্গ বেট নামকরণের স্পষ্টকরণের শ্রেণিবদ্ধকরণ (একটি রোগীর আইডি -> রোগী.আইডি)।

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

কোড নিজেই ডকুমেন্টেশন বিবেচনা করার পক্ষে যথেষ্ট ভাল নয়। বেশিরভাগ ক্ষেত্রে সমস্যাটি কোডটির কার্যকরী মন্তব্য করা বা মন্তব্য করা হয় না, বরং ড্রাইভিং ফোর্স (ডোমেন লজিক) নয় isn't

আমরা মাঝেমধ্যে কারা বস তা ভুলে যাই - যদি কোড পরিবর্তন হয় তবে ডোমেন যুক্তি বা যুক্তি হওয়া উচিত নয়, তবে যদি ডোমেন যুক্তি বা যুক্তি কোডটি পরিবর্তন করে তবে অবশ্যই তা হয়ে যাবে।

ধারাবাহিকতাও খুব গুরুত্বপূর্ণ - যদি এটি ধারাবাহিক না হয় তবে নিজেই কনভেনশন অকেজো।

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

অর্ধ সংগ্রাম চেনা

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

মন্তব্য করার ক্ষেত্রে, যুক্তির পিছনে ডোমেন যুক্তি প্রদর্শন করা সর্বদা ভাল।

উদাহরণস্বরূপ, আপনি চিকিত্সা শিল্পে কাজ করছেন। আপনার পদ্ধতিতে আপনি "ইসপ্যাটেন্টসেকচার = সত্য" লিখেছেন;

এখন, কোনও শালীন প্রোগ্রামারই বুঝতে পারেন যে রোগীটিকে সুরক্ষিত হিসাবে চিহ্নিত করা হচ্ছে। কিন্তু কেন? এর অর্থ কী?

এক্ষেত্রে রোগী এমন একজন বন্দী যেটিকে নিরাপদে কোনও অফ-প্রসেস হাসপাতালে স্থানান্তর করা হয়েছিল। এটি জানার পরে, ঘটনাসমূহ কল্পনা করা সহজ যেগুলি এই মুহুর্তে পৌঁছায় (এবং সম্ভবত এখনও কী ঘটবে)।

সম্ভবত এই পোস্টটি দার্শনিক মনে হচ্ছে - তবে মনে রাখবেন যে এটি 'যুক্তি' বা 'যুক্তি' যা আপনি লিখেছেন - কোড নয় -


1

আমি পাপাদিমিউলিসের উক্তিটির সাথে একমত। উত্স কোডটি নিজের পক্ষে কথা বলতে পারে, তবে কোডটি কেন এটি বিদ্যমান তা কীভাবে ব্যবহার করা উচিত এবং কোডটি কীভাবে আচরণ করা উচিত তা আপনাকে বলতে পারে না।

আমি একটি ভাল অনুপাত জানি না।

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

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


1

নিজেকে দ্বিতীয় অনুমান করা বন্ধ করতে যথেষ্ট।

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

যতক্ষণ না অনুভূতিটি চলে যায় ততক্ষণ ধুয়ে ফেলুন ।


1
-1: আপনি মূলত 'এহহহ্ ... বলছেন যা খুশি তাই করুন'। যা একটি উত্তর নেই।
স্টিভেন এভার্স

তিনি 'আপনার যা প্রয়োজন মনে করেন তা করুন' বলছেন বলে মনে হচ্ছে যা আমার কাছে বৈধ উত্তরের মতো শোনাচ্ছে। আমি আরও অনেক নির্দিষ্ট উত্তর থেকে সাবধান থাকব।
সিজেএমউকে

1

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

  • "সিস্টেমের বোঝাপড়া" সম্পর্কে আপনাকে উদ্বেগযুক্ত বিষয়গুলি ঝুঁকি হিসাবে প্রকাশ করুন
  • ঝুঁকিগুলির অগ্রাধিকার দিন
  • আপনার দলটি প্রকল্পের ঝুঁকি যথেষ্ট পরিমাণে হ্রাস না হওয়া পর্যন্ত ঝুঁকিগুলি হ্রাস করুন। এই ক্ষেত্রে আপনি সম্ভবত একরকম ডকুমেন্টেশন তৈরি করবেন be

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

এখন কিছু ঝুঁকি শনাক্ত করুন। আপনি যে সিস্টেমটি তৈরি করেছেন (বা নির্মাণ করছেন) তা দিয়ে আপনার দলকে সবচেয়ে বেশি চিন্তিত করে? এগুলি ঝুঁকিপূর্ণ বিবৃতি হিসাবে বাক্যাংশ করুন। আমি SEI এর কন্ডিশন-ফলাফলের স্টাইলটি পছন্দ করি তবে অন্যগুলিও রয়েছে। উদাহরণ:

  • ডেটা মডেল বড় এবং জটিল; ডেভেলপাররা প্রদত্ত পরিস্থিতিতে কোন ডেটা উপাদান ব্যবহার করতে পারে তা নাও জানেন।
  • সিস্টেমের নির্ভরযোগ্যতা বাড়াতে API সংযোগ সীমা রয়েছে; বিকাশকারীরা ঘটনাক্রমে সংযোগের সীমা ছাড়িয়ে যেতে পারে।
  • প্লাগ-ইনগুলি বেশ কয়েকটি ক্রমিক পদক্ষেপে গ্রাস করা হয়; বিকাশকারীরা এই অর্ডার করা পদক্ষেপগুলি মাথায় রেখে প্লাগ-ইনগুলি না তৈরি করতে পারে।

এখন দল হিসাবে, ঝুঁকিগুলিকে অগ্রাধিকার দিন। বহু ভোটদান অত্যন্ত ভাল কাজ করে।

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


1

যতটা সম্ভব কম, তবে যতটা প্রয়োজন necessary

আমি কোথায় কখন ও কখন এটি শুনেছিলাম তা মনে করতে পারি না তবে এটি অনেক অ্যাপ্লিকেশন সহ সর্বাধিক।

প্রযুক্তি বা অ্যাপ্লিকেশন যত জটিল, তত বেশি ডকুমেন্টেশন প্রয়োজন হবে (স্পষ্টতই), তবে স্পষ্টতই আপনি ওভারবোর্ডে গিয়ে সময় নষ্ট করতে চান না।

জনএফএক্সের 'হলওয়ে পরীক্ষা' দুর্দান্ত। তবে নিজেকে বিশ্বাস করুন; আপনি কোডটি বিকাশ করেছেন এবং তাই আপনার সকল ব্যক্তির মধ্যে এমন উপাদানগুলির জন্য অনুভূতি থাকা উচিত যা অতিরিক্ত মনোযোগের প্রয়োজন এবং যে উপাদানগুলি সবার কাছে সুস্পষ্ট হবে। আপনার কোডটি বিকাশকারী যে संघर्षগুলি হয়েছে সেগুলি সম্পর্কে চিন্তাভাবনা করুন এবং আপনার বিকাশকারীরা আপনার কোডটি দেখলে আপনার বোধহয় একটি ধারণা পাবেন।

প্রচেষ্টা ব্যয় কোডিং এবং প্রচেষ্টা ব্যয় ডকুমেন্টিং মধ্যে যে কোনও সম্পর্ক ভুলে যান।


0

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

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

আপনি যদি এটি আগে কখনও না করেন তবে আপনি কতটা কাজ করবেন তা অনুমান করতে পারবেন না, তবে কয়েকটি পুনরাবৃত্তির পরে আপনি কতটা প্রয়োজন তা সম্পর্কে আরও ভাল ধারণা পাবেন।

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