ভিসিএস থেকে সরাসরি অপ্রয়োজনীয় ফাইলগুলি মুছে ফেলা না বরং পরিবর্তে প্রথমে মন্তব্যগুলি দিয়ে "মুছতে হবে" হিসাবে চিহ্নিত করা কি খারাপ অভ্যাস?


53

আমি জানতে চেয়েছিলাম যে সংস্করণ নিয়ন্ত্রণ থেকে মুছে ফেলার প্রয়োজনীয় উত্স ফাইলগুলির সাথে আমি যেভাবে व्यवहार করি সেটিকে অনুশীলন হিসাবে বিবেচনা করা যেতে পারে।

আমি সেই উদাহরণটির ভিত্তিতে আপনাকে এটি ব্যাখ্যা করতে চাই:

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

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

এখনই এগুলি মুছে ফেলার পরিবর্তে এটি করছেন কেন?

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

"হুম ... কেন এই ফাইলগুলি মুছে ফেলা হয়েছে? আমি আগে ভাল কাজ করেছি।" (প্রেসগুলি 'রিভার্ট' -> যে ছেলেটি তারপরে ফিরে গিয়েছিল তা পরবর্তী সপ্তাহগুলিতে চিরতরে চলে যায় বা উপলভ্য নয় এবং পরবর্তী অ্যাসিজনিকে আমার মতো ক্লান্তিপূর্ণভাবে সেই ফাইলগুলি সম্পর্কে কী তা খুঁজে বের করতে হবে)

কিন্তু আপনি কি খেয়াল করেন না যে এই ফাইলগুলি প্রতিশ্রুতিবদ্ধ বার্তাগুলিতে মোছা হয়েছে কেন?

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


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

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

13
"পরের বার যখন আমাকে সংস্করণ নিয়ন্ত্রণে প্রকল্পের কোনও কিছু প্রতিশ্রুতিবদ্ধ / চেক করতে হবে, আমি এসভিএন-> মুছুন" টিপুন "আপনি কি বলছেন যে আপনি এগুলি (সম্ভাব্য) সম্পূর্ণ সম্পর্কহীন প্রতিশ্রুতিতে মুছে ফেলছেন?
কেভিন

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

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

উত্তর:


110

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

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

"আমি যদি এই অব্যবহৃত ফাইলটি মুছতে পারি এবং তারপরে কারওর প্রয়োজন হয়?" কেউ জিজ্ঞাসা করতে পারে।

আপনি উত্স নিয়ন্ত্রণ ব্যবহার করছেন। পরিবর্তনটি প্রত্যাহার করুন, বা ফাইলটি মুছে ফেলা (যোগাযোগ) এর সাথে আরও ভাল কথা বলুন।

"আমি যদি মৃত ফাইলটি মুছি, তবে কেউ আবার এটি ব্যবহার শুরু করে এবং তারা পরিবর্তন করে?" অন্য কেউ জিজ্ঞাসা করতে পারে।

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

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

এটি অপসারণ করা উচিত, এটি মুছে ফেলুন। কোড বেস থেকে ফ্যাট কাটা।

যদি আপনি একটি "ওপসি" তৈরি করেন এবং আপনার আসলে ফাইলটির প্রয়োজন হয় তবে মনে রাখবেন যে আপনি উত্স নিয়ন্ত্রণ ব্যবহার করছেন যাতে আপনি ফাইলটি পুনরুদ্ধার করতে পারেন।

ভিনসেন্ট সাভার্ড এই প্রশ্নের মন্তব্যে বলেছেন:

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

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

যদি প্রতিশ্রুতিবদ্ধ বার্তাগুলি গল্প না বলে, তবে বিকাশকারীদের আরও ভাল প্রতিশ্রুতি বার্তা লিখতে হবে।

কোড মুছে ফেলা বা ফাইলগুলি মুছতে ভয় পাওয়া প্রক্রিয়াটির সাথে গভীর, পদ্ধতিগত সমস্যার সূচক:

  • সঠিক কোড পর্যালোচনার অভাব
  • উত্স নিয়ন্ত্রণ কীভাবে কাজ করে সে সম্পর্কে বোঝার অভাব
  • দলের যোগাযোগের অভাব
  • বিকাশকারীদের পক্ষ থেকে দুর্বল প্রতিশ্রুতি বার্তা

এগুলি সমাধান করার জন্য সমস্যাগুলি, তাই আপনি কোড বা ফাইলগুলি মুছলে আপনি কাঁচের ঘরে পাথর নিক্ষেপ করছেন বলে মনে করবেন না।


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

7
@ শ্যাশলি: একটি বিকাশকারী কাজ খুব কমই কোনও মন্তব্য পরিবর্তন করতে পারে। কার্যগুলিতে কোড পরিবর্তন করা জড়িত, যা বিকাশকারী ফোকাস করে - মন্তব্যগুলি নয়।
গ্রেগ বার্গার্ট

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

5
@ শ্যাশলি - উদাহরণ হিসাবে আমি সাধারণত কোনও স্থানে ফাইলগুলি খুলি। ভিএস-তে আমি শীর্ষে ড্রপডাউনগুলি ব্যবহার করে সরাসরি "পদ্ধতিতে খুলতে পারি বা" সংজ্ঞায় যেতে পারি "প্রসঙ্গ মেনুতে। আমি কখনও ফাইলের শীর্ষ দেখতে পাব না। এছাড়াও সাব্লাইম পাঠ্যে আমি প্রায়শই একটি লাইনে খোলাম তাদের ওপেন ডায়ালগ ব্যবহারকারীগণ.আরবি: 123 ব্যবহারকারীগণকে ডায়াল করে সরাসরি 123 লাইনটিতে খুলবে Many অনেক কোড সম্পাদকের খুব অনুরূপ বিকল্প রয়েছে।
কোটায়ার

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

105

হ্যাঁ এটা খারাপ অভ্যাস।

আপনি ফাইলগুলি মুছে ফেলার সময় প্রতিশ্রুতিবদ্ধ বার্তায় মুছে ফেলার ব্যাখ্যাটি রাখা উচিত।

উত্স ফাইলে থাকা মন্তব্যে কোডটি বর্তমানে যেমনটি দেখাচ্ছে তেমন ব্যাখ্যা করা উচিত । কমিটের বার্তাগুলিতে ব্যাখ্যা করা উচিত যে প্রতিশ্রুতি পরিবর্তনগুলি কেন করা হয়েছিল, সুতরাং ফাইলটিতে কমিটের ইতিহাস তার ইতিহাস ব্যাখ্যা করে।

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


6
সম্ভবত এই প্রশ্নের উত্তর যুক্ত করুন: এটি কি খারাপ অভ্যাস? হ্যাঁ, কারণ ....
হুয়ান কার্লোস কটো

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

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

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

4
@ অ্যান্ড্রুস্যাভিনিখ হ্যাঁ, এবং এটি এইরকম নয় যে আমি এই সমস্যাগুলিও अनुभव করি নি - প্রকল্পগুলি যাঁর রক্ষণাবেক্ষণকারীরা সত্যই সংস্করণ নিয়ন্ত্রণের সাথে কাজ করেন নি এবং মন্তব্যগুলিতে প্রচুর তথ্য রাখে যা সত্যই বার্তাগুলি করা উচিত ছিল, পরিবর্তে নতুন ম্যানুয়াল-পূর্বাবস্থায় যোগ করেছে সঠিকভাবে প্রত্যাবর্তন, ইত্যাদি .. যে বৃহত্তর রি-বেসের ফলে সংঘাতের অনেক মজা জন্য তৈরি সংগ্রহস্থলের ফলে রাষ্ট্র ... কিন্তু, এবং যে আমার পয়েন্ট আছে, এই সমস্যার প্রায়ই মূলত হয় সৃষ্ট এক তুমি এখানে রক্ষার মত সমাধান নীচে উপস্থিত দ্বারা।
21

15

আমার মতে উভয় আপনার অপশন রয়েছে সেরা অনুশীলনের না , হিসাবে খারাপ উল্টোদিকে , অনুশীলন:

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

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

  1. একটি মন্তব্য যুক্ত করুন যে এটি মুছে ফেলার প্রার্থী এবং অবমূল্যায়ন #warning বা অনুরূপ, (বেশিরভাগ ভাষায় এই জাতীয় পদ্ধতি রয়েছে যেমন, জাভাতে , সবচেয়ে খারাপ ক্ষেত্রে একটি printবিবৃতি বা অনুরূপ যথেষ্ট হবে), আদর্শভাবে কিছু ধরণের টাইমস্কেল সহ এবং যোগাযোগের বিশদ সহ। এটি এখনও কোডটি ব্যবহার করছে এমন যে কাউকে সতর্ক করবে । এই সতর্কতাগুলি সাধারণত প্রতিটি ফাংশন বা শ্রেণীর ভিতরে থাকে যদি এই ধরণের জিনিস বিদ্যমান থাকে
  2. কিছুক্ষণ পরে সতর্কতাটিকে একটি স্ট্যান্ডার্ড ফাইল স্কোপে আপগ্রেড করুন #warning(কিছু লোক অবনতি সতর্কতাগুলি উপেক্ষা করে এবং কিছু সরঞ্জাম চেনগুলি ডিফল্টরূপে এই ধরনের সতর্কতা প্রদর্শন করে না)
  3. পরে ফাইল স্কোপটিকে #warningএকটি #errorবা সমমানের সাথে প্রতিস্থাপন করুন - এটি বিল্ড সময় কোডটি ভেঙে ফেলবে তবে একেবারে প্রয়োজন হলে অপসারণ করা যেতে পারে তবে যে ব্যক্তি এটি অপসারণ করছে এটি এটিকে উপেক্ষা করতে পারে না। (কিছু বিকাশকারী কোনও সতর্কতা পড়েন না বা সম্বোধন করেন না বা এতো বেশি রয়েছে যে তারা গুরুত্বপূর্ণগুলি আলাদা করতে পারবেন না)।
  4. অবশেষে ভিসিএস-এ মুছে ফেলা হিসাবে ফাইল (গুলি), (নির্ধারিত তারিখে বা তার পরে) চিহ্নিত করুন।
  5. যদি কোনও সতর্কতা পর্যায়ে পুরো প্যাকেজ / লাইব্রেরি / ইত্যাদি মুছে ফেলা হয় তবে আমি কখন এবং কেন প্যাকেজটি থেকে মুক্তি পাওয়ার পরিকল্পনা করে এবং কেবলমাত্র সেই ফাইলটি রেখে যাচ্ছি তার একটি তথ্যের সাথে একটি README.txt বা README.html যুক্ত করব a যখন মুছে ফেলা হয়েছে তখনই পরিবর্তনটি বলুন, বাকী সামগ্রীটি মুছে ফেলার পরে কিছু সময়ের জন্য প্যাকেজের একমাত্র সামগ্রী হিসাবে।

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

নোট করুন #warning/ / #errorএটি একটি সি / সি ++ মেকানিজম যা প্রদত্ত পাঠ্যের পরে একটি সতর্কতা / ত্রুটি সৃষ্টি করে যখন সংকলকটির কোডটির সাথে মুখোমুখি হয়, জাভা / জাভা-ডক @Deprecatedব্যবহারের বিষয়ে সতর্কতা জারি করার জন্য @deprecatedকিছু বিবরণ দেওয়া হয় এবং এখানে কিছু তথ্য সরবরাহ করা হয়। পাইথন ও একই রকম করার রেসিপিগুলি আমি বাস্তব বিশ্বে assertএকইরকম তথ্য সরবরাহ করতে ব্যবহার করতে দেখেছি #error


7
বিশেষত, যেহেতু এই প্রশ্নটিতে জাভার উল্লেখ রয়েছে, তাই @deprecatedজাভাডোক মন্তব্য এবং @Deprecatedটীকাটি ব্যবহার করুন ।
200_সাক্সেস

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

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

1
@ 200_সুকস ধন্যবাদ - আমার / সি / সি ++ এর পটভূমি - উত্তরে যুক্ত হয়েছে।
স্টিভ বার্নস

1
@ স্টিভবার্নস সম্ভবত কিন্তু ওপি যা জিজ্ঞাসা করছে তা নয়। তিনি যাচাই করেছেন যে কোডটি মারা গেছে।
অ্যান্ডি

3

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

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

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

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


1

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

সুতরাং (একটি সি ++ প্রকল্পে) আমি যুক্ত করেছি

#error this is not as dead as I thought it was

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

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


-1

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

তবে এই কোডটি বেশি দিন বেঁচে থাকা উচিত নয়। আমি পরবর্তী স্প্রিন্টের শুরুতে মুছে ফেলি।

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


এই কিছু সারগর্ভ প্রস্তাব উপর পয়েন্ট হয়েছে এবং পূর্বে 6 উত্তর ব্যাখ্যা বলে মনে হচ্ছে না
মশা

-3

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

  • পদক্ষেপ 1: শ্রেণীর নাম পরিবর্তন করুন, আপনার মন্তব্য যুক্ত করুন, প্রতিশ্রুতিবদ্ধ
  • পদক্ষেপ 2: ফাইল মুছুন এবং প্রতিশ্রুতিবদ্ধ

যদি এটি ডেড কোড হয় তবে এটি মুছুন। যে কারও এটির প্রয়োজন আছে, তারা ফিরে যেতে পারে, তবে পুনরায় নামকরণের পদক্ষেপটি এটিকে সরাসরি চিন্তা না করে এটিকে ব্যবহার করতে বাধা দেবে।

লোকেরা কীভাবে কোনও ফাইলের জন্য সমস্ত প্রতিশ্রুতিবদ্ধ বার্তাগুলি সন্ধান করবেন তা শেখান, কিছু লোক এমনকি জানেন না যে এটি সম্ভব।


6
"রিফ্যাক্টরিং" এর অর্থ আসলে যা হয় তা বোঝায় না
নিক কিরিয়াকাইডস

6
শ্রেণি / পদ্ধতির অপব্যবহার নিশ্চিত করার জন্য পুনরায় নামকরণ করার দরকার নেই, এটি মুছে ফেলা ঠিক একইভাবে কাজ করে। পরিবর্তে পদ্ধতিটি অন্য যে কোনও পরিবর্তনের মতোই: 1) মৃত কোডটি মুছুন , ২) পরীক্ষা চালান , ৩) যদি তারা পাস করেন তবে ভাষ্য দিয়ে কমিট করুন
শোওয়ার্ন

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

@ ব্রুডারলাস্টিগ: ভাল সফ্টওয়্যার অবশ্যই তা করবে না। গিট আছে git mv, যা ইতিহাস ট্র্যাক করে। বুধবার একইভাবে আছে hg mvদেখে মনে হচ্ছে svn moveএসভিএন এর জন্যও কাজ করা উচিত?
wchargin

@wchargin No, git mvকেবল ফাইলটি সরানো এবং একটি ফাইল মুছে ফেলা এবং একটি ফাইল তৈরির কাজ করে। সমস্ত চালনা ট্র্যাকিং ঘটে যখন আপনি চালাবেন git log --followএবং অনুরূপ। gitনতুন নামগুলি ট্র্যাক করার কোনও উপায় নেই, এটি আসলে কোনও পরিবর্তনকেই ট্র্যাক করে না ; পরিবর্তে প্রতিশ্রুতিবদ্ধ হওয়ার সময় এটি রাজ্যগুলি ট্র্যাক করে এবং আপনি ইতিহাসটি পরিদর্শন করার সময় কী পরিবর্তন হয়েছিল তা সন্ধান করে।
মার্টিনাস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.