আপনার সমস্ত বিকাশ যখন শাখাগুলিতে থাকে তখন কীভাবে রিফ্যাক্টর করবেন?


24

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

আমরা যদি কোনও শাখায় কোনও রিফ্যাক্টরিং চেপে দেখার চেষ্টা করি তবে এটি কতক্ষণ "আউট" হবে তা আমরা জানি না, সুতরাং এটি আবার সংশ্লেষ করার পরে অনেক বিবাদ সৃষ্টি করতে পারে।

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

এদিকে, নতুন বিকাশ ঘটছে, এবং আমার নাম পরিবর্তিত ফাংশনটি মূলত কাঁটাচামচ করা শাখাগুলির কোনওটিতে নেই। যখন আমার ইস্যুটি আবার একত্রিত হয়ে যায়, তখন সেগুলি ভেঙে যায়।

এটি মোকাবেলার কোন উপায় আছে?

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


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

2
একদিকে যেমন, বর্তমান শাখা কাঠামোর একটি চিত্রটি সত্যই সহায়ক হতে পারে। এটা সম্ভব যে রিফ্যাক্টরিংয়ের সাথে সমস্যার সাথে সমস্যার মূলটি কিছু অংশের কারণে ঘটেছিল ... অপ্রচলিত শাখার নীতিগুলি (দেখুন প্রোগ্রামারস.স্ট্যাকেক্সচেঞ্জ / প্রশ্নগুলি / ২১০৩60০) যেমন একটি উদাহরণের জন্য )। আমি কিছু ধারণা এবং পটভূমি পেতে ভ্যানস.com/ স্টিভ / স্পারফোর্স / ব্রাঞ্চিং_সেট্রেজিজ এইচটিএমএল পড়ার পরামর্শও দেব (যদি আমি এই প্রশ্নের উত্তর দিতে সক্ষম হই তবে এটি একটি প্রধান রেফারেন্স পয়েন্ট হবে)।

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

1
@ ম্যাটনজ: আপনি ঠিক বলেছেন। তারা আসল কিউএ দল নয়। তারা বেশিরভাগ গ্রাহক সমর্থন। আমি মনে করি তাদের বেশিরভাগ দায়িত্ব দেব দলের কাছে ফিরিয়ে দেওয়া উচিত কারণ তারা কেবল আমাদের উপর যে সমস্ত জিনিস ফেলে দেয় তা পরিচালনা করতে পারে না, তবে এটি একটি ব্যবস্থাপনা সমস্যা এবং একটি যুদ্ধ যা আমি এখনও জিততে পারি নি।
এমপেন

3
আপনি আমার খনন মিস করেছেন। পরীক্ষা! = কিউএ। কিউএ গুণমানের তদারকি করে এবং ব্যবসায়ের ফলাফলগুলি উন্নত করার লক্ষ্যে। পরীক্ষাগুলি ত্রুটিগুলি সনাক্ত করে তাদের অভাব প্রমাণ করার চেষ্টা করে।
mattnz

উত্তর:


12

এই পরিবেশে রিফ্যাক্টরিং চ্যালেঞ্জিং করতে বেশ কয়েকটি সমস্যা একত্রে মিশ্রিত হচ্ছে। এর সাথে মিশ্রিত হ'ল কিছু অ-প্রযুক্তিগত সমস্যা ("তবে এটি একটি ম্যানেজমেন্ট সমস্যা এবং একটি যুদ্ধ যা আমি এখনও জিততে পারি না")।

প্রথম সমস্যাটি দেখতে দীর্ঘমেয়াদী শাখা। এই শাখাগুলির বিকাশকারীদের দেখার বাইরে ট্র্যাকিং পরিবর্তনগুলি ট্র্যাক করতে অসুবিধা হয়। এটিকে সম্বোধন করতে:

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

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

একটি সংক্ষিপ্ত বৈশিষ্ট্য শেষ সময় শুরু হওয়ার সাথে সাথে অন্য শাখাগুলি দ্বারা বাছাই করা সক্ষম হওয়া সহজতর হবে oring

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

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

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

প্রযুক্তিগত debtণ নিয়ে কাজ করার জন্য সময় বরাদ্দের সন্ধানে আপনি নিম্নলিখিত প্রশ্নগুলি দরকারী দেখতে পেতে পারেন:

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

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


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

3

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

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

যদি সত্যিকারের রিফ্যাক্টরিং টিম স্ক্রু না করে সিঙ্কে রাখতে খুব বেশি সময় নেয় তবে আমি সমস্ত প্রাসঙ্গিক বৈশিষ্ট্য নিচ্ছি এবং সেগুলিও সমান্তরালে পুনরায় সংশোধন করছি।

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

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

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

সাধারণত, ধারণাটি হল সমান্তরালে নতুন বৈশিষ্ট্য প্রস্তুত করা এবং একটি ছোট পদক্ষেপের মাধ্যমে সেগুলি ব্যবহার করতে স্যুইচ করা।

জন কারম্যাক এই (বা কমপক্ষে একযোগে) পদ্ধতির ব্যবহার করে, সম্ভবত তার ব্লগ পোস্টটি এটি আরও ভালভাবে ব্যাখ্যা করেছে: (লিঙ্ক)


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

1

এটি প্রযুক্তিগত দিক থেকে অসুবিধার মতো দেখাতে পারে যখন এটি প্রয়োজনীয়তার দিকে থাকে।

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

সমস্ত বিকাশকারীদের প্রাসঙ্গিক ইনপুটগুলির সাথে সঠিক সিদ্ধান্ত নেওয়ার পরে জেডবিবি প্রক্রিয়া এবং কো-ডেভ "সমঝোতা" করে যখন আপনার কী প্রয়োজন তা ভাবতে না পেরে আপনার উত্তরপত্রগুলি কার্যকর করতে হবে - আমি কীভাবে আমার কোডটি মার্জ করব?

জেডবিবি এর অর্থ জিরো-ভিত্তিক বাজেটিং । কো-ডেভ বলতে আমি বোঝাতে চেয়েছি এমন কিছু লোক যারা সমান্তরাল প্রোগ্রামিংয়ে কাজ করছেন।


2
"জেডবিবি" এবং "কো-দেব" কী?
gnat

জেডবিবি - এন.উইকিপিডিয়া.আর / উইকি / জিরো- বেসড_বাজেটিং । কো-ডেভ বলতে আমি বোঝাতে চেয়েছি এমন কিছু লোক যারা সমান্তরাল প্রোগ্রামিংয়ে কাজ করছেন।
ইয়োসি দাহারী

1

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


0

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

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

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

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