একটি বৃহত কোডবেস কীভাবে বোঝা যায় তা সহজ

Question

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

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

উদাহরণ স্বরূপ:

/*
 * PROGRAMMER'S NOTES:
 *
 * As stated in the documentation, the GamepadManager class 
 * reads joystick joystick input using SDL and 'parses' SDL events to
 * Qt signals.
 *
 * Most of the code here is about goofing around the joystick mappings.
 * We want to avoid having different joystick behaviours between
 * operating systems to have a more integrated user experience, since
 * we don't want team members to have a bad surprise while
 * driving their robots with different laptops.
 *
 * Unfortunately, we cannot use SDL's GamepadAPI because the robots
 * are interested in getting the button/axes numbers, not the "A" or
 * "X" button.
 *
 * To get around this issue, we created a INI file for the most common 
 * controllers that maps each joystick button/axis to the "standard" 
 * buttons and axes used by most teams. 
 *
 * We choose to use INI files because we can safely use QSettings
 * to read its values and we don't have to worry about having to use
 * third-party tools to read other formats.
 */

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

Comments

কোনভাবেই না. যদি আপনার কোডটি অপঠনযোগ্য হয় তবে ডকুমেন্টেশন সাহায্য করবে না।

— টেলাস্টিন

@ জেফো - সমস্যাটি হ'ল এটি করার জন্য সময় নেওয়া একবার হতে পারে। কোড পাঠযোগ্য রাখার সময় সময়ের সাথে সাথে ঘটে। আমি এই ধরণের ডকুমেন্টেশন সহ এমন জায়গায় এসেছি, যখন প্রকল্পটি তরুণ ছিল, বা জো পারফেকশনিস্ট তখনও দলে ছিল। এরপরে এটি পরিত্যাজ্য হয়ে যায় এবং মন্তব্যগুলি দীর্ঘস্থায়ী হয়, আর সঠিক থাকে না।

— টেলাস্টিন

কমপক্ষে একটি উচ্চ স্তরে, কোনও প্রকল্প কী করে, কীভাবে এটি কাজ করে এবং আর্কিটেকচারে কী ট্রেড অফ হয়েছে তার একটি বহিরাগত কোড গদ্য বিবরণ অমূল্য। এই নথির এই ধরণের একটি নতুন আগমনকারীদের কোড ট্যুর নেওয়ার আগে অবশ্যই পড়তে হবে । আছে অনেক আমার-পদ্ধতি-is-খুব-র্যাডিকেল-জন্য-দস্তাবেজ-শহরবাসী নেট প্রায় বাজে কথা, আর যখন এটি হয় সত্য যে ইনিশিয়াল খিলান ডক এবং নব্য খিলান ডক সারিবদ্ধ করা হবে না, একটি গদ্য বিবরণ প্রয়োজনীয় যে কেউ দ্রুত একটি বৃহত্তর, অ-তুচ্ছ কোডবেস ধরতে পারে। এখানে একটি (দরিদ্র) উদাহরণ রয়েছে: zxq9.com/erlmud/html/001-002_architecture.html

— zxq9

@ টেলাস্টিন: কোডটি পঠনযোগ্য কিনা এবং (এবং আমি এটি আশা করি) এটির সাথে কোনও সম্পর্ক নেই। নকশা যুক্তি ডকুমেন্টিং একেবারে গুরুত্বপূর্ণ।

— হালকা ঘোড়দৌড়

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

— হালকা ঘোড়দৌড়

Answer 1

এটা সত্যিই দারুন. আমি আশা করি আরও সফ্টওয়্যার বিকাশকারীরা এটি করার জন্য সময় এবং প্রচেষ্টা নিল। এটা তোলে:

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

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

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

Comments

এবং কেন "পৌরাণিক মেন মাস" একটি স্ব-পূর্বাভাসমূলক ভবিষ্যদ্বাণী হয়ে ওঠে, কেউ যখন তাদের মনে তাজা ছিল এবং প্রকল্পটি পিছনে পড়েনি তখন নতুন দেবের জন্য এই সমস্ত লেখার জন্য সময় নেন নি।

— JeffO

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

— মার্টিন ইয়র্ক

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

— ডিফোর্ড

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

— কোডটিতে

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

— সোভালোরজেন

Answer 2

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

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

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

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

Comments

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

— জন চেস্টারফিল্ড 22

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

— লাইক

ডকুমেন্টেশনের গাইডলাইন হিসাবে ডিআরওয়াই খুব ভাল পয়েন্ট! এটি স্বয়ংক্রিয়ভাবে ফোকাসটি সঠিকভাবে সেট করে এবং বিখ্যাত অবাধ্য "// ইনক্রিমেন্ট এক্স বাই 1" মন্তব্যগুলিকে নিষিদ্ধ করে।

— হ্যান্স-পিটার স্টার

Answer 3

আমি সম্মত হব না এটি একটি খুব ভাল পদ্ধতির, মূলত কারণে

1. আপনি যখন আপনার প্রকল্পটি রিফ্যাক্টর করেন, তখন পদ্ধতিগুলি সরান, ডকুমেন্টেশন ভঙ্গ হয়।

2. যদি ডকুমেন্টেশন সঠিকভাবে আপডেট না হয় তবে কোড বোঝার ক্ষেত্রে সাহায্যের চেয়ে আরও বিভ্রান্তির সৃষ্টি হবে।

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

হ্যাঁ, একটি সঠিক ডিরেক্টরি কাঠামো থাকা অবশ্যই সাহায্য করবে।

Comments

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

— বিজেঙ্ক

Answer 4

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

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

Comments

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

— মাইকেল ডুরান্ট

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

— জ্বলছে

@ জওয়েন্টিং: আপনাকে এটি এতদূর নিতে হবে না। তবে আপনি কী নির্মাণ করছেন তা সম্পর্কে কিছু ধারণা থাকা এখনও ভাল ।

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

এটি কীভাবে সঠিকভাবে ভেঙে দেওয়া যায় এবং নিয়মগুলি কোথায় ভাঙতে হবে তার সতর্কতা ছাড়াই আপনার খুব শীঘ্রই একটি ডকুমেন্ট রয়েছে যা পুরানো বা একটি মিলস্টোন রয়েছে। "সময় খায় এমন বেহমথ ডকুমেন্টোতে আমার একটি নতুন ক্লাস যুক্ত করা দরকার!"

— ডিফোর্ড

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

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

Answer 5

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

নকশা নথিতে অন্তর্ভুক্ত জিনিসগুলি হ'ল;

• অ্যাপ্লিকেশন আর্কিটেকচার
• লজিকাল কোড কাঠামো
• তথ্য প্রবাহিত হয়
• মূল নিদর্শন ব্যবহৃত এবং তাদের ব্যবহারের পিছনে অনুপ্রেরণা
• কোড উত্স কাঠামো
• কীভাবে এটি তৈরি করবেন (এটি অন্তর্নিহিত নির্ভরতা এবং শারীরিক কোড উত্স কাঠামোর অন্তর্দৃষ্টি দেয়)

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

• পূর্বশর্ত
• প্রভাব
• Invariants
• ব্যতিক্রম শর্ত (নিক্ষেপ)

Comments

+1 প্রতিটি শ্রেণীর বর্ণনা দেওয়ার চেয়ে আরও ভাল, যেহেতু এটি সামগ্রিক নকশার চেয়ে দ্রুতগতির হয়ে যায়।

— লোড

Answer 6

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

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

Comments

আমার নিয়ম যে মন্তব্য সম্পর্কে হওয়া উচিত কেন না কেমন । কোডটি কীভাবে বর্ণনা করে।

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

Answer 7

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

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

Answer 8

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

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

Answer 9

জটিল সিস্টেমগুলির জন্য এটি প্রতিটি ফাইলের নথি নয়, তবে তাদের মিথস্ক্রিয়া এবং শ্রেণিবিন্যাস, এবং কীভাবে প্রোগ্রামের কাঠামো এবং কেন why

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

Answer 10

এটি আংশিক হতে পারে কারণ একক প্রোগ্রামারকে এটি লেখা শক্ত, কারণ প্রতিটি ব্যক্তি তাদের প্রকল্পের কেবলমাত্র অংশটি বোঝে।

কখনও কখনও আপনি প্রকল্প ম্যানেজারের নোটগুলি থেকে এই তথ্যটি পেতে পারেন তবে আপনি যা পাবেন তা হ'ল তারা খুব শীঘ্রই এই ফর্ম্যাটে তাদের নোটগুলি আবার লিখতে পারবেন।

Comments

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

— slebetman

এটি প্রশ্নের উত্তর দেবে বলে মনে হচ্ছে না, যা প্রস্তাবিত ডকুমেন্টেশন স্টাইলটি কাজ করবে না বা করবে না এবং ডকুমেন্টেশন স্ট্যান্ডার্ডগুলির জন্যও যা খুঁজছিল।

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

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

— অরবিটে হালকা হওয়া রেস