মাস্টার শাখার উপরে কয়েকশত কাস্টমাইজড শাখা বজায় রাখুন


140

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

আমরা যে চ্যালেঞ্জের মুখোমুখি তা হ'ল আমরা যখন এই শতাধিক কাস্টমাইজড শাখা বজায় রাখি এবং ক্লায়েন্টগুলিতে বিতরণ করি তখন সময়ে সময়ে আমরা নতুন বৈশিষ্ট্য সরবরাহ করি এবং আমাদের মাস্টার ব্রাঞ্চ আপডেট করি এবং আপডেট করার জন্য আমরা কাস্টম শাখায় মাস্টার শাখা পরিবর্তনগুলি ধাক্কা দিতে চাই তাদের সর্বশেষতম সংস্করণে।

দুর্ভাগ্যক্রমে এটি প্রায়শই কাস্টম কোডে অনেক বিবাদ সৃষ্টি করে এবং আমরা সমস্ত বিবাদগুলি সমাধান করতে প্রতিটি শাখা জুড়ে অনেক ঘন্টা ব্যয় করি। এটি অত্যন্ত অদক্ষ এবং আমরা খুঁজে পেয়েছি যে এই দ্বন্দ্বগুলি সমাধান করার সময় ভুলগুলি অস্বাভাবিক নয় are

আমি আমাদের ক্লায়েন্টের রিলিজ শাখাগুলিকে মাস্টার ব্রাঞ্চের সাথে আপ টু ডেট রাখার আরও কার্যকর পদ্ধতির সন্ধান করছি যা মার্জ হওয়ার সময় কম পরিশ্রমের ফলস্বরূপ।


11
"আপনি এক্স সরঞ্জামটি ব্যবহার করতে পারেন" উত্তর না দেওয়ার জন্য দুঃখিত, তবে এর একটিও নেই।
হালকাতা রেস

3
বা বিল্ড করার সময় (যা সম্ভবত আরও সাধারণ)। শুধু .. পুরোপুরি আলাদাভাবে কোডবেস নয়।
অরবিট

15
@ ফার্নানডো টিটান - আপনার দৃশ্যমান লক্ষণটি কোড হতে পারে, তবে আপনার রোগের মূল কারণটি হ'ল আপনার পণ্য খণ্ডন, নিরাময়ে পণ্য ফোকাস / পণ্য সক্ষমতা ম্যাপিং থেকে আসা দরকার, কোড ক্লিন আপ নয় - যা শেষ পর্যন্ত হবে। আমি আমার উত্তরে আরও বিস্তারিত জানিয়েছি - প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার.এই
অ্যালেক্স এস

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

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

উত্তর:


314

আপনি সম্পূর্ণ শাখা আপত্তি করছেন! আপনার অ্যাপ্লিকেশনটিতে নমনীয়তা দ্বারা চালিত কাস্টমাইজেশন থাকা উচিত, আপনার সংস্করণ নিয়ন্ত্রণে নমনীয়তা নয় (যা আপনি আবিষ্কার করেছেন যে এই ধরণের ব্যবহারের জন্য নকশাকৃত নয়)।

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

মূল অবকাঠামো এবং যে কোনও অংশীদারি বৈশিষ্ট্য, তারপরে কেবলমাত্র একবার সঞ্চয় করা, রক্ষণাবেক্ষণ এবং পরীক্ষা করা দরকার ।

আপনার এটি শুরু থেকেই করা উচিত ছিল। আপনার যদি ইতিমধ্যে পাঁচ শতাধিক পণ্যের বৈকল্পিক (!) থাকে তবে এটি ঠিক করা একটি বিশাল কাজ হয়ে উঠবে … তবে চলমান রক্ষণাবেক্ষণের চেয়ে বেশি আর কিছু নয়।


142
"আপনার প্রথম থেকেই এটি করা উচিত ছিল" এর জন্য +1। এই স্তরের প্রযুক্তিগত debtণ একটি সংস্থাকে ধ্বংস করতে পারে।
দেনিথ

31
@ ডেইনথ: স্পষ্টতই পাঁচ শতাধিক কাস্টম শাখা নিয়ে আমি অবাক হয়েছি যে এটি ইতিমধ্যে হয়নি। কে এই জিনিসগুলিকে খারাপ হতে দেয়? লোল
হালকা ঘোড়দৌড়

73
@ ফার্নান্দো টান আমি তাই, তাই বলে আপনার জন্য দুঃখিত ...
এন্ডারল্যান্ড

20
@ ফারানন্দো টান: আমিও। :( হতে পারে আপনি সাক্ষাত্কারে আরও প্রশ্ন জিজ্ঞাসা করা উচিত ছিল ?;) পরিষ্কার বলতে গেলে, আমার উত্তরে "আপনি" হ'ল সংগঠন। এটি একটি বিমূর্ততা। আমি ব্যক্তিদের জন্য দোষারোপ করার চেষ্টা করছি না।
অরবিট

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

93

৫০০ ক্লায়েন্ট থাকা একটি দুর্দান্ত সমস্যা, যদি আপনি শাখাগুলি নিয়ে এই সমস্যাটি এড়াতে সামনের সময়টি ব্যয় করে থাকেন তবে কোনও ক্লায়েন্ট পাওয়ার জন্য আপনি কখনও এতদিন ট্রেড রাখতে পারবেন না।

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

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

তারপরে কৌশল প্যাটার্ন, নির্ভরতা ইনজেকশন ইত্যাদি ব্যবহার করে আরও শক্ত সমস্যাগুলি সরিয়ে নিন

ক্লায়েন্টের নিজস্ব ক্ষেত্রগুলির জন্য কলাম যুক্ত করার চেয়ে ডাটাবেসে জসন সংরক্ষণ করার বিষয়টি বিবেচনা করুন - আপনার যদি এসকিউএল দিয়ে এই ক্ষেত্রগুলি অনুসন্ধান করার প্রয়োজন না হয় তবে এটি আপনার পক্ষে কাজ করতে পারে।

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

আপনি প্রথমে 500 টি শাখা থেকে আলাদা আলাদা প্রচুর ফাইল সহ বেশিরভাগ শাখায় কেবল কয়েকটি ফাইল যা আলাদা having এখনও বেঁচে থাকার জন্য যথেষ্ট অর্থোপার্জন করার সময়।

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


Br3w5- এর মন্তব্যের ভিত্তিতে:

  • আপনি ক্লায়েন্টদের মধ্যে পৃথক প্রতিটি ক্লাস নিতে পারেন
  • ক্লাসে বাইরে থেকে ডেকে আনা সমস্ত পদ্ধতিগুলির সংজ্ঞা দেয় এমন একটি "xxx_baseclass" করুন b
  • ক্লাসটির নাম পরিবর্তন করুন যাতে xxx কে xxx_clientName বলা হয় (xxx_baseclass এর উপ শ্রেণি হিসাবে)
  • নির্ভরতা ইনজেকশন ব্যবহার করুন যাতে ক্লাসের সঠিক সংস্করণ প্রতিটি ক্লায়েন্টের জন্য ব্যবহৃত হয়
  • এবং এখন চতুর অন্তর্দৃষ্টি জন্য br3w5 সামনে আসে! এখনকার নকল কোডটি খুঁজে পেতে এবং এটি বেস শ্রেণিতে ইত্যাদি স্থানান্তরিত করতে একটি স্ট্যাটিক কোড বিশ্লেষণ সরঞ্জাম ব্যবহার করুন

সহজ শস্য পাওয়ার পরে কেবল উপরেরটিটিই করুন এবং কয়েকটি ক্লাস দিয়ে প্রথমে এটি অনুসরণ করুন।


28
আসল সমস্যার জন্য একটি দৃষ্টিভঙ্গি দেওয়ার চেষ্টা করার জন্য +1
ইয়ান

35
আমি সত্যিই উদ্বিগ্ন ছিলাম যে আপনি নিজের উত্তরের জন্য নিজেকে অভিনন্দন জানাচ্ছেন, যতক্ষণ না আমি বুঝতে পেরেছি যে আপনি উত্তর @ উত্তরটি লিখেছেন একই নন।
থেরন লুহন

2
সম্ভবত কোডের কোন
অংশটি

1
কোন ক্লায়েন্টের
কোডটির

1
এটি "কেবল আপনার কোডটি রিফ্যাক্টর" বলার মতো দীর্ঘ বাতাসের মতো শোনাচ্ছে
রোল্যান্ড টেলিপ

40

ভবিষ্যতে, আপনার সাক্ষাত্কারে জোয়েল পরীক্ষার প্রশ্নগুলি জিজ্ঞাসা করুন । আপনি ট্রেনের ধস্তায় না যাওয়ার সম্ভাবনা বেশি থাকবেন।


এটি একটি, আহ, আমরা কীভাবে বলব ... সত্যই, সত্যই খারাপ সমস্যা আছে। এই প্রযুক্তিগত debtণের "সুদের হার" খুব, খুব বেশি হতে চলেছে। এটি পুনরুদ্ধারযোগ্য নাও হতে পারে ...

এই কাস্টম পরিবর্তনগুলি "কোর" এর সাথে কতটা সংহত হয়েছে? আপনি কি তাদের তাদের নিজস্ব গ্রন্থাগার তৈরি করতে এবং একটি একক "কোর" এবং প্রতিটি নির্দিষ্ট গ্রাহকের নিজস্ব "অ্যাড-অন" থাকতে পারেন?

না এই সমস্ত খুব গৌণ কনফিগারেশন?

আমি মনে করি সমাধানটি এর সংমিশ্রণ:

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

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

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

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


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

10
জোল টেস্টের কোন প্রশ্ন আপনাকে জানিয়েছিল যে সংস্থাটি শাখাগুলি আপত্তি করছে?
স্পেসট্রকার

2
@ স্পেসট্রিকার: আচ্ছা, "আপনি কি প্রতিদিন বিল্ডিং করেন?" সাহায্য করতে পারে। ৫০০ টি শাখা নিয়ে তারা সম্ভবত এগুলি রাখেনি বা উল্লেখ করেছেন যে তারা কেবল কয়েকটি শাখার জন্য এটি করেন।
সলেস্কে

17

আপনি যে কোনও ভিসিএসের সাহায্যে আঘাত করতে পারেন এটির মধ্যে অন্যতম নিকৃষ্ট প্রতিরোধক।

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

এটি আপনাকে আপনার উত্পাদন কোডের সাথে একটি মাস্টার শাখা রাখতে দেয়।


3
আপনি যদি এটি করেন তবে নিজের পক্ষে একটি সুবিধা করুন এবং কৌশল প্যাটার্নটি যতটা সম্ভব ব্যবহার করার চেষ্টা করুন । এটি আপনার কোডটি বজায় রাখা আরও সহজ করে তুলবে যদি আপনি কেবল if(getFeature(FEATURE_X).isEnabled())জুড়েই স্লেটার করেন ।
TMN

13

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

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

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


6
আপনি রক্ষণাবেক্ষণ শাখাগুলি সম্পর্কে ভুলে গেছেন, যা মূলত আপনার উত্তরে বর্ণিত শাখাগুলির বিপরীত। :)
কক্ষপথের হালকাত্বের রেস

7

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

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

যার অর্থ:

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

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

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

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


2
প্রযুক্তিগত সমস্যার পিছনে থাকা সামাজিক / সাংগঠনিক সমস্যাগুলি সমাধান করার জন্য ভাল পয়েন্টগুলি। এটি প্রায়শই উপেক্ষা করা হয়।
সলেস্কে

5

সমস্ত নায়ে-বক্তাদের বিপরীতে, আসুন ব্যবসায়ের প্রয়োজন অনুমান করি।

(উদাহরণস্বরূপ, বিতরণযোগ্য সোর্স কোড, গ্রাহকরা একই ব্যবসার লাইন থেকে এবং তাই একে অপরের প্রতিযোগী এবং আপনার ব্যবসায়ের মডেল তাদের গোপনীয় বিষয় গোপন রাখার প্রতিশ্রুতি দেয়)

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

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

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

প্লাগিনগুলি রান সময়ে লোড হতে পারে, বা সংকলন সময়ে অন্তর্নির্মিত হতে পারে।

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

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

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

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

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

পরিশেষে এই ধরণের ব্যবসায়ের শাখা রক্ষণাবেক্ষণের সাথে সত্যই নিজেকে উদ্বেগ করতে হবে , যথা, গ্রাহক-নির্দিষ্ট বৈশিষ্ট্যটি এক্স এত সাধারণ যে এটি সমস্ত গ্রাহক তার জন্য অর্থ প্রদান না করেও এটিকে মূল দিকে নিয়ে যাওয়া সস্তা?


3

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

আপনার 'কাস্টম' কোডটি পণ্যের বৈশিষ্ট্যগুলি এবং এক্সটেনশানগুলি এবং অন্যদের ডেটা ক্ষেত্রের পরিবর্তনের ব্যতীত কিছুই উপস্থাপন করে।

কাস্টম বৈশিষ্ট্যগুলি কতটা বিস্তৃত, কতটা পৃথক, প্রেক্ষাপটে কীভাবে অনুরূপ বা না আপনার পণ্য কোড কোড বেসকে 'স্যানিটাইজাইজিং' করতে অনেক ভূমিকা ফেলবে।

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

কারণ, দিনের শেষে, কোডটি আপনার ক্লায়েন্টদের কাছে আপনার ব্যবসায় এবং পণ্য বৈশিষ্ট্য / পরিষেবাদির অফার ব্যতীত কিছুই নয় । আপনার সংস্থাটি এর জন্য অর্থ প্রদান করছে।

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

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

এবং যদি আপনি বেশ কয়েকটি জিনিস সরবরাহ করে থাকেন তবে এটি আপনার পণ্যাদির সামঞ্জস্যকে একটি সংঘবদ্ধ ফ্যাশনে মডুলারাইজ করার অর্থ হবে।

আপনার পণ্যগুলি কত বিস্তৃত এবং গভীরতর হবে? নাহলে এটি 'পরিষেবার পরিষেবার মান' এবং 'পণ্য হ্রাস এবং খণ্ডিতকরণ' বাড়ে যখন আপনি লাইনে নেমে যাবেন।

আপনি কি সিআরএম বা ইআরপি বা অর্ডার প্রসেসিং / প্রেরণ বা মাইক্রোসফ্ট এক্সেল হবেন ?

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

আপনার একটি শক্তিশালী পণ্য পরিচালনা এবং ডেটা আর্কিটেকচার ব্যক্তি নিম্নলিখিত মানচিত্রের প্রয়োজন হবে:

  • মাস্টার শাখা, এর পণ্য ক্ষমতা এবং বৈশিষ্ট্যগুলির ভিত্তি
  • কাস্টম এক্সটেনশন বৈশিষ্ট্য, প্রকার এবং বিভিন্নতা
  • 'কাস্টম ক্ষেত্র' এর তাত্পর্য এবং প্রকরণ

..আপনার মূল প্রয়োগের দুর্দান্ত প্রেক্ষাপটে এই সমস্ত আলগা পণ্য থ্রেড / শাখাগুলির সমন্বয় এবং সুরেলা করার রোড ম্যাপ তৈরি করতে।

পিএস: আমার সাথে সংযুক্ত থাকুন, আমি এমন একজনকে চিনি যা আপনাকে এটি ঠিক করতে সহায়তা করতে পারে :)


-5

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

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

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

"প্রথমবার এটি ঠিকমতো না করার" জন্য অনেকগুলি কারণ রয়েছে এবং আমি মনে করি যারা এগুলি দ্রুত গ্রহণ করে এবং "এই মুহুর্তে এটি করতে" এগিয়ে যায় তারা সর্বদা সফল হবে।


16
একাধিক সংগ্রহস্থল কীভাবে রক্ষণাবেক্ষণকে আরও সহজ করে তুলবে?
ম্যাথলেটিক্স

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