"মন্তব্য করা" কোড চেক ইন করা [বন্ধ]


95

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

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

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

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

যাইহোক, আপনার চিন্তা কি? আপনি কি বিশ্বাস করেন যে "মন্তব্য করা" কোডটি সংগ্রহস্থলটিতে রাখতে কার্যকর?

আমি এই বিষয়ে অন্যের কাছ থেকে শুনতে আগ্রহী।

সম্পাদনা করুন: স্বচ্ছতার জন্য আমরা ব্যক্তিগত শাখা ব্যবহার করি না। যদি আমরা তা করি তবে আমি বলব যে আপনি নিজের ব্যক্তিগত শাখায় যা চান তা করুন তবে কখনও ট্রাঙ্ক বা কোনও ভাগ করা শাখার সাথে মন্তব্যযুক্ত কোডটি মার্জ করবেন না।

সম্পাদনা করুন: আমরা ব্যক্তিগত বা প্রতি ব্যবহারকারী শাখাগুলি ব্যবহার না করার কোনও বৈধ কারণ নেই। এটি এমন কোনও ধারণা নয় যার সাথে আমি একমত নই। আমরা এখনও এটি সেভাবে সেট আপ করি নি। সম্ভবত এটিই মধ্যম স্থল। আপাতত আমরা টিএফএস শেল্ভিং ব্যবহার করি।


4
আপনি আপনার বিকাশকারীদের টিএফএসের যথাযথ ব্যবহার সম্পর্কে সম্পূর্ণ প্রশিক্ষণ দিন তা নিশ্চিত করুন। আমার ওয়ার্কগ্রুপ টিএফএসের সাথে উল্লেখযোগ্য সমস্যা পেয়েছে এবং যার ফলে আমার কোড-লস হয়েছে। একটি "আইডি 10 টি" ত্রুটি হতে পারে তবে আমি এখনও টিএফএসকে বিশ্বাস করি না।
জেমস শেক 22

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

@ নাল - সম্পাদনায় উল্লিখিত হিসাবে, তাদের সাথে আমার কোনও সমস্যা নেই, আমরা এখনও এটি করি নি। যদিও এই দৃশ্যে সমস্যাটি হ'ল আমরা একটি বেসরকারী শাখা থেকে মুক্তি দেব না এবং তিনি একটি আংশিক সমাধান মোতায়েন চাই।
জন


উত্তর:


124

বিভিন্ন অভিজ্ঞতার সাথে অন্য কেউ থাকতে পারে, তবে অর্ধ-সমাপ্ত কোডে খনি পরীক্ষা করা একটি ভয়াবহ ধারণা, সময়কাল।

এখানে আমি যে নীতিগুলি শিখেছি এবং তা অনুসরণ করার চেষ্টা করেছি তা এখানে:

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

এর অর্থ:

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

সুতরাং সংক্ষেপে, না! কোডটি যদি পরবর্তী পর্যায়ে যেতে প্রস্তুত না হয় (আপনার জন্য যেটিই হোক: ইনটেক্সট / কিউএ / ইউএটি / প্রিপ্রড / প্রোড), এটি ট্রাঙ্ক বা মাল্টি-বিকাশকারী শাখায় প্রতিশ্রুতিবদ্ধ হওয়া উচিত নয়। পিরিয়ড।

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

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


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

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

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

4
@ জন: মনে হচ্ছে এমন কোনও ত্রুটি কোনও বিকাশকারী তদারকির কারণে হয়েছিল by মন্তব্য-আউট কোডে চেক করার নিষেধাজ্ঞা কীভাবে সেই বিকাশকারীকে এই তদারকি করতে বাধা দিত? নিষেধাজ্ঞা কেবল দুটি পরিবর্তে আপনাকে শাস্তি দেওয়ার জন্য দুটি জিনিস দেয়। এটি তদারকি বাধা দেয় না।
এডি

9
আমি প্রায় এটিকে ভোট দিয়েছি, তবে সত্যিই বিরল যে আমি কেবলমাত্র এক দিনের কাজের জন্য চেক-ইন অবস্থায় কাজ করছি এমন কিছু পেয়েছি। আমি মনে করি এটি সম্ভব যে আপনি আমার চেয়ে আরও উন্নত বিকাশকারী, তবে আমি বিশ্বাস করতে বেছে নিই যে আমি আপনার চেয়ে আরও শক্ত স্টাফের উপর কাজ করি। :-)
টেড

45

"কখনই" নির্দেশিকাতে ব্যবহার করার জন্য খুব কমই ভাল শব্দ।

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

বেশিরভাগ ক্ষেত্রে, একটি সু-পরিচালিত পরিবর্তন-নিয়ন্ত্রিত সিস্টেমে ডেড কোড মন্তব্য করা অপ্রয়োজনীয়। তবে, সমস্ত মন্তব্য কোড "মৃত" নয়।


9
আমি একমত নই কোডটি যদি অসম্পূর্ণ থাকে তবে প্রথমে এটি কেন চেক ইন করা হচ্ছে। আধুনিক উত্স নিয়ন্ত্রণ সিস্টেমে ট্রাঙ্কের প্রতিশ্রুতি না দিয়ে অগ্রগতি কার্যকারিতা আপলোড করার ব্যবস্থা রয়েছে।
রেক্স এম

9
+1, কখনও কখনও এটি করা সবচেয়ে উপযুক্ত জিনিস। সবসময় না, তবে কখনও হয় নাকখনও বলা সহজ হয় না, তবে খুব সীমাবদ্ধ।
এডি

@ রেক্স আমি প্রগতি কার্যকারিতা আপলোড এবং ট্রাঙ্ক প্রতিশ্রুতিবদ্ধ মধ্যে পার্থক্য নির্ধারণ করতে মূল পোস্টে পর্যাপ্ত তথ্য আছে বলে আমি মনে করি না।
জেসন কোকো

রেক্স - এটি কোনটি? অসম্পূর্ণ চেক না? বা ট্রাঙ্কে কখনই অসম্পূর্ণ চেক ইন করবেন না? এগুলি একই জিনিস নয়।
জেমস শেক

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

25

ইতিহাস রক্ষার লক্ষ্যে মন্তব্য করা আউট কোডটি কখনও চেক ইন করা উচিত নয় । এটি হ'ল উত্স নিয়ন্ত্রণের বিষয়।

মানুষ এখানে আদর্শ অনেক কথা হয়। অন্য সবার থেকে ভিন্ন হতে পারে, আমাকে "বাস্তব বিশ্বের" সাথে একাধিক বাধা সহ একাধিক প্রকল্পে কাজ করতে হবে assion মমত্বপূর্ণভাবে আমার কাজের দিনকে বাধা দিয়েছে।

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

প্রয়োজনে আমি আংশিক পরিবর্তনগুলি করার জন্য আমার নিজস্ব ওয়ার্কিং শাখা তৈরি করব।


4
@ জেমস আপনার শেষ বিটটি হ'ল চাবিকাঠি - আপনি যদি ওয়ার্কিং কোডটি চেক করতে না পারেন তবে এটি রাখার জন্য অন্য কোনও জায়গা খুঁজে নিন। তা কোনও শাখা বা তাক লাগানো সেট বা যাই হোক না কেন।
রেক্স এম

আমি যদি এটি একাধিকবার upvote করতে পারেন, আমি চাই। আমার অনুভূতি অবিকল!
ওলা এল্ডি

24

আমি ছেড়ে যাওয়া একটি ক্ষেত্রে কোড মন্তব্য আউট:

// This approach doesn't work
// Blah, blah, blah

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


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

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

4
হ্যাঁ, এটি আমার ধারণা - এটি নিশ্চিত করে যে ভবিষ্যতে বাগটি পুনরায় পরিচয় করা হবে না। আসল কোডটি রেখে তারা দেখতে পাবে যে এটি কীভাবে মূল লেখা হয়েছিল তাতে কেবল কোনও বাগ ছিল না।
লরেন পেচটেল

এই ক্ষেত্রে, আমি এটিকে "মন্তব্য করা কোড" হিসাবে বিবেচনা করি না, এটি ডকুমেন্টেশন।
hlovdal

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

20

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

আমি মনে করি আমরা সকলেই এই বিষয়গুলির সাথে একমত:

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

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

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

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

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

রেক্স এম বলেছেন: 1) কেবল সম্পূর্ণ কার্যকারিতা পরীক্ষা করে দেখুন, 2) [যদি] টাস্কটি খুব বড় হয় - এটি ছোট ছোট পরিপূরণীয় কার্যগুলিতে বিভক্ত করুন।

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

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

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

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


4
@ ক্যাম: এক সমস্যা ট্র্যাকিং সিস্টেম সমস্যাটি সম্পর্কে একটি সংক্ষিপ্ত মন্তব্য সহ প্রসঙ্গে, কোডের মধ্যে থাকা একটি অনুস্মারক হিসাবে একই প্রসঙ্গটি সরবরাহ করবে না। ইস্যু ট্র্যাকিং IDE এর সাথে গভীরভাবে সংহত করা হয়নি। আপনার পরামর্শটি ডগমাদের খাতিরে প্রচুর তথ্য সরিয়ে দেয় ।
এডি

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

4
একটি উদাহরণস্বরূপ, আমার শেষ মন্তব্য দেখুন: @John stackoverflow.com/questions/758279/... - এবং আমাকে বাগ পুনরায় প্রবর্তনের বাধা একটি ভাল উপায় দিতে। অথবা @ ক্যামে, আমাকে বলুন কীভাবে কোনও সমস্যা ট্র্যাকিং সিস্টেম সেই বাগটি পুনরায় প্রবর্তনকে আটকাবে। আপনি মিশন-সমালোচনামূলক 5-9 এর সরঞ্জামগুলিতে যখন কাজ করেন, তখন এ জাতীয় জিনিসগুলি গুরুত্বপূর্ণ।
এডি

4
@ জন: "আপনি বেশিরভাগ ছোট আকারের স্টাফগুলিতে কাজ করেন তার স্বতন্ত্র ছাপ আমি পেয়েছি" এতে আমার কীভাবে আপত্তি হওয়ার কথা নয়? ওরফে, কেবলমাত্র আমরা খুব ছোট কিছু নিয়ে একমত নই, আমাকে অবশ্যই অনভিজ্ঞ হতে হবে? আপনি অবশ্যই সর্বদা আপনার মতামতের অধিকারী, এবং এটি ঠিক যে আমরা একমত নই। তবে খেয়াল করুন যখন আমি আপনার সাথে একমত নই, আমি আপনার অভিজ্ঞতার স্তরের সমালোচনা করি না কারণ আমরা বিষয়গুলি ভিন্নভাবে দেখি। আসলে, আমি 98% বা 99% আপনার সাথে একমত। আমি কেবল নিঃসংশয় পছন্দ করি না।
এডি

4
@ এডি - আপনার উত্তরের বর্তমান অবকাশটি আমি সর্বোত্তম অনুশীলন হিসাবে বিবেচনা করব তার সাথে একমত হওয়ার অনেক বেশি কাছাকাছি। যদিও সর্বদা যথাযথ অনুশীলনের বিষয়টি আসে, আপনি কখনই সকলের কাছ থেকে 100% চুক্তি পাবেন না যে কোনও কিছুই বৈধ সেরা অনুশীলন। আমি কখন আমার প্রশ্ন পোস্ট করেছি তা আশা করিনি :)
জন

15

আমি কখনও মনে করি না শর্ত খুব শক্তিশালী হয় না।

আমি মন্তব্য করতে, চেক ইন করতে, পরীক্ষা চালাতে, একটি চিন্তাভাবনা করতে এবং তারপরে পরবর্তী প্রকাশের পরে মন্তব্যগুলি সরাতে চাই।


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

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

ঠিক যেমন, কিন্তু দুর্ভাগ্যক্রমে সেখানে বিপুল সংখ্যক বিকাশকারী মনে করেন "কমিট" এর অর্থ "ট্রাঙ্কে পরিবর্তনগুলি প্রবর্তন", সিভিএস এবং এসভিএন আমার অনুমানের জন্য ধন্যবাদ। ভাগ্যক্রমে জিআইটির মতো নতুন সিস্টেমগুলি নতুন পদ্ধতি শেখাচ্ছে ...
পাবলো

@ জোহান, আমি বোঝাতে চেয়েছি: মন্তব্য কর, পরীক্ষা কর, চেকিন ..! আপনি সঠিক.
ফরটিয়রুনার

14

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

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

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

আমার জন্য কমেন্ট-আউট কোডটি সাধারণত কম চিন্তাশীল সহকর্মীর কাছ থেকে অসম্মানের চিহ্ন হিসাবে দেখা হয় ।


4
আপনার পোস্টের শেষ লাইনটি মারা গেছে। আমি আশা করি আমি আপনাকে একাধিকবার ভোট দিতে পারলাম
মাইকেজে

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

7

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


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

4
আমি এই ধরণের বিষয়টিকে পুরোপুরি এড়িয়ে চলা উচিত, তবে কোনও কারণে ম্যানেজমেন্ট রাজি বলে মনে হচ্ছে না :)
রবার্ট গোল্ড

6

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

মন্তব্য করা আউট কোডটি দেখতে পরবর্তী বিকাশকারীটির কোনও ধারণা নেই যে এটি কাজ চলছে। তিনি কি এটিকে পরিবর্তন করতে মুক্ত? এটা কি ডেড কোড? সে জানে না।

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

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


6

এটি দুটি বিদ্যালয়ের চিন্তার মৌলিক পার্থক্য দেখায়: যারা কেবলমাত্র কার্যকর কোডটি যাচাই করে যা তারা সন্তুষ্ট এবং বোধ করেন তারা সংরক্ষণের উপযুক্ত এবং যাঁরা তাদের কাজটি পরীক্ষা করেন তাই তাদের সংশোধন নিয়ন্ত্রণ তথ্য উপাত্তের বিপরীতে দাঁড় করানোর জন্য রয়েছে।

আমি পরেরটিটিকে "যারা তাদের পুনর্বিবেচনা নিয়ন্ত্রণ ব্যবস্থাটি দরিদ্র লোকের টেপ ব্যাকআপ হিসাবে ব্যবহার করতে পছন্দ করে" হিসাবে চরিত্রায়িত করব তবে আমি যে শিবিরে আছি তাতে আমার হাত টিপছে। :-)

আমার অনুমান যে আপনি "ভাল কোড" শিবিরের, এবং তিনি "ওয়ার্কিং কোড" শিবিরের।

[সম্পাদনা]

মন্তব্যগুলি থেকে, হ্যাঁ আমি সঠিক অনুমান করেছি।

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

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


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

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

জেমস, কীভাবে আমার ইমাস ব্যাকআপগুলি আমাকে রক্ষা করে না? বিটিডাব্লু: আমি আপনার শেষ বাক্যটির সাথে আন্তরিকভাবে একমত হই।
টেড

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

@ টেড.ডেননিসন: শীর্ষ দুটি উত্তরের স্কোরের দিকে তাকিয়ে আমি বলব যে আপনার মতামত এসও নিয়ে সংখ্যাগরিষ্ঠ মতামত।
এডি

4

আমার অভিজ্ঞতায় বিকাশকারী স্যুইচগুলি কোড মন্তব্য করে are

কখনও কখনও, নতুন ব্যাক-এন্ডগুলি সমান্তরালে নির্মিত হয়, সক্রিয়করণের সুইচগুলি সোর্স নিয়ন্ত্রণে মন্তব্য করেছিল।

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


4

কোডে মন্তব্য করাতে চেক করার জন্য আরেকটি কারণ:

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


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

অবশ্যই কোডের অপসারণ লাইনে। এটা একটা ভাল দিক.
বৃহস্পতিবার

4
আমি একমত নই কী এড়াতে হবে সে সম্পর্কে একটি মন্তব্য করা প্রয়োজন, তবে কোড আকারে নয়, এটি কথায় বর্ণনার চেয়ে।
thSoft

3

সম্ভবত এখানে আসল প্রশ্নটি হ'ল বিকাশকারীদের কি অসম্পূর্ণ কোড চেক করার অনুমতি দেওয়া উচিত?

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


3

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


3

আমার দৃষ্টিভঙ্গি: যদি বিকাশকারীরা তাদের নিজস্ব শাখায় বা তাদের নিজস্ব স্যান্ডবক্স অঞ্চলে কাজ করে থাকে তবে তাদের যা খুশি তা পরীক্ষা করতে সক্ষম হওয়া উচিত। তারা যখন কোনও ভাগ করা শাখায় (কোনও বৈশিষ্ট্য শাখা, বা একটি দলের শাখা, বা অবশ্যই MAIN / ট্রাঙ্ক) কোডটি পরীক্ষা করে দেখেন যে কোডটি যতটা সম্ভব আধ্যাত্মিক হওয়া উচিত (কোনও মন্তব্য কোড আউট, আর কোনও FIXMEs ইত্যাদি নেই)।


4
মূল ট্রাঙ্কে টোডো এবং ফিক্সএমই বা হ্যাক ছাড়া বিশ্বে কোনও অর্থবহ প্রকল্প নেই। স্বপ্ন.
রবার্ট গোল্ড

4
@ রবার্ট কেবল কারণ এটি অনেক কিছু ঘটে তার অর্থ এই নয় যে আমাদের এড়াতে চেষ্টা করা উচিত নয়।
রেক্স এম

4
বাহ, এটি সত্যিই একটি স্বপ্ন। কোনও FIXMEs সহ প্রোডাকশন কোড? এটি অবশ্যই কোনও বাগ এবং কোনও অব্যক্ত আচরণ নয় এমন বৈশিষ্ট্য সম্পূর্ণ হতে হবে। ওহ অপেক্ষা করুন, এমন কোডের অস্তিত্ব নেই! :)
এডি

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

@ জিন: হ্যাঁ, আমরা এর সাথে একমত হই।
এডি

2

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

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


2

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

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

আমি এটি কোড জটিল করে তোলে এবং এটি পড়া কঠিন করে দেখি।

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


2

আমি মনে করি একটি উত্স কোড নিয়ন্ত্রণ ব্যবস্থায় মন্তব্য করা কোডটি চূড়ান্ত সতর্কতার সাথে করা উচিত, বিশেষত যদি কোডটিতে মন্তব্য করার জন্য ব্যবহৃত ভাষা ট্যাগগুলি ব্লক দ্বারা লিখিত হয়, যেমন:

/* My commented code start here
My commented code line 1
My commented code line 2
*/

বরং পৃথক লাইনের ভিত্তিতে যেমন:

// My commented code start here
// My commented code line 1
// My commented code line 2

(আপনি ধারণা পেতে)

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

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

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


হ্যা আমি রাজি. আমরা আমাদের সমস্ত সি # প্রোগ্রামে মন্তব্য করার / * * / স্টাইলকে বিশেষভাবে অস্বীকার করেছি।
জন

2

সোর্স-কন্ট্রোল ইতিহাসকে কোনও মন্তব্য করার পরিবর্তে মন্তব্য করার চেয়ে কমেন্ট করার "পুরানো উপায়" চিত্রিত করার অনুমতি দেওয়ার ধারণাটি ব্যাখ্যা সহ তদন্তের ক্ষেত্রে একটি ভাল ধারণা।

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

তারপরেও প্রায় 3 টির বেশি সংস্করণ ফিরে পাওয়া মূলত কখনই ঘটে না।

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

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

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

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

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

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

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

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

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


কেন খুব কম লোকই এই যুক্তিগুলির সাথে একমত হয়?
পাব্রাম

2

আমি মনে করি মন্তব্য করা কোডটিকে "বর্জ্য" হিসাবে বিবেচনা করা হয়।

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

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

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

আপনাকে কোডটি কেন মন্তব্য করা হয়েছে তা " কেন " প্রশ্ন জিজ্ঞাসা করতে হবে। কিছু পরামর্শ:

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

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

যদি আপনি কিছু মন্তব্য করে থাকেন কারণ "কিছু কাজ করে না" তবে ফিক্স আইটি ! একটি সাধারণ দৃশ্য হ'ল "ভাঙা পরীক্ষা" বা "টুড" । আপনার যদি এগুলি থাকে তবে আপনি নিজের শেল্ফকে ঠিক করে বা কেবল এগুলি থেকে মুক্তি পেয়ে প্রচুর সময় সাশ্রয় করবেন। যদি তারা একটি সময়ের জন্য "ভাঙ্গা" হতে পারে তবে সম্ভবত তারা চিরতরে নষ্ট হয়ে যেতে পারে।

এই সমস্ত সম্ভাব্য পরিস্থিতিতে (এবং আমি এখানে উল্লেখ করি নি) এর সমস্ত সময় এবং প্রচেষ্টা নষ্ট হয়। মন্তব্য করা আউট কোডটি একটি ছোট সমস্যার মতো মনে হতে পারে তবে এটি আপনার দলে বড় ইস্যুর সূচক হতে পারে।


1

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

আমি এটিতে মন্তব্য করার একমাত্র কারণ হ'ল আমি রাতারাতি বিল্ডটি ভাঙতে চাই না।


একটি সংগ্রহস্থল একটি ভার্সন নিয়ন্ত্রণ সিস্টেম যা আমার মনে কোনও ব্যাকআপ সরঞ্জাম নয় tool
জন

@ জন: অনেক বিকাশকারী উভয়ই এটিকে দেখতে পাবেন।
এডি

@ এডি, তারা করবে, কিন্তু তা নয়। ব্যাকআপগুলির জন্য সমস্ত ধরণের ভাল বিকল্প রয়েছে, সংস্করণ-নিয়ন্ত্রণ আসলে তাদের মধ্যে একটি নয়, তাই না?
ডেভিড বলেছেন মনিকা

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

1

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

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


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

1

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

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


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

@ এডি - আমি সময়ে সময়ে শিপিংয়ের জন্য পরীক্ষামূলক কোডটির সাথে একমত হই। তবে যখন আমার মতে এটির আর দরকার নেই তখন এটি মন্তব্য করা উচিত নয়।
জন

@ এডি - আমি বুঝতে পারি আপনি যখন শাখা তৈরি করবেন তখন শাখাটি হেড / রিলিজ সংস্করণের সম্পূর্ণ অনুলিপি। যদি আপনি একটি মোড তৈরি করেন তবে এটি বিল্ডেবল / শিপযোগ্য should আপনি যদি শাখার পরিবর্তনগুলি পছন্দ করেন তবে আপনি এগুলি আবার মাথা প্রান্তে মার্জ করে বা প্রয়োজনে ডিবাগ / প্রোফাইলিংয়ের জন্য সহজ রাখেন।
মাইকেজে

@ জন: সম্পূর্ণ একমত একবার পরীক্ষামূলক কোডটি আর পরীক্ষামূলক না হলে এটিকে যথাযথভাবে রেখে দেওয়া বা সম্পূর্ণ অপসারণ করা উচিত। @ মাইকজে: ভাল সাড়া
এডি

1

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

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


1

" স্কার টিস্যু " হ'ল আমি মন্তব্য-আউট কোড বলে। সংস্করণ-নিয়ন্ত্রণ ব্যবস্থাগুলির বিস্তৃত ব্যবহারের আগের দিনগুলিতে, কোড বানররা কার্যকারিতা ফিরিয়ে নেওয়ার প্রয়োজনে ফাইলটিতে মন্তব্য করা কোড ছেড়ে দেবে।

"দাগী টিস্যু" চেক-ইন করার ক্ষেত্রে এটি কেবল গ্রহণযোগ্য

  1. আপনার যদি একটি প্রাইভেট শাখা থাকে এবং
  2. আপনার ত্রুটি ছাড়াই কোড সংকলন করার সময় নেই এবং
  3. আপনি একটি দীর্ঘ অবকাশ যাচ্ছেন এবং
  4. আপনি আপনার ভিসিএসকে বিশ্বাস করেন না, যেমন আপনি ভিজ্যুয়াল সোর্স নিরাপদ OR ব্যবহার করেন ।
    [সম্পাদনা]
  5. আপনার একটি সূক্ষ্ম ত্রুটি রয়েছে যা ভুল কোডটি অনুস্মারক হিসাবে না রেখে যদি পুনরায় চালু করা যায়। (অন্যান্য উত্তর থেকে ভাল পয়েন্ট)।

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

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

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

[সম্পাদনা] আমি যুক্ত করব যে দুটি প্রধান দৃশ্য আছে যা আলাদা করা প্রয়োজন:

  • ব্যক্তিগত উন্নয়ন হয়, হয় একটি ব্যক্তিগত প্রকল্প কোডিং বা একটি বেসরকারী শাখায় চেক ইন
  • রক্ষণাবেক্ষণের বিকাশ, যেখানে কোডটি যাচাই করা হচ্ছে সেগুলি উত্পাদনের উদ্দেশ্যে is

দাগ-টিস্যুতে কেবল "না" বলুন!


-1 মন্তব্য কোড একটি ফাংশন এর উদ্দেশ্য বুঝতে খুব দরকারী। নিখুঁত বিশ্বে সবাই এর জন্য দুর্দান্ত মন্তব্য ফেলে leaves তবে বাস্তব বিশ্বে আমি মন্তব্য কোডটি খুব সহায়ক বলে খুঁজে পেয়েছি এবং অ্যান্ড্রু শেলানস্কি আমাকে কেন এটি উত্স নিয়ন্ত্রণে সন্ধান করতে হবে না তার কারণগুলি উল্লেখ করেছিলেন।
ব্র্যান্ডন মুর

0

আমি জানি না - আমি পরিবর্তনগুলি করার আগে আমি সর্বদা মূল লাইনগুলিতে মন্তব্য করি - যদি আমি আমার মন পরিবর্তন করি তবে এটি আমাকে তাদের ফিরিয়ে দিতে সহায়তা করে। এবং হ্যাঁ আমি তাদের পরীক্ষা করে নিই।

যাইহোক আমি আগের চেক-ইন থেকে কোনও পুরানো মন্তব্য কোড সরিয়ে আনি।

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


4
আপনার আরও ভাল ডিফ সরঞ্জামগুলির প্রয়োজন হতে পারে?
jw

এটি না করার একটি কারণ হতে পারে যাতে আপনি দেখতে পারেন কে মূল লাইনটি তুচ্ছভাবে লিখেছেন (উদাঃ গিট দোষ)
gtd

হ্যাঁ আমার কাছে এটি বলার সাথে মিলে যায় "আমি টয়লেট ব্যবহারের আগে সবসময় ফ্লাশ করি। তবে পরে না"।
বেনজিসমথ

0

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


0

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

যদি আমার পূর্ববর্তী পরিবর্তনগুলি দেখতে এখন বেশ কয়েকটি সংস্করণ ফিরে যেতে হয় যা এখন একটি পারফরম্যান্স হিট নিয়ে যায় তবে তা খুব বিরক্তিকর হবে।

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

এই কোডটি কারা মন্তব্য করেছেন তা জানাও ভাল হবে যাতে যদি কিছু যুক্তি প্রয়োজন হয় তবে তাদের জিজ্ঞাসা করা যেতে পারে।

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


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

0

ডেভেলপার কিছু কোড আউট মন্তব্য করে থাকে তাহলে কারণ এটি এখনো সম্পূর্ণ তারপর সঠিক "উৎস নিয়ন্ত্রণ" এই মোকাবেলা করার যা বিকাশকারীর তার নিজের একটি পৃথক শাখায় এটা রাখতে হতে হবে, যতক্ষণ না যে কোড নয় হয় পরীক্ষা করার জন্য প্রস্তুত ভিতরে.

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

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


0

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

এই কর্মপ্রবাহে বিকাশকারীকে সহায়তা করা ভিসিএস সিস্টেমের উপর নির্ভর করে (গিটটি একটি দুর্দান্ত ভিসিএস সিস্টেম যা এটি খুব সুন্দরভাবে কাজ করে)।

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