অন্য দলের সদস্যের কোড পুনরায় লেখার অলিখিত বিধিগুলি [বন্ধ]

Question

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

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

Comments

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

— বেনামে

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

— তাজ

@ তাজ - এটি হ'ল বিগ বল অফ মড ( লুপুটান.আর . / মিউড ) প্যাটার্নের ভিত্তি ।

— ম্যাথু ফ্লিন

@ ম্যাথেজফ্লিন - দুর্দান্ত নিবন্ধ "মডের বড় বল" শব্দটিটি এতবার উপস্থিত হয়েছিল, এটি অ্যালান আইভারসনের "অনুশীলন" ( ইউটিউব . com/watch?v= eGDBR2L5kzI ) এর দেবা ভু অভিজ্ঞতার মতো অনুভূত হয়েছিল । ;-)

— হ্যাপি গ্রিন কিড নেপস

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

— mattnz

Answer 1

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

পূর্বের যোগাযোগ ব্যতিরেকে প্রবেশ এবং পুনরায় লেখাই অসুস্থ ইচ্ছার একটি রেসিপি।

Comments

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

— ফুলফি

"বিকাশকারী সাথে কথা বলুন" এর জন্য +1 - আমাদের কাছে একটি বাগ (ভাল, কমপক্ষে একটি, সম্ভবত আরও বেশি) রয়েছে যা গ্রাহক এখন প্রত্যাশা করে ... এবং এতদূর সমাহিত হয়ে গেছেন যে কেবল আমিই ছিলাম কেন এটি অস্পষ্টভাবে জানত যে এটি কেন বাকি ছিল একা।

— ইজকাটা

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

— অ্যারোনআউট

@ অ্যারোনট - মূল বিকাশকারীকে প্রথমে জিজ্ঞাসা করার প্রশ্নটি থেকেই বোঝা যায় যে ওপি এখনও মূল বিকাশকারীর সাথে কথা বলেনি এবং এইভাবে তিনি যা পারেন তার সব আবিষ্কার করার চেষ্টা করেননি। আমি আশা করি উত্তরটি ট্রাইটের বিপরীত - এটি মৌলিক।

— ম্যাথু ফ্লিন 18

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

— জেফ গ্রিগ

Answer 2

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

1. আপনি কি একেবারে, ইতিবাচকভাবে নিশ্চিত যে আপনি পুনর্লিখনের বিষয়ে কথা বলছেন এবং রিফ্যাক্টরিং নয়? সংজ্ঞা অনুযায়ী, কোড শৈলী অথবা কাঠামো যে পরিবর্তন একটি উন্নত (বা শুধু বিভিন্ন) বহিরাগত আচরণ পরিবর্তন ছাড়া বাস্তবায়নের এর ফলে refactor হয় না একটি লেখা। 50 subroutines একটি সেট মধ্যে একশব্দ 500-লাইন রুটিন ব্রেকিং বেশ কয়েকটি নতুন কোড লেখার সাথে জড়িত থাকতে পারে, তবে এটি পুনর্লিখন নয়। পুনর্লিখন শব্দের অর্থ পুরো পণ্য বা বৈশিষ্ট্যকে ছুঁড়ে ফেলা এবং স্ক্র্যাচ থেকে শুরু করা; এটি হালকাভাবে নেওয়া কিছু নয়।

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

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

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

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

5. প্রশ্নটি প্রথম অনুচ্ছেদে বলেছে any developer can change any line of code to add functionality, to refactor, fix bugs or improve designs,। একটি লেখা হবে না এ করছ কি? বা এটি অতিরিক্ত কিছু করবে - এবং যদি তা হয় তবে কী? মৌলিকভাবে, কি হয় একটি লেখা করতে অনুপস্থিত জন্য আপনার কারণে, এবং আপনি যে তারা পণ্য বা দল উপকৃত হবে কিভাবে কি নিশ্চিত? আপনার আমার জবাব দেওয়ার দরকার নেই, তবে আপনি দলের সাথে আলোচনা করার সময় এবং কখন এটির জন্য কিছু উদ্দেশ্যমূলক পয়েন্ট পেতে চাইবেন।

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

Comments

+1 এই আলোচনার একমাত্র সঠিক উত্তর।

— mattnz

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

— জেফ গ্রিগ

Answer 3

আপনি কোডটি সম্পাদনা করছেন কেন?

বাগ আছে বা এটি আরও মৌলিক ডিজাইনের ত্রুটি রয়েছে?

পূর্ববর্তী ক্ষেত্রে, আমি কোডটিতে ছোট বাগগুলি কী হতে পারে তা ঠিক করার জন্য একটি পুনর্লিখনের বিষয়ে চিন্তা করব

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

এটি সম্মিলিত কোডের মালিকানার মূল বিষয় - আপনি যে কোডটি লিখছেন সেটি হ'ল আরও কিছু ভাল কিছু সামনে আসলে পরিবর্তন বা এমনকি প্রতিস্থাপন করতে হবে।

Comments

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

— অ্যারোনআট

Answer 4

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

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

Answer 5

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

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

Answer 6

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

তবে কোডটি রিফ্যাক্টর করার বা পুনরায় লেখার আগে হয় একটি কোড ব্যাকআপ বা শাখা তৈরি করুন। যদি পুরানো কোডটি ঠিকঠাক কাজ করে, তবে এটি পুনরুদ্ধার করার একটি সুযোগ থাকবে।

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

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

Comments

"আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি কিছুক্ষণ পরে কোডটি মুছুন" - এর মধ্যে এটি কোথায় থাকা উচিত? একটি মন্তব্য ব্লক? বর্তমান উত্স কোডটি পরিষ্কার রেখে, সহজে পুনরুদ্ধারের জন্য সমস্ত পরিবর্তিত / মোছা কোডের একটি ব্যাকআপ অনুলিপি রাখার জন্য সোর্স নিয়ন্ত্রণটি এটি।

— dj18

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

— তদতিরিক্ত

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

— dj18

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

— অ্যারোনআট

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

— rwong

Answer 7

এর সুযোগ কী?

• আপনি যদি আরও দক্ষ হওয়ার জন্য কয়েকটি লাইন পুনরায় কাজ করছেন তবে কেবল এটি করুন। আপনার জিজ্ঞাসা করুন সূক্ষ্ম আচরণ মুছে ফেলতে আপনার কোনও বিপদ আছে কিনা। স্ক্র্যাম চলাকালীন বা ইমেলের মাধ্যমে পরিবর্তনের প্রতিবেদন করুন, এটি সত্যিই তুচ্ছ না হলে (কোনও টাইপ ফিক্স করা)।

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

• যদি আপনি একটি বৃহত্তর সিস্টেমটি পুনরায় কাজ করে থাকেন তবে পরিবর্তনের বিষয়ে তাদের সচেতন করতে এবং নকশার পরিকল্পনা করার জন্য আপনার দলের সাথে অবশ্যই কাজ করা উচিত।

Answer 8

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

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

আমি যখন আবার লিখি, তখন আমি মন্তব্য করেছিলাম যে আমি এটি মন্তব্য করেছি, সেই সাথে তারিখ এবং নাম / আদ্যক্ষর এবং কেন এটি মন্তব্য করা হচ্ছে। আমি নাম বা আদ্যক্ষর, তারিখ, কারণ যুক্ত করা হয় ইত্যাদি সহ নতুন কোড মন্তব্য করি

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

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

Answer 9

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

আমার অনুশীলনটি এটি প্রতিস্থাপন করার সময় এটিকে মন্তব্য করা। (মূলত রেফারেন্সের জন্য।) তারপরে এটিকে কার্য পরিবর্তনের চূড়ান্ত প্রতিশ্রুতিতে মুছুন। (এটির জন্য সংস্করণ নিয়ন্ত্রণ এবং পরিবর্তনগুলি কীভাবে ফিরিয়ে আনতে হবে তা বোঝার প্রয়োজন))

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

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

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

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

কোড পর্যালোচনা পরিবর্তন করা উপযুক্ত বিকাশকারী দ্বারা সম্পাদন করা উচিত।

Comments

প্রায় "এটি চূড়ান্ত প্রতিশ্রুতিতে মুছুন" না হওয়া অবধি এটি প্রায় হ্রাস করা।

— জোশুয়া ড্রেক

Answer 10

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

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

অন্যদিকে, আবার কিছু সময় রয়েছে যখন পুনর্লিখনের জন্য বলা হয়:

• কোডটি লেখার পর থেকে দলটি অনেক কিছু শিখেছে, এবং যে ডেভ (গুলি) লিখেছিল তারা এখন আপনার ইনপুট ছাড়াই এটিকে অন্যভাবে লিখবে।

• একটি নতুন বৈশিষ্ট্যের প্রয়োজনীয়তা পরিস্থিতিটিকে এমন পরিবর্তন করে যে একটি লক্ষ্যযুক্ত মিনি-পুনর্লিখন উপযুক্ত।

এই ক্ষেত্রে, আমি সম্ভবত কোনও কথোপকথন নিয়ে বিরক্ত করব না।

এ সম্পর্কে চিন্তাভাবনা করে, আমার কাছে মনে হচ্ছে কোডটি যত দীর্ঘ হয়েছে, কথোপকথনের প্রয়োজন কম হবে।

Answer 11

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

আমার ব্যক্তিগত অভিজ্ঞতা কোডটি সাধারণত পরিবর্তিত হয় কারণ হয় এটি ইচ্ছাকৃতভাবে কাজ করে না, অথবা আপনাকে কেবল এটি যা করে তা প্রসারিত করতে হবে।

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

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

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

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

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

Answer 12

প্রায়শই কোড কোনও কারণে নির্দিষ্টভাবে লেখা হয়। লেখকের কাছে পরিবর্তনটি যোগাযোগ করা সর্বদা সেরা কাজ করে।