কেবলমাত্র অ-সমালোচক টাইপগুলি সমাধান করার জন্য প্রতিশ্রুতিবদ্ধতাটি মূল্যবান?

Question

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

বিশেষত, আমি এই নন-সমালোচনামূলক টাইপগুলি সমাধান করার মানটির বিরুদ্ধে কমিট লগের গাম্পিং আপকে ওজন সম্পর্কে আগ্রহী। আমি তাদের সমাধানের দিকে ঝুঁকছি। আমি কি পেডেন্টিক হচ্ছি?

Comments

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

— রেক্স কের 18

@ রুট 45 যদিও আপনি এর ফলাফলগুলি দেখুন তবে এই প্রশ্নটি জিজ্ঞাসা করার চেয়ে এগুলি ব্যাকরণের বিভিন্ন ধরণের're

— ইজকাটা

Answer 1

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

আপনি এটি কোনও TRIVIAL:ট্যাগ দিয়ে উপসর্গ করতে চান , বা আপনার ভিসিএস সমর্থন করলে এটি তুচ্ছ হিসাবে চিহ্নিত করতে পারেন।

Comments

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

— অ্যান্ডি

ভাঙা উইন্ডো প্রভাব উল্লেখ করার জন্য +1। ছোট বিষয়গুলি গুরুত্বপূর্ণ। সবকিছু যদি সত্যিই পরিষ্কার হয় তবে লোকেরা অযত্নে লিখিত বা অনির্ধারিত কোড করার আগে দু'বার চিন্তা করবে।

— রায় টিঙ্কার

এছাড়াও যদি আপনি এটি কোনও বৈশিষ্ট্য দিয়ে সজ্জিত করেন, তবে আপনি সেই বৈশিষ্ট্যটি ফিরিয়ে আনুন যাতে আপনি পরিবর্তনটি আলগা করেন। একবারে একটি জিনিস প্রতিশ্রুতিবদ্ধ।

— ctrl-alt-delor 21

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

— Xion

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

— আরএফ্যাক্টর

Answer 2

আপনি পেডেন্টিক নন, এবং পৃথকভাবে এগুলি সমাধান করা ভাল। যত বেশি পারমাণবিক পরিবর্তন হয় তত ভাল you আপনি চান না যে ক্র্যাশিং বাগ ফিক্সটি 500 টি মন্তব্য / টাইপো পরিবর্তনের সাথে মিশ্রিত হোক।

Comments

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

— অনুদান দিন

Answer 3

সাধারণ ক্ষেত্রে: হ্যাঁ

এটা সবসময় মূল্য এটি maintainability বৃদ্ধি আপনার সফ্টওয়্যার করুন।

শুধু এটাই কর.

যদি আপনি কেবল একটি মুক্তির চালান দিতে চলেছেন ...

... এবং যদি আপনি দলের নেতা না হন তবে তার সাথে তার সাথে যোগাযোগ করুন ।

---

প্রতিশ্রুতিবদ্ধ লগের বিষয়বস্তু সম্পর্কে ...

আমি অন্যদের সাথে একমত যে আপনার "কমপক্ষে কিছু লেখার" বিষয়টিকে "বৈশিষ্ট্য" সম্পর্কিত সম্পর্কিত কমিট থেকে আলাদা করা উচিত, যদি এটি কেবল কোনও বিচ্ছিন্ন টাইপ ঠিক করার বিষয়ে হয় about

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

• বড় অটোমেটেড ক্ষতিকারক ক্লিনআপস (হোয়াইটস্পেসগুলি ঝাড়ু),
• ব্যাকরণ এবং টাইপো শিকারের স্প্রি,
• সিস্টেম পরিবর্তন করুন,
• ইত্যাদি ...

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

Comments

টাইপ ফিক্সের জন্য আপনার দলের নেতার সাথে চেক করছেন? আমি যদি সেই টিম নেতা হয়ে থাকি যারা আসন্ন মুক্তির সাথে জোর দিয়ে থাকি তবে আমি এ জাতীয় তুচ্ছ ঘটায় বিরক্ত হতে চাই না।

— জো

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

— হাইলেম

@ জো: মূলত, যদি আমার টিম লিড নতুন বিল্ডটি হঠাৎ করে নতুন বিল্ডটি শুরু করতে দেখছে (বা ইতিমধ্যে এটি শুরু করা হয়েছে), তবে আমি আপনাকে নিশ্চিত করতে পারি যে এই পদ্ধতির সাহায্যে তার চাপের মাত্রা বাড়বে পাশাপাশি ...

— হাইলিমে

Answer 4

টাইপগুলি প্রতিশ্রুতি হিসাবে যুক্ত করা উচিত। ভুল বানানযুক্ত শব্দ বা ব্যাকরণগত ত্রুটিগুলি ঠিক করা আপনার কোডের পঠনযোগ্যতা বৃদ্ধি করবে।

"ফিক্সড টাইপো" বা "ফাইলে ফিক্সড টাইপো" এর মতো প্রতিশ্রুতিবদ্ধ বার্তা ব্যবহার করা আপনাকে এই কমিটগুলি অন্যান্য, প্রধান কোড কমিট থেকে আলাদা করতে সহায়তা করবে।

Answer 5

হ্যাঁ, আপনার একেবারে এটি করা উচিত, বিশেষত কোনও প্রকল্পের প্রথম দিকে।

কেন? দুটি বিন্দু:

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

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

Comments

হ্যাঁ - সমস্ত সঠিক উত্তরগুলির মধ্যে, এটি উল্লেখ করার জন্য আমি এটির পক্ষে একটি পছন্দ করি যে এটি "কখন" এর উপর নির্ভর করে।

— ওয়াঙ্কো দ্য সনে

Answer 6

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

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

Answer 7

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

Comments

I commit typo fixes all the timeআইএমও যে উদ্বেগজনক, আরও ভাল ইংরেজী সহ প্রোগ্রামারগুলি সন্ধান করার চেষ্টা করবেন?

— মিথ্যা রায়ান

ইয়া এই দিনগুলিতে আপনি কি পেতে পারেন তা নিন। প্রোগ্রামাররা সন্ধান করা যা কার্যকরভাবে কোড লিখতে পারে তা একটি মারাত্মক সমস্যা!

— ব্রায়ান নোব্লাচ

Answer 8

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

Answer 9

আপনার পরিবর্তন পরিচালনার প্রক্রিয়া কি এটির অনুমতি দেয়?

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

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

Comments

+1 কিছু পরিবেশে এটি সত্য। আপনি যেখানে কাজ করেন সেখানে এটি সত্য নয় বলে দয়া করে ডাউনोट করবেন না।

— মার্কজে

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

— gnat

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

— aloc

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

— মশা

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

— অ্যালোক

Answer 10

ইতিহাস সম্পাদনা করতে ডিভিসিএস ব্যবহার করুন

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

অন্যথায় সাধারণ জ্ঞান রাখুন

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

নোট করুন যে কার্যকরী বাগগুলি এখনও পারমাণবিক প্রতিশ্রুতিতে ASAP প্রতিশ্রুতিবদ্ধ হওয়া উচিত।

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