উত্স ফাইলটির শুরুতে একটি মন্তব্যে বাগ নম্বরগুলি রাখা ভাল ধারণা? [বন্ধ]

40

একটি হেডার মন্তব্যের ভিতরেই ফাইলটিতে বাগ নম্বরগুলি রাখা ভাল অনুশীলন?

মন্তব্যগুলি দেখতে এরকম কিছু হবে:

 MODIFIED    (MM/DD/YY)
 abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode

 cde 01/17/14 - Bug 2314558  - some other error description

এটি সহায়ক বলে মনে হচ্ছে, তবে এটি কি খারাপ অভ্যাস হিসাবে বিবেচিত?

— গীক
সূত্র

23

আমি যে প্রশ্নটি জিজ্ঞাসা করব তা হ'ল "এম্বেড থাকা বাগ নম্বরগুলি আপনি কী করতে পারবেন যা আপনি ইতিমধ্যে আপনার বাগ ডাটাবেসের সাথে করতে পারবেন না?" আমি কোনও আসল ব্যবহারের ক্ষেত্রে ভাবতে পারি না।

— এম ডুডলি

2

সম্পর্কিত: স্ট্যাকওভারফ্লো.com

— ব্রায়ান

6

@ জেনসিজ এজন্য আপনি এটি প্রতিশ্রুতি বার্তায় রেখেছেন এবং logফাইলটিতে একটি আপনাকে ঠিক একই জিনিস দেবে, তবে ফাইলটি

— বিশৃঙ্খলা

1

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

— ডিএমকেকে

3

এই প্রশ্নটি আরস টেকনিকা নিবন্ধের বিষয়বস্তু কি আমাদের কোনও উত্স ফাইলের শিরোনামে বাগগুলি তালিকাভুক্ত করা উচিত? (এই প্রশ্ন পোস্ট হওয়ার 15 দিন পরে প্রকাশিত)।

— পিটার মর্টেনসেন

107

আমি এটি আগে দেখেছি উভয়ই ম্যানুয়ালি লেখক দ্বারা এবং স্বয়ংক্রিয়ভাবে স্ক্রিপ্ট দ্বারা এবং ট্রিগারকে সংস্করণ নিয়ন্ত্রণ সিস্টেমের সাথে সংহত করে লেখক, চেক-ইন মন্তব্য এবং ফাইলে তারিখের তথ্য যুক্ত করতে।

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

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

— টমাস ওভেনস
সূত্র

2

"এবং আপনি যদি এমন একটি আধুনিক সংস্করণ নিয়ন্ত্রণ ব্যবস্থা ব্যবহার করছেন যা পরিবর্তন-সেটগুলি সমর্থন করে, তবে এটি আসলে পরিবর্তনের তথ্য হারাবে" " - আপনি দয়া করে বিস্তারিত বলতে পারেন?

— গীক

10

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

— টমাস ওয়ানস

9

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

— 26

2

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

— ক্রুঙ্কার

@ 17of26 - আমি "পুরানো ইস্যু ট্র্যাকার বাগ 1234" এর মত মন্তব্য ব্যতীত অন্য কোনও প্রক্রিয়া না করে আপনি যদি পুরনো বাগ / ইস্যুগুলিকে নতুনগুলির সাথে লিঙ্ক করতে পারতেন তবে আমি ভাবতে পারি।

— কেনি এভিট

42

ঠিক foo()এটির একটি ক্ষেত্রে আমি এটি করব, যথা ভবিষ্যতের প্রোগ্রামারদের জন্য একটি সতর্কতার অংশ হিসাবে: " এখানে সরাসরি ফাংশনটি কল করবেন না ; এর ফলে বাগ # 1234 হয়েছে, নাম ..." এবং তারপরে একটি সংক্ষিপ্ত বিবরণ বাগ অনুসরণ।

এবং কোডটি যদি এমনভাবে পরিবর্তিত হয় যে foo()সরাসরি কল করার কোনও প্রলোভন নেই , তবে সেই মন্তব্যটি সরিয়ে দিন। এটি কেবল বিরক্ত হবে এবং কোডটি ফুটিয়ে তুলবে।

— REM
সূত্র

19

হয়তো আমি কিছুটা হার্ডস, তবে যদি foo()সরাসরি কল না করা হয়, তবে কোডটি এমনভাবে গঠন করা উচিত যাতে এটি না হয়।

— মেটাফাইট

20

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

— রিম

16

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

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

— কিলিয়ান ফথ
সূত্র

আপনি মনে করেন ঠিক কতগুলি বাগ একটি ফাইলে সম্ভব এবং যদি এমন অনেকগুলি থাকে তবে এটি সম্ভবত পুনর্লিখনের জন্য সময়।

— অ্যান্ডি

11

না।

সংস্করণ নিয়ন্ত্রণ ব্যবস্থা ব্যবহার করার আগে লোকেরা এটি করেছিল (যেমন উত্স কোডটি যখন জিপফাইলে কেবল ব্যাকআপ ছিল)।

— নীল বার্নওয়েল
সূত্র

2

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

— jwenting

1

@ জ্বলন্ত আমি এই সাইটে খুব দুর্ভাগ্যজনক লোকদের পক্ষ থেকে প্রশ্নগুলি দেখেছি যেগুলি বর্তমানে এমন দোকানে ব্যবহৃত হতে পারে যেখানে বর্তমানে প্রচলিত অনুশীলন রয়েছে :-(

— কারসন 000৩০০০

আমরা একটি দুর্দান্ত উত্স নিয়ন্ত্রণ ব্যবস্থা ব্যবহার করি। কোডটি চেক করার সময় আমার ছাড়া আর কেউ মন্তব্য করেন না। <શ્રু> আমি কিছু জিনিস মন্তব্য করি (যেমন পিএলএসকিউএল যা সর্বদা এসসিএম দ্বারা ট্র্যাক হয় না)। আমি আমার কোডটি ব্যাখ্যা করার জন্য মন্তব্য করি, তবে এটি কখনই নির্দিষ্ট বাগগুলিতে আবার বেঁধে রাখি না, তবে আমি যখনই চেক ইন করি তখন আমি সবসময় এসসিএম-তে থাকা বাগ মন্তব্যগুলিতে মন্তব্য করি। আশা করি অবশেষে কেউ এটির প্রশংসা করবে will

— পেডেন্টিক

11

এটি, আইএমএইচও, খুব খারাপ ধারণা। 100 নম্বর সংশোধনীর পরে, আপনার 90% মন্তব্য এবং 10% কোড থাকবে। আমি এটিকে পরিষ্কার এবং পাঠযোগ্য হিসাবে বিবেচনা করব না।

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

— ডক ব্রাউন
সূত্র

8

আমি দেখতে পাচ্ছি যে সবাই এই ধারণার বিরোধী এবং কেন লোকেরা এটি করছে তার একটি historicalতিহাসিক কারণ (প্রাক উত্স নিয়ন্ত্রণের যুগ) দিয়েছে।

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

হ্যাঁ, এটি কোডকে বিশৃঙ্খলা করে, তবে কোডটির টুকরোটি কেন রয়েছে তা কারণ খুঁজে পেতে এটি সহায়তা করে।

— পারভেজ
সূত্র

3

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

— JensG

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

— ডেভিড কনরাড

চিন্তা, সিদ্ধান্ত, ক্লিক, ক্লিক, ক্লিক, স্ক্রোল। সে কারণেই আমি বলেছি "কোডে ক্যাশিং"। যদি এটি সেখানে থাকে তবে আমি এটি দেখতে পাচ্ছি।

— JensG

2

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

— জেফ্রি হ্যান্টিন

7

পয়েন্ট এক জোএল পরীক্ষা হয়

আপনার কি কোনও বাগ ডাটাবেস আছে?

এই জাতীয় তথ্য যদি আপনার গুরুত্বপূর্ণ মনে হয় তবে এটি একটি বাগের ডাটাবেজে রাখা যেতে পারে তবে তারা কেবল মন্তব্যেই শব্দ করবে।

— পিয়ের আরলাড
সূত্র

1

প্রশ্নের উদাহরণটি দেখুন - মন্তব্যগুলি বাগের ডাটাবেসটিকে উল্লেখ করবে ...

— ইজকাটা

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

— পিয়ের আরলাড

6

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

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

একবার আপনি এটি প্রয়োগে নিলে, অভ্যাসগুলি তৈরি করা কোড বেসকে সবার জন্য কাজ করা সহজ করে তোলে।

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

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

— জেফও
সূত্র

2

আপনার কাছে যদি কমিটমেন্ট বার্তাগুলি সহ কোনও ভিসিএস না থাকে এবং আপনার মন্তব্য দেওয়ার কোনও বিকল্প সহ কোনও বাগ ট্র্যাকিং সিস্টেম না থাকে তবে পরিবর্তনের উপর নজর রাখার জন্য এটি একটি বিকল্প এবং সর্বোত্তম নয়।
সেই তথ্য সহ একটি স্প্রেডশিট থাকা ভাল, বা যদি আপনি এই জাতীয় "বিলাসিতা" ছাড়াই কোনও পরিবেশে থাকেন তবে আপনার উত্সের কাছে কোথাও বসে একটি পাঠ্য ফাইল।
তবে আমি দৃ strongly়ভাবে সুপারিশ করব যদি আপনি ভিসিএস এবং বাগ ট্র্যাকিং সিস্টেমে বিনিয়োগের জন্য কেস তৈরি করা শুরু করেন তবে আপনি যদি এমন পরিবেশে থাকেন তবে :)

— jwenting
সূত্র

2

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

আমি সম্মত না হওয়ার পরেও ফাইল বিশৃঙ্খলা বিরক্তিকর, একটি ফাইল খোলার এবং সরঞ্জামগুলি ব্যবহার না করেই এর ইতিহাস বোঝা সর্বদা খুব সহায়ক ছিল - বিশেষত যদি আমি কোডটি বজায় রাখি।

ব্যক্তিগতভাবে, আমি মনে করি সরঞ্জাম এবং ইন-কোড লগ উভয়ের জন্যই জায়গা রয়েছে।

— GGB
সূত্র

2

আমি জানি গীত এই কাজ করে না এবং সহজ উত্তর হল "কেন পৃথিবীতে হবে এটা সেখানে যেতে?"

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

কোনও ফাইলের যে কোনও গ্রাহককে প্রথমে সংস্করণ নিয়ন্ত্রণ সিস্টেমের মাধ্যমে এটি প্রক্রিয়া করা প্রয়োজন। এটি দৃ tight় মিলন, উদাহরণস্বরূপ আপনার ভিসিএস সমর্থন না করে যদি আপনার প্রিয় আইডিই ভেঙে যায়।

— জেচলিন
সূত্র

2

না, কোডটিতে মন্তব্য হিসাবে আপনার বাগ ফিক্সগুলি ট্র্যাক করা ভাল অভ্যাস নয়। এটি কেবল বিশৃঙ্খলা সৃষ্টি করে।

আপনি উল্লিখিত কপিরাইট বার্তাগুলির জন্যও আমি একই বলব। যদি আপনার সংস্থার বাইরে কেউ এই কোডটি দেখতে না পান তবে কোনও কপিরাইট বার্তা অন্তর্ভুক্ত করার কোনও কারণ নেই।

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

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

— ব্রায়ান
সূত্র

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

— বারেন্ড জেন্ড্রিসেক

1

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

একটি ভাগ করা কোড বেসের সাথে একটি টিম পরিবেশে এবং যখন বেশ কয়েকটি টিম সদস্য সম্ভাব্যভাবে কোডের একই ক্ষেত্রে কাজ করছেন, তখন সঠিক সুযোগে (পদ্ধতি বা শ্রেণি) একটি সংক্ষিপ্ত সংশোধন মন্তব্য করা একটি পরিবর্তনকে নির্দেশ করে যা খুব কার্যকর হতে পারে for মার্জ বা চেকইন বিরোধগুলি দ্রুত সমাধান করা ol

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

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

— StingyJack
সূত্র

3

প্রশ্নটি কপিরাইট বার্তার ঠিক পরে সোর্স ফাইলের শুরুতে মন্তব্য সম্পর্কে

— gnat

এখানে সমস্ত উত্তর ঠিক সে সম্পর্কেই কথা বলছে। আমি যদি পুরো ক্লাসের ফাইলগুলিতে (পুনর্গঠন বা ফর্ম্যাটিং ফিক্সিং) উল্লেখযোগ্য পরিবর্তন করি তবে আমি কি ক্লাস ফাইলটিকে সুযোগ হিসাবে মন্তব্য করব না?

— স্টিংজি জ্যাক

0

কোডের একটি অংশের সাথে সরাসরি সম্পর্কিত যে কোনও বাগের তথ্য অপ্রাসঙ্গিক হয়ে ওঠে যখন পুরো পরিবর্তনটির অখণ্ডতা ক্রমাগত সংশোধন করে পরিবর্তিত হয়।

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

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

— ফিয়ামমেটা কাস্তালডি
সূত্র

0

আমি অবশ্যই ফাইলের শুরুতে এই জাতীয় তথ্য রাখব না - সাধারণত এই জাতীয় জিনিস টিকিট ব্যবস্থার অন্তর্ভুক্ত।

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

— এইচএসটিয়ার
সূত্র

এটি পূর্বের উত্তরগুলিতে ইতিমধ্যে পোস্ট করা হয়েছে যা এতে যথেষ্ট পরিমাণ যুক্ত হবে বলে মনে হয় না

— gnat

0

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

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

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

— ফ্রেড থমসন sen
সূত্র