শিল্পে ডকুমেন্টেশনের প্রতিরোধের কী আছে?

Question

এমনকি সর্বাধিক প্রাথমিক ডকুমেন্টেশন লেখার ক্ষেত্রে বিরূপতা রয়েছে বলে মনে হয়। আমাদের প্রকল্পের README গুলি তুলনামূলকভাবে খালি। দস্তাবেজে নির্ভরতার তালিকাও নেই।

শিল্পে আমি অজানা এমন কিছু আছে যা প্রোগ্রামারদের ডকুমেন্টেশন লেখার পক্ষে অপছন্দ করে? আমি প্রয়োজনে ডক্সের অনুচ্ছেদগুলি টাইপ করতে পারি, অন্যরা কেন এটিকে এতটা বিরক্ত করে?

আরও গুরুত্বপূর্ণ, আমি কীভাবে তাদের বোঝাতে পারি যে ডকগুলি লেখাই আমাদের ভবিষ্যতে সময় এবং হতাশাকে বাঁচায়?

Comments

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

— এফিট করুন

কারণ অভিজ্ঞতা প্রমাণ করেছে যে কেউ ডক্স পড়ে না reads

— ব্যবহারকারী16764

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

— প্যাট্রিক হিউজেস

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

— ড্যান পিচেলম্যান

এটি মজাদার নয় ...

Answer 1

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

পরিবর্তে, সমস্যা এবং সম্ভাব্য সমাধানগুলিতে মনোনিবেশ করুন।

1. ভাল ডকুমেন্টেশন নিজে লিখুন

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

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

যদি কেউ আমাকে ক্লায়েন্ট সি এর জন্য কোনও জিনিস কাস্টমাইজ করতে ফ্যাক্টরী এফ এর নতুন বাস্তবায়ন কীভাবে লিখবেন তা জিজ্ঞাসা করে, আমি তাদের বলি এটি বিকাশকারী গাইডের পৃষ্ঠা 10 এ রয়েছে।

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

২. আপনার ডকুমেন্টেশনের মান প্রমাণ করুন

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

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

অথবা

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

৩. বোর্ডে পরিচালনা পান

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

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

৪. ডকুমেন্টেশনটি দেখলে উত্সাহ দিন

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

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

ফ্রেমওয়ার্ক জি-তে বাগ বিটির জন্য কার্যবিধির নথিপত্র দেওয়ার জন্য আপনাকে ধন্যবাদ। আমি সে সম্পর্কে জানতাম না এবং আমি মনে করি না যে সেখানে আপনি কী করছেন তা আমি বুঝতে পারতাম।

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

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

Comments

পয়েন্ট # 2 এর জন্য +1, সরাসরি ওপি-র প্রশ্নের উত্তর দিয়ে যা "" আমি কীভাবে

— বোঝাব

আমি এই উত্তরটি পছন্দ করি, অন্যরা "কীভাবে" পরিবর্তে "কেন" - তার দিকে বেশি মনোনিবেশ করেছিল

— রুডলফ ওলা

@ মাউস - কারণ বেশিরভাগ ক্ষেত্রেই ডকুমেন্টেশন লেখার ফলে ভবিষ্যতে আপনার সময় এবং হতাশাকে বাঁচায় না । এগুলি খুব কমই সঠিক হয় এবং লোকেরা কখনই সেগুলি পড়ে না।

— তেলস্তিন

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

— অ্যামি ব্লাকনশিপ

এটি মানুষের অনুপ্রেরণাগুলি অনুমান করা খুব সহায়ক বলে মনে করে।

— tymtam

Answer 2

আমার অভিজ্ঞতাতে দুটি প্রধান কারণ রয়েছে:

সময়সীমা

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

পরিবর্তন

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

আমি ব্যক্তিগতভাবে এমনকি মন্তব্য আর তাকান না। কোড মিথ্যা বলতে পারে না।

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

Comments

"আমি ব্যক্তিগতভাবে মন্তব্যগুলিতে আর তাকাব না" এর জন্য +1, আমি মনে করি এটি সাধারণ; আপনি যখন কোডটি নিজেই একটি নির্দিষ্ট স্বাচ্ছন্দ্যে পৌঁছান, আপনি কমেন্টের চেয়ে তাড়াতাড়ি পড়তে পারেন (এবং মন্তব্যগুলি ভাল না হলে আরও দ্রুত), এবং কোডটি মিথ্যা বলে না

— জিমি হোফা

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

— zzzzBov

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

— টেলাস্টিন

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

— বৃহস্পতিবার

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

— কেভিন রুবিন

Answer 3

এখানে খেলতে বেশ কয়েকটি কারণ রয়েছে:

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

2. ডকুমেন্টেশন লেখার পক্ষে যুক্তিযুক্ত লেখার কোডের চেয়ে আলাদা দক্ষতা। কিছু সফ্টওয়্যার বিকাশকারী অন্যদের চেয়ে এতে ভাল are ডকুমেন্টেশন লেখার চেয়ে কিছু লেখার কোডে আরও ভাল।

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

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

5. কোড পরিবর্তন হলে আপনাকে ডকুমেন্টেশনও পরিবর্তন করতে হবে। সেখানে যত কম ডকুমেন্টেশন রয়েছে তত কম পরিবর্তন করতে হবে।

6. কেউ যেভাবেই ডকুমেন্টেশন পড়ে না, তাই কেন বিরক্ত করবেন?

Comments

আবার # 1, আমি মনে করি না যে এটি কখনও

— ঘটেনি

@ ওয়াটসিসনাম: মোটেও নয়। স্বচ্ছ কোড লিখুন যাতে কম ডকুমেন্টেশন প্রয়োজন, এবং আপনি যখন কোডটি পরিবর্তন করবেন তখন আপনাকে কম ডকুমেন্টেশন সংশোধন করতে হবে।

— রবার্ট হার্ভে

@ থ্রি বৃহস্পতিবার: এই বুলেটগুলির অর্থ হ'ল আপনাকে ডকুমেন্টেশন দুটি বার লিখতে হবে না: একবার কোড মন্তব্যের জন্য এবং আবার সাহায্যের ফাইল / প্রোগ্রামার রেফারেন্সের জন্য। আপনার অবশ্যই এটি দুটিবার নতুন করে লিখতে হবে না । ছেলেরা কি এই জিনিসটি পড়ছেন?

— রবার্ট হার্ভে

# 6 ... আমি মনে করি এটি একটি সাধারণ ভুল ধারণা। একজন অনেক মানুষের পুঙ্খানুপুঙ্খভাবে ডকুমেন্টেশন পড়ুন।

— ডায়নামিক

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

— রবার্ট হার্ভে

Answer 4

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

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

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

এটি কখনই ঘটবে না।

Comments

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

— কেভিন রুবিন

আমি প্রস্তাব দিই যে "(সীমিত) ডকুমেন্টেশনের মাধ্যমে তার উদ্দেশ্যগুলি যোগাযোগ করার প্রাথমিক ক্ষমতা" প্রয়োজনীয় প্রোগ্রামার দক্ষতা skill একজন প্রোগ্রামারকে কবি হতে হবে না, তবে তিনি বা সে দলিল করতে না পারলে আমি সত্যই তাকে আমার দলে চাই না। এই জাতীয় ব্যক্তি দীর্ঘমেয়াদী দায়বদ্ধতা।

Answer 5

আরও গুরুত্বপূর্ণ, আমি কীভাবে তাদের বোঝাতে পারি যে ডকগুলি লেখাই আমাদের ভবিষ্যতে সময় এবং হতাশাকে বাঁচায়?

এটা কি এটা করে?

এখানে দুটি ধরণের ডকুমেন্টেশন রয়েছে:

দরকারী ডকুমেন্টেশন

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

অকেজো ডকুমেন্টেশন

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

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

Answer 6

আমি বলব যে মূল কারণটি হ'ল ইচ্ছার অভাব এবং ডকুমেন্টেশনের কার্যকারিতা বোঝার অভাব। ডকুমেন্টেশনের কয়েকটি শ্রেণি বিবেচনা করার জন্য রয়েছে:

পণ্য / রিলিজ ডকুমেন্টেশন

এটি আপনার 'সমাপ্ত' পণ্যটির সাথে বাইরে চলে আসে। এটি কেবল ম্যানুয়ালগুলির চেয়ে বেশি, এটি হ'ল READMEs, পরিবর্তন লগগুলি, হাও-টোস এবং এর মতো। তত্ত্ব অনুসারে, আপনি এগুলি না লিখেই পালাতে পারেন তবে আপনি এমন একটি পণ্য যা লোকেরা ব্যবহার করতে চায় না বা অযথা ব্যয়বহুল এমন একটি সমর্থন বোঝা দিয়ে শেষ করে।

এপিআই ডকুমেন্টেশন

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

কোড মন্তব্য

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

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

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

Comments

"ডকুমেন্টেশনের জন্য প্রাথমিক শ্রোতা অন্য ব্যক্তিরা" এর জন্য +1। অনেক বেশি প্রোগ্রামার অন্যের সাথে কথোপকথনের সত্যই মূল্য দেয় না। (এ কারণেই তারা জ্যেষ্ঠতার দিকে অগ্রসর হওয়া কঠিন মনে করবে।)

— ডোনাল ফেলো

Answer 7

এখানে আমার দুটি সেন্ট।

1. অ্যাগিল ম্যানিফেস্টোতে "ওয়ার্কিং সফটওয়্যার ওভার বিস্তৃত ডকুমেন্টেশন" বলা হয়েছে এবং প্রত্যেকে পৌঁছে যেতে পঠেন না "এটি হ'ল ডানদিকে থাকা আইটেমগুলির মধ্যে মূল্য রয়েছে, আমরা বামদিকে থাকা আইটেমগুলিকে আরও মূল্যবান বলে মনে করি।"

2. দুঃখজনকভাবে এটি https://en.wikedia.org/wiki/Code_and_fix এর পক্ষে সাধারণ এবং ডকুমেন্টেশনগুলি এই মডেলটির সাথে কাজ করে না (এটি সিঙ্কের বাইরে চলে যায়)।

3. সফটওয়্যার ডেভলপমেন্ট ইন্ডাস্ট্রিতে ভাল নিয়ন্ত্রিত হয় না। ডকুমেন্টেশন লেখার কোনও আইনি প্রয়োজন নেই।

4. স্ব-ডকুমেন্টিং কোড হ'ল বর্তমান প্রবণতা।

এটি বলে, আমি মনে করি সেখানে খুব ভাল ডকুমেন্টেশন আছে।

Comments

(1) " আমরা বাম দিকের জিনিসগুলিকে আরও বেশি গুরুত্ব দিয়েছি ... " বোঝায় না যে আমরা ডান দিকের বিষয়ে মোটেই মাথা ঘামাই না। (২) " ৪. স্বতঃ-ডকুমেন্টিং কোডটি বর্তমান প্রবণতা " যদি ডকুমেন্টেশনগুলি তখন প্রয়োজনীয় না হয় তবে কেন লোকেরা প্রথমে এবং সর্বাগ্রে খারাপ / নিখোঁজ নথিপত্র সম্পর্কে অভিযোগ করে? (৩) একজন বিকাশকারী তার কাজের নথি না দিয়ে যে সময় সাশ্রয় করে তার প্রতিটি একক বিকাশকারীকে তথ্য প্রয়োজন হয়, কারণ তাকে ৫ পৃষ্ঠার ডকুমেন্টেশনের পরিবর্তে 5000 ডলার স্ব-ডকুমেন্টিং কোড স্ক্যান করতে হয়। দক্ষতা অন্য কিছু, কিন্তু ওহে আমরা চটপটে!

— জেনসজি

Answer 8

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

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

Answer 9

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

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

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

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

এই কারণে ডকুমেন্টেশন (ইনলাইন কোড মন্তব্য ব্যতীত) যোগাযোগকারীদের কাছে সবচেয়ে ভাল বাম, কোডার নয়।

Comments

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

— অ্যামি ব্লাকনশিপ

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

— কেভিন রুবিন

Answer 10

কোড পড়া আপনাকে দেখায় যে এটি কীভাবে কাজ করে। এটি কেন ব্যাখ্যা করতে পারে না : আপনার মন্তব্য দরকার।

কোডটি পড়া আপনাকে একটি পদ্ধতির নাম এবং পরামিতিগুলির প্রকার প্রদর্শন করে। এটি শব্দার্থবিজ্ঞান, বা লেখকের সঠিক উদ্দেশ্য ব্যাখ্যা করতে পারে না: আপনার মন্তব্য দরকার।

মন্তব্যগুলি কোড পড়ার প্রতিস্থাপন করে না, তারা এতে যুক্ত করে।

Comments

অনুভূতির জন্য +1। তবে এটি প্রশ্নের উত্তর নয়; আপনি প্রকৃত প্রশ্ন জিজ্ঞাসা করা ছাড়া এখানে অন্য কিছুতে সাড়া দিচ্ছেন বলে মনে হচ্ছে।

— বুধবার

Answer 11

ডকুমেন্টেশন কোড হিসাবে কার্যকর করা হয় না। ফলস্বরূপ ডকুমেন্টেশনটি ঠিক আছে এবং সম্পূর্ণ হয়েছে তা যাচাই করতে প্রায়শই কার্যকর প্রতিক্রিয়া লুপ থাকে না। কোড মন্তব্যে পঁচার প্রবণতা একই কারণ।

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

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

Comments

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

— উলফম্যানেক্স

Answer 12

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

Answer 13

ডকুমেন্টেশন পড়তে অপছন্দকারী লোকেরা ডকুমেন্টেশন লেখা অপছন্দ করে। ডকুমেন্টটি পুরোপুরি পড়া এড়াতে প্রচুর প্রোগ্রামাররা তাদের যথাসাধ্য চেষ্টা করবে।

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

Answer 14

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

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

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

যাহোক

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

1. লোকেরা সাধারণত ইমেল চেক করে, অন্যদিকে "ডক" নামক ফোল্ডারের মাধ্যমে কেউ ades

2. ইমেল প্রসঙ্গে উপস্থিত রয়েছে, অন্যান্য ইমেলগুলি ঘিরে রয়েছে বৈশিষ্ট্য এবং সম্পর্কিত বৈশিষ্ট্যগুলি এবং সেই সময়ে যা চলছে সেগুলি নিয়ে আলোচনা করা।

3. ইমেল সংক্ষিপ্ত এবং ফোকাসযুক্ত এবং একটি বিষয় লাইন আছে।

4. ইমেল এমন ব্যক্তিদেরকে এখনই প্রশ্ন জিজ্ঞাসা করার অনুমতি দেয়,

5. ইমেলটি অত্যন্ত অনুসন্ধানযোগ্য, কারণ লোকেরা এটি সমস্ত কিছুর জন্য ব্যবহার করে এবং মেল ক্লায়েন্টরা কয়েক বছর ধরে বেশ খানিকটা এগিয়েছে advanced

6. যদি এটি কোনও ইমেলটিতে থাকে তবে কমপক্ষে অন্য একজন ব্যক্তি জানেন কোথায় এটি সন্ধান করবেন।

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

Comments

# 4 ("যারা এখন অবধি প্রশ্ন জিজ্ঞাসা করেন") বাদে আপনার তালিকাভুক্ত ইমেল সুবিধাগুলির কোনওটিই আমার জন্য নির্ভরযোগ্যভাবে কাজ করে না। 1: লোকেদের ইমেল উপেক্ষা করার প্রবণতা রয়েছে, যখন এটির প্রচুর পরিমাণ থাকে 2: ইমেলটি প্রায়শই প্রসঙ্গ হারাতে পারে, এটিকে পাশের ইস্যুতে সমাহিত করে এবং অতিসত্তর 3: ইমেলগুলি প্রায়শই দীর্ঘ / দীর্ঘ হয় এবং আলোচনার দিকে যাওয়ার সাথে সাথে ফোকাস হারাতে থাকে Email আরও পার্শ্ব সমস্যা এবং বিষয় লাইন প্রায়শই অপ্রাসঙ্গিক / অপ্রচলিত ("পুনরায়: ডাব্লুটিএফ আজ সার্ভারে ঘটেছে?") ...

— gnat

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

— মশা

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

— ওয়েন

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

— gnat