কোড ডকুমেন্টেশন প্রথম? [বন্ধ]

Question

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

Comments

হ্যাঁ. এটা একটা ভালো ধারণা. লোকেরা সারাক্ষণ তা করে। আপনি আরও কি জানতে চান?

— এসলট

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

— চাকরি

এটি দুর্দান্ত ধারণা, অন্যথায় আপনি অনির্ধারিত বৈশিষ্ট্যগুলি সহ শেষ করেন।

— ক্রিস করুন

@ এস.লোট যে সাধারণ প্রশ্নটি জিজ্ঞাসা করছেন তার সরল সত্যটি তিনি আরও কিছু তথ্য সন্ধান করছেন কারণ আমি নিশ্চিত যে আপনি অবগত ছিলেন। তবে মনে হয় আপনি অন্য ব্যক্তির ত্রুটিগুলি সম্পর্কে মন্তব্য করতে পছন্দ করেন।

— কেনেথ

এটি আরও ভাল হবে যদি আপনি স্বীকৃতি পরীক্ষা লিখে থাকেন এবং তারপরে সেই স্বীকৃতি পরীক্ষাগুলি পূরণ করতে টিডিডি ব্যবহার করেন;)।

— মার্টিন ব্লোর

Answer 1

হ্যাঁ.

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

আইডিইয়ের চেয়ে অঙ্কন বোর্ডে কিছু ঠিক করা সহজ।

Comments

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

— ক্যাফগিকে

@ চাদ এটি সত্য। আমি প্রতিফলিত করতে আমার উত্তর সম্পাদনা করেছি।

— ম্যাক্সপাম

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

— জ্যাচারি স্কট

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

— জনসিওয়েব

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

— ইভান প্লেইস

Answer 2

এটি সম্পর্কে চিন্তাভাবনার দুটি উপায় রয়েছে:

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

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

Comments

টিডিডির জন্য +1। ডকুমেন্টিংয়ের চেয়ে একেবারে ভাল বিকল্প, তারপরে কোড পরিবর্তন হলে উল্লেখযোগ্য পরিমাণে ডকুমেন্টেশন পরিবর্তন করতে হবে।

— এথেল ইভানস 21

এছাড়াও টিডিডি আকারে ডকুমেন্টেশনের জন্য +1 করুন।

— সেভেনসিয়াট

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

— উঠেছে

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

— ইভান প্লেইস

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

— ইভান প্লেইস

Answer 3

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

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

Comments

একদম ঠিক! পরিবর্তন ঘটে। ডকুমেন্টেশন দড়ি। কোড ডকুমেন্টেশনের সত্যতম ফর্ম is

— জ্যাচারি স্কট

Answer 4

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

সম্পাদনা: কিছু ডকুমেন্টেশন যদিও আপনি দীর্ঘ যেতে হবে তা করা উচিত। এটি পরে পুরো ডকুমেন্টেশন করা সহজ করে তোলে।

Answer 5

জোশুয়া ব্লচ তার এই সাক্ষাত্কারে "কোডারস এট ওয়ার্ক" বইয়ের জন্য তার সাক্ষাত্কারে এই বিষয়টি নিয়ে আলোচনা করেছেন।

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

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

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

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

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

- জোশুয়া ব্লচ, পিটার সেবেলের " কোডারস এট ওয়ার্ক: রিফ্লাকশন অফ ক্র্যাফ্ট অফ প্রোগ্রামিং " এর একটি সাক্ষাত্কার থেকে

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

Comments

এটি ভাল পরামর্শ, তবে ভাল ডকুমেন্টেশনে এপিআইয়ের ব্যবহার অন্তর্ভুক্ত রয়েছে।

— ফ্রাঙ্ক হিলিমান

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

— ডিপিএম

Answer 6

কিছু লোক এমনকি আরও এগিয়ে যান এবং বলে যে কোনও সংস্থার পুরোপুরি পিছনের দিকে কাজ করা উচিত, তাই

1. প্রেস রিলিজ লিখুন
2. একটি FAQ লিখুন
3. গ্রাহকের অভিজ্ঞতা সংজ্ঞায়িত করুন
4. ব্যবহারকারী ম্যানুয়াল লিখুন
5. প্রোগ্রামিং শুরু করুন

Http://www.allthingsdistributes.com/2006/11/working_backwards.html দেখুন

Answer 7

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

README আপনার প্রকল্পের প্রতিটি বিবরণ নথিভুক্ত করে না । পরিবর্তে, এতে সাধারণত নিম্নলিখিত তথ্য থাকে:

1. বর্ণনা : সংক্ষিপ্ত "বিক্রয় পিচ"। পাঠককে কেন তাদের পড়া চালিয়ে যাওয়া উচিত তা বলুন।
2. দ্রুত উদাহরণ : সংক্ষিপ্ত কোড স্নিপেট বা বর্ণনার সমর্থন করতে স্ক্রিনশট।
3. দ্রুত শুরু : কীভাবে যাবেন, নির্দেশাবলী ইনস্টল করুন এবং আরও উদাহরণ।
4. আরও ডকুমেন্টেশন : সম্পূর্ণ ডক্স এবং আরও তথ্যের লিঙ্ক।
5. প্রকল্প সংগঠন : লেখক কারা, কীভাবে অবদান রাখতে হয়, কীভাবে বাগ ফাইল করতে হয়।
6. আইনী নোটিশ : লাইসেন্স, কপিরাইট এবং অন্য কোনও আইনি বিবরণ।

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

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

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

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

আরও তথ্যের জন্য, নিম্নলিখিতটি দেখুন:

1. রেডিমে চালিত বিকাশ
2. সর্বাধিক গুরুত্বপূর্ণ কোডটি কোড নয়
3. আপনি যা ডকুমেন্ট করেছেন তা আপনি

Answer 8

ক্লাসগুলি কীভাবে ইন্টারেক্ট করে সে সম্পর্কে কেন আপনি ভাবতে চান না? কেন এটি একটি খারাপ জিনিস? ক্লাসগুলি কী তা জানার আগে আমি আসলে মিথস্ক্রিয়াগুলি সম্পর্কে চিন্তা করি। এইভাবে ক্লাসগুলি তাদের সনাক্ত করে।

Answer 9

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