যেগুলি সংশোধন নিয়ন্ত্রণ ব্যবহার করে এমন দোকানে ইনলাইন মন্তব্যগুলি 'সম্পাদিত' হয়?

Question

আমাদের দোকানের প্রবীণ দেব জোর দিয়ে বলেছেন যে যখনই কোডটি সংশোধন করা হচ্ছে তখন দায়বদ্ধ প্রোগ্রামারকে তার কাজটি জানিয়ে একটি ইনলাইন মন্তব্য যুক্ত করা উচিত। এই মন্তব্যগুলি সাধারণত মত দেখাচ্ছে// YYYY-MM-DD <User ID> Added this IF block per bug 1234.

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

অন্যান্য দোকানে কি এটি স্ট্যান্ডার্ড (বা কমপক্ষে সাধারণ) অনুশীলন?

Comments

আমি আপনার সাথে একমত হব, সংস্করণ নিয়ন্ত্রণে রিভিশন লগগুলি এটাই।

— TZHX

সংস্করণ নিয়ন্ত্রণ বিস্তৃত হওয়ার আগেই আপনার দলের সিনিয়র দেব এটি করেছিলেন এবং কোড গন্ধ অপসারণ করার জন্য এটি অন্য কোথাও অন্তর্ভুক্ত বলে উপলব্ধি করতে পারেননি। তাকে ছয়টি ওপেন-সোর্স প্রকল্প দেখান যা বাগজিলা এবং ভিসি সিস্টেম ব্যবহার করে, তাকে জিজ্ঞাসা করুন যে জিকারি লাইব্রেরির মন্তব্যে জানতে হবে যে $ .ajax () সম্প্রতি জবাবার্গ দ্বারা 4 মাস আগে পরিবর্তিত হয়েছিল এবং সমস্ত ছোটখাট পরিবর্তন হয়েছে শত শত লোকের দ্বারা নির্মিত সেখানেও রয়েছে। পুরো jQuery লাইব্রেরি মন্তব্যগুলির গোলমাল হবে, এবং কিছুই অর্জন করা হয়নি!

— ছদ্ম

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

— স্টিফেন পলগার

Answer 1

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

তবে আমি এখনও প্রায়শই নির্দিষ্ট ধরণের সম্পাদনার জন্য এ জাতীয় কিছু করি।

কেস 1 - টাস্ক

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

আমি সময়ে সময়ে কোড পর্যালোচনা করার সময় নীচের মতো কিছু যুক্ত করব:

// TOREVIEW: [2010-12-09 haylem] marking this for review because blablabla

বা:

// FIXME: [2010-12-09 haylem] marking this for review because blablabla

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

কেস 2 - তৃতীয় পক্ষের পাবলিক প্যাচগুলি

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

// [PATCH_START:product_name]
//  ... real code here ...
// [PATCH_END:product_name]

কেস 3 - অ-সুস্পষ্ট সমাধান

এটি আপনার প্রবীণ দেব যা চাইছে তার থেকে এটি খানিকটা বিতর্কিত এবং নিকটে।

এই মুহুর্তে আমি যে পণ্যটিতে কাজ করি তাতে আমাদের মাঝে মাঝে (অবশ্যই একটি সাধারণ জিনিস নয়) মতামত থাকে:

// BUGFIX: [2010-12-09 haylem] fix for BUG_ID-XYZ

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

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

---

এটি ঠিক এখানে: একটি বাস্তব জীবনের উদাহরণ

কিছু ক্ষেত্রে, এটি কিছুই চেয়ে ভাল :)

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

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

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

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

Comments

এই পরিস্থিতিগুলি বোঝা যায়। ইনপুট জন্য ধন্যবাদ।

— জোশুয়া স্মিথ

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

— সালানদুর

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

— টিম উইলিসক্রফ্ট

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

— হাইলেম

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

— 11'30

Answer 2

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

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

Comments

আমি সম্মত, সংস্করণ নিয়ন্ত্রণে থাকা ফাইলগুলি আলাদা গল্প।

— জোশুয়া স্মিথ

"এগুলি ব্যাক আপ করার চেয়ে অনেক বেশি কিছু করা কঠিন প্রমাণিত।" সত্যিই কোন অজুহাত নয় যে আমার সিটিও পেট করবে।

— টিম উইলিসক্রফ্ট

@ টিম: সর্বদা পরামর্শের জন্য উন্মুক্ত - আমি তাদের কমান্ডের চেইন আপ করতে পারি। :) ফাইল বন্ধ এবং চালু করতে মেনফ্রেমে কাজ করা শক্ত।

— মাইকেল কে

আমার পরামর্শ - সম্ভবত আপনি এগুলি বন্ধ করতে পারেন (ব্যাকআপ); কেন কেবল যে কোথাও ফেলে দেওয়া হয়নি এবং প্রতি রাতে পার্কে সামান্য স্ক্রিপ্ট পরিবর্তন করা আছে?

— ওয়াইয়াট বার্নেট

Answer 3

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

ভাগ্যক্রমে, তখন থেকে আমার পরিচালকরা সংস্করণ নিয়ন্ত্রণ সিস্টেমগুলি কী করতে পারে সে সম্পর্কে আরও জ্ঞাত ছিল (আমাকে যুক্ত করতে হবে যে আমরা সেই প্রথম দোকানে সোর্সসেফ ব্যবহার করেছি)। সুতরাং আমি কোডে সংস্করণ मेटाটাটা যুক্ত করি না।

Answer 4

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

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

Comments

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

— টিম উইলিসক্রফ্ট

Answer 5

স্পষ্টতই, এই জাতীয় কোনও মন্তব্য সময়ের সাথে প্রায় ভুল হওয়ার গ্যারান্টিযুক্ত; আপনি যদি দুবার একটি লাইন সম্পাদনা করেন তবে আপনি কি দুটি মন্তব্য যুক্ত করবেন? যেখানে তারা যেতে না? সুতরাং আপনার সরঞ্জামগুলির উপর নির্ভর করা আরও ভাল প্রক্রিয়া।

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

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

প্রয়োজনীয়তার জন্য তার কারণ না বুঝে আপনি তাকে বোঝাতে সক্ষম হবেন না।

Answer 6

আমি একটি 20+ বছরের পুরানো উইন্ডোজ পণ্য নিয়ে কাজ করি। আমাদের একটি অনুরূপ অনুশীলন রয়েছে যা দীর্ঘদিন ধরে ছিল। এই অনুশীলনটি আমার বেকনকে কতবার সংরক্ষণ করেছে তা আমি গণনা করতে পারি না।

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

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

ত্রুটিযুক্ত নম্বর সহ একটি মন্তব্য আমাকে কোডের উত্স সন্ধান করতে যাওয়ার জায়গা দেয়।

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

Answer 7

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

Answer 8

আমি তা বলতে পারি না।

আমি সাথে সাথে যাওয়ার সাথে সাথে আমার কোডগুলিতে টুডলগুলি ছড়িয়ে দিই এবং লক্ষ্যটি হ'ল পর্যালোচনার সময় এগুলি সরিয়ে দেওয়া।