কোডিং স্ট্যান্ডার্ড ডকুমেন্ট তৈরি করা হচ্ছে


15

আমি একটি নিয়ন্ত্রণ সিস্টেম সংস্থায় কাজ করি, যেখানে প্রাথমিক কাজটি এসসিএডিএ এবং পিএলসি এবং অন্যান্য নিয়ন্ত্রণ সিস্টেমের স্টাফ সহ।

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

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

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

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

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

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


2
আপনার কি ইতিমধ্যে বিস্তৃত পরীক্ষার কভারেজ রয়েছে? কোডটি যদি ভুল হয় তবে তা কত সুন্দর তা বিবেচনা করে না ...
জেবিআরউইলকিনসন

2
ভাল জিনিস হ'ল আমরা আমাদের স্টাফের মধ্য দিয়ে নিয়মিত পরীক্ষা করি, আমাদের প্রকল্পের জন্য আমাদের নিয়মিত ইউনিট টেস্টিং প্রয়োগ করা হয় এবং আমরা প্রকাশের আগে আমরা এলোমেলো হলওয়ে টেস্টিং ব্যবহার করব এবং কালো এবং সাদা বক্স পরীক্ষার জন্য একটি পরীক্ষার তালিকা লিখব।
ফেলিক্স ওয়েয়ার

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

এই বিষয়টিতে "ক্লাসিক" কাজ করে এমন কিছু সংস্থান রয়েছে। আমি আপনার দলের প্রয়োজন মেটাতে এমন নথি তৈরি করার জন্য এই মানগুলির সর্বোত্তম অংশ গ্রহণের পরামর্শ দিচ্ছি: ১. বেল ল্যাবস, ইন্ডিয়ান হিল সি স্টাইল এবং কোডিং স্ট্যান্ডার্ডস, ১৯ ফেব্রুয়ারী ১৯৯ 1997, মলটেক.com / ক্রিসলট / রিসোর্স / স্টাইল / ইন্ডিহ্ল-স্টাইল .পিডিএফ ২. স্টলম্যান, রিচার্ড, জিএনইউ কোডিং স্ট্যান্ডার্ডস, ৩০ জুন ২০১২, gnu.org/prep/standards/standards.html ৩. জেট প্রপালশন ল্যাবরেটরি, সিপি প্রোগ্রামিং ল্যাঙ্গুয়েজের জেপিএল ইনস্টিটিউশনাল কোডিং স্ট্যান্ডার্ড, সংস্করণ ১.০, ৩ মার্চ ২০০৯, lars-lab.jpl.nasa.gov/JPL_ কোডিং_ স্ট্যান্ডার্ড_
উইলিয়াম লায়ারা

উত্তর:


24

একটি ভাল কোডিং মান নথির মূল দিকগুলি এবং বিষয়বস্তুগুলি কী কী?

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

  2. হচ্ছে ভাল চিন্তা আউট, এর পরিবর্তে আপনার ব্যক্তিগত মতামত হচ্ছে । আপনি স্পষ্টভাবে বলবেন না: "এখন থেকে আমরা অঞ্চলগুলি আর ব্যবহার করি না, কারণ অঞ্চলগুলি আমি পছন্দ করি না।" বরং আপনি ব্যাখ্যা করবেন যে অঞ্চলগুলি কোড বৃদ্ধিতে উত্সাহ দেয় এবং কোনও বড় সমস্যা সমাধান করে না

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

  3. ভাল ডকুমেন্টেড হচ্ছে । ডকুমেন্টেশন অভাব বিভ্রান্তি এবং ব্যাখ্যা জন্য স্থান তৈরি করে ; বিভ্রান্তি এবং ব্যাখ্যার সম্ভাবনা শৈলীর পার্থক্যের দিকে পরিচালিত করে, অর্থাৎ জিনিসটির মানটি দমন করতে চায়।

  4. হচ্ছে ব্যাপক, যেমন আপনার কোম্পানি বাহিরে সহ । বিশ প্রোগ্রামারদের দ্বারা ব্যবহৃত একটি "স্ট্যান্ডার্ড" বিশ্বজুড়ে কয়েক হাজার বিকাশকারী দ্বারা পরিচিত একটি মানের চেয়ে কম স্ট্যান্ডার্ড।

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

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

  1. আপনার নিজের স্ট্যান্ডার্ডগুলির সাথে ফিট করার জন্য আপনার স্টাইলকপ বিধিগুলি পুনরায় লেখার দরকার নেই। আমি বলছি না যে আপনার নিজের নিয়মগুলি লেখা শক্ত, তবে আপনি যদি এটি করা এড়াতে পারেন তবে এর অর্থ আপনার পরিবর্তে দরকারী কিছু করার জন্য আরও বেশি সময় লাগবে।

  2. মাইক্রোসফ্ট এর গাইডলাইন খুব ভালভাবে চিন্তা করা হয়। এমন সম্ভাবনা রয়েছে যে আপনি যদি কারও কারও সাথে একমত নন তবে এটি হতে পারে কারণ আপনি তাদের বোঝেন নি। এটা ঠিক আমার ঘটনা ছিল; যখন আমি সি # বিকাশ শুরু করেছি, তখন আমি কয়েকটি নিয়ম সম্পূর্ণ বোবা পেয়েছি। এখন, আমি তাদের সাথে পুরোপুরি একমত, কারণ শেষ পর্যন্ত আমি বুঝতে পেরেছিলাম কেন তাদের এভাবে লেখা হয়েছিল।

  3. মাইক্রোসফ্টের নির্দেশিকা ভাল ডকুমেন্টেড, সুতরাং আপনার নিজের ডকুমেন্টেশন লিখতে হবে না।

  4. পরে আপনার সংস্থায় নিয়োগ করা হবে এমন নতুন বিকাশকারীরা মাইক্রোসফের কোডিং মানগুলির সাথে ইতিমধ্যে পরিচিত হতে পারেন। এমন কিছু সম্ভাবনা রয়েছে যে কেউ আপনার অভ্যন্তরীণ কোডিং শৈলীর সাথে পরিচিত হবে না।


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

বিটিডাব্লু, আপনি "সরঞ্জামগুলি যা স্বয়ংক্রিয় চেকিং সক্ষম করে" উল্লেখ করেন, কোনটি সরঞ্জামগুলি? আমি আগ্রহী.
ফেলিক্স ওয়েয়ার

@ ফেলিক্সওয়ের: নেট ফ্রেমওয়ার্কের জন্য? StyleCop।
আর্সেনী মোরজেনকো

ওহ ঠিক, আমি ভেবেছিলাম আপনি অন্য কিছুতে ইঙ্গিত দিচ্ছেন। আমরা স্টাইলোকপ ব্যবহার করি ...: ^)
ফেলিক্স ওয়েয়ার

1
@ ফেলিক্সওয়ের: এছাড়াও, কোড বিশ্লেষণ চেষ্টা করুন (যদি আপনি এটি ইতিমধ্যে না করে থাকেন)। উদ্দেশ্যটি পৃথক এবং শৈলীর সাথে সম্পর্কিত নয় তবে এটি মানকতাও সক্ষম করে।
আর্সেনী মোরজেনকো

8

প্রথম গুরুত্বপূর্ণ জিনিসটি লক্ষণীয়: কোডিং মানদণ্ডের নথিটি সঠিক এবং ভুল সম্পর্কে নয়। এটি ভাল মন্দ সম্পর্কে নয় বা কোন পদ্ধতিটি ভাল।

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

এগুলি সবই অভিন্নতার, এবং "সঠিক এবং ভুল" সম্পর্কে কিছুই নয়

এই বিষয়টিকে সামনে রেখে কোডিং স্ট্যান্ডার্ড নথিতে আপনার কয়েকটি বিষয় পরিষ্কার করা উচিত:

নামকরণ অনুষ্ঠান

আপনি কীভাবে আপনার পদ্ধতি, ভেরিয়েবল, ক্লাস এবং ইন্টারফেসের নাম রাখবেন? আপনি কোন স্বরলিপি ব্যবহার করবেন?

এছাড়াও আমাদের স্ট্যান্ডার্ডের অন্তর্ভুক্ত অন্য কিছু হ'ল এসকিউএল-র জন্য পৃথকীকরণের মান standards

খাঁজ

আপনি ইন্ডেন্টেশন জন্য কী ব্যবহার করবেন? একক ট্যাব? 3 স্পেস?

বিন্যাস

ব্রেসেসগুলি কি খোলার পদ্ধতি লাইনের মতো একই লাইনে রাখা হবে? (সাধারণত জাভা) না পরের লাইনে নাকি নিজস্ব লাইনের? (সাধারণত সি #)

ব্যতিক্রম হ্যান্ডলিং / লগিং

ব্যতিক্রম হ্যান্ডলিং এবং লগিংয়ের জন্য আপনার মানকগুলি কী, এটি কি সমস্ত বাড়িতেই জন্মেছে বা আপনি কোনও তৃতীয় পক্ষের সরঞ্জাম ব্যবহার করছেন? এটি কীভাবে ব্যবহার করা উচিত?

মন্তব্য

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

বর্ণনার জন্য পদ্ধতি সম্পর্কে কীভাবে? এগুলি কি ব্যবহার করা যায়? কখন?

প্রকাশ

আপনার সমস্ত পদ্ধতি এবং ক্ষেত্রগুলি কী সর্বনিম্ন স্তরের অ্যাক্সেসের সম্ভাব্য প্রয়োগ করা উচিত?

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

আমি সবেমাত্র এই নথির কোনওটিতে যা যেতে পারে তার পৃষ্ঠটি স্ক্র্যাচ করেছি, তবে কেআইএসএস

এটি দীর্ঘ, এবং বিরক্তিকর এবং অতিক্রম করা অসম্ভব হয়ে উঠবেন না বা এই মানগুলি কেবল অনুসরণ করা হবে না, এটি সহজ রাখুন।


1
কোডিং মানগুলি প্রায়শই, বিশেষত সি / সি ++ বিকাশের জন্যও একটি (বৃহত্তর) বিভাগ থাকে যা কোন ভাষাটি আপনাকে ব্যবহার না করা উচিত এবং কেন ব্যবহার করা উচিত সে সম্পর্কে ।
বার্ট ভ্যান ইনজেন শেহেনো

2
@ বার্টওয়ানইঞ্জেনচেনাউ আপনার সি ++ এর জন্য প্রয়োজন কেন বা অন্য ভাষার জন্য আপনার একই ধরণের বিভাগের দরকার নেই তার কোনও কারণ নেই - আপনি সি # বা জেএস বা .. ভাল কিছুতেই গোলমাল করতে পারেন। সমস্ত ভাষায় 'এমন বৈশিষ্ট্য রয়েছে যা অপব্যবহার করা যায়'। মিনি টিউটোরিয়ালগুলি "কীভাবে কোড করবেন না" তার সাথে স্ট্যান্ডার্ড ডকুমেন্টটি পূরণ করার পরিবর্তে আপনার ডেভসকে তাদের কাজটিতে ভাল হতে প্রশিক্ষণ দেওয়া সেরা।
gbjbaanb

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

1
@ বার্টওয়ানজেঞ্জেনচেনা আমার মনে হয় যে কোডিং গাইডলাইনস ডকুমেন্টে কোনও কোডিং স্ট্যান্ডার্ড ডকুমেন্ট নয় বরং আরও ভালভাবে স্থাপন করা যেতে পারে
রাইসডাব্লু

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

6

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

উদাহরণস্বরূপ, আমি এটি সবেমাত্র খুঁজে পেয়েছি: http://www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

যাইহোক, আপনার শিখা-নিক্ষেপকারী হাত রাখুন।

চিয়ার্স,


2
+1 আমি একই কথা বলতে যাচ্ছিলাম। কোডিং স্ট্যান্ডার্ড ডকুমেন্ট তৈরি করা একটি বিশাল কাজ যা আগেও হয়ে গেছে। একটি ভাল সন্ধান করুন, তারপরে কাস্টমাইজ করতে সংশোধন করুন।
জন ম্যাকআইন্টির

4

আমি বেশিরভাগ মানের নথিকে ঘৃণা করি কারণ তারা সাধারণত ছোট জিনিসগুলি ঘামে এবং বড় চিত্রটিকে উপেক্ষা করার চেষ্টা করে।

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

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

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

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

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

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


2

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

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