কোনও বৈশিষ্ট্য শাখায় কাজ করার সময় আপনার কোডের মান উন্নত করা উচিত


11

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

আমি বিচ্ছিন্নতার বৈশিষ্ট্যগুলি বিকাশের উপায় হিসাবে বৈশিষ্ট্যযুক্ত শাখাগুলিও পছন্দ করি যাতে এটি পছন্দ না হলে আপনি সহজেই এটি মার্জ করতে পারবেন না ইত্যাদি etc.

তবে, আমি যদি কোনও বৈশিষ্ট্য শাখায় কাজ করছি এবং আমি কিছু কুরুচিপূর্ণ কোডটি সনাক্ত করেছি, তবে আমার এটি ঠিক করা উচিত?

এটি ঠিক করার জন্য অনেকগুলি নীচের দিক রয়েছে বলে মনে হয়:

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

ফ্লিপ সাইডে, আমি যদি ফাইলটিতে থাকি তবে এটি না করি, তবে স্পষ্টভাবে আমি শাখাটি সংযুক্ত করার পরে কয়েক দিনের মধ্যে এটি করতে ভুলে যাব।

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



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

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

উত্তর:


8

আপনি যদি বৈশিষ্ট্যের অংশ হিসাবে যেভাবেই সেই অংশের কোডটি পরিবর্তন করে থাকেন তবে আপনার কেবলমাত্র একটি বৈশিষ্ট্য শাখায় কোড 'ঠিক করা' উচিত।

যেমন। আমি 'প্রিন্ট খরগোশ' বৈশিষ্ট্যটিতে কাজ করছি এবং আমি প্রিন্টার কোডটি পাই

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

আমি এটিকে পরিবর্তন করি:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

কেন:

  • আমি কোড নিয়ে কাজ করছি,
  • কার্যকারিতা যুক্ত করতে আমার এটি পরিবর্তন করতে হবে,
  • যুক্ত কার্যকারিতা সমস্যাটি মোকাবেলার একটি রিফ্যাক্টর উপায় প্রস্তাব করে।

আমি কোড বেসের অন্য কোনও অংশকে এলোমেলোভাবে আঘাত করব না এবং এটি আরও ভাল করে তুলব ':

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

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

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

5

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

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


3

উদ্দেশ্য branchধরনের প্রদান করতে চলেছেন উদ্দেশ্য তাদের পরিচালনা করার জন্য। ধরনের পছন্দ শাখাবিন্যাস একটি GitFlow শৈলী অনুসরণ করছেন, তাহলে আপনি সম্ভবত আছে feature, hotfix, release, ইত্যাদি .. একটি বৈশিষ্ট্য শাখার ক্ষেত্রে, তার উদ্দেশ্য অন্য শাখা (অর্থাত মধ্যে একটি একত্রীকরণ encapsulate হয় developযে শো বিকাশকারীর জন্য দায়ী) মার্জ করা, এই বৈশিষ্ট্যটি কী। আপনি যে কোডটি পরিষ্কার করছেন সেটি যদি সেই বৈশিষ্ট্যের অংশ না হয় তবে এটিকে পরিবর্তন করবেন না।

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

এখানে বিভিন্ন কৌশলগুলির বেশ ভাল ব্যাখ্যা: https://www.atlassian.com/git/tutorials/compering-workflows/


0

যদি আমি কোনও বৈশিষ্ট্য শাখায় কাজ করছি এবং আমি কিছু কুরুচিপূর্ণ কোডটি সনাক্ত করেছি, আমি কি এটি সংশোধন করব?

প্রকল্পের টেম্পো, কোডের 'কদর্যতা' ইত্যাদির উপর ভিত্তি করে দৃষ্টিতে 'কুরুচিপূর্ণ কোড' ঠিক করা ঠিক আছে তবে বৈশিষ্ট্য শাখায় নিজেই এটি না করার চেষ্টা করুন।

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

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

  • আপনার সংশোধনগুলি রাখতে এবং আপনার বৈশিষ্ট্যটি বিভিন্ন গোষ্ঠীতে কমিট করে যাতে লগ আরও বেশি পঠনযোগ্য হয়,
  • যে কোনও সময় বিকাশযোগ্য হিসাবে যতটা সম্ভব উন্নয়ন বজায় রাখা এবং
  • কাজের সদৃশতা এড়াতে (একাধিক ব্যক্তি বিভিন্ন শাখায় সূক্ষ্মভাবে বিভিন্ন উপায়ে একই সমস্যা সমাধান করছেন)।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.