إعادة تنظيم المشروع للتوسع/إعادة الاستخدام

Question

يتم توسيع نطاق المشروع الذي أعمل عليه.التطبيق بسيط إلى حد ما ولكنه يستهدف حاليًا مكانًا محددًا للغاية.في المستقبل القريب، طُلب مني تقسيم المشروع لاستهداف سوق جديدة ومواصلة تطوير المشروعين جنبًا إلى جنب.

سيكون كلا المشروعين متشابهين وظيفيًا، لذا هناك حافز قوي جدًا لتعميم الكثير من الأمور أحشاء من المشروع الأصلي.أنا متأكد أيضًا من أنني سأستهدف المزيد من الأسواق في المستقبل القريب (الأسواق جغرافية).

المشكلة هي أن المشرفين السابقين على المشروع وضعوا الكثير من الافتراضات التي تربطه بالسوق الأصلي.سوف يستغرق الأمر قدرًا كبيرًا من إعادة البناء لفصل الكود العام عن الكود الخاص بالسوق.

ولجعل الأمور أكثر تعقيدا، تم طرح العديد من الاقتراحات حول كيفية تنظيم المشاريع لعدد متزايد من الأسواق:

1. كل سوق هو مشروع منفصل، ويتم نقل القواسم المشتركة بين المشاريع إلى مكتبة مشتركة، ويتم نشر المشاريع بشكل مستقل.
2. قم بتوسيع المشروع الحالي لاستهداف أسواق متعددة، مما يحد من الوظائف بناءً على الترخيص الذي تم شراؤه.
3. أنشئ تطبيقًا أصليًا وأعد تصميم المشاريع كمكونات إضافية، يتم شراؤها بشكل منفصل

جميع الاقتراحات الثلاثة لها ميزة ومن الناحية المثالية أود أن أجعل الكود مرنًا بدرجة كافية بحيث يكون أي منها ممكنًا مع تعديلات طفيفة.يبدو أن الاقتراح 3 هو الأكثر صعوبة لأنه يتطلب بناء بنية البرنامج المساعد.الاقتراحان الأولان أكثر قبولا بعض الشيء.

هل هناك أي موارد جيدة متاحة حول إيجابيات وسلبيات هذه البنى المختلفة؟

ما هي إيجابيات وسلبيات مشاركة التعليمات البرمجية بين آيات المشاريع والنسخ والتفرع؟

Answer 1

عادةً ما يمنحك التشعب نتيجة أسرع في البداية، ولكن دائمًا ما يأتي ويعضك في الصيانة - تضيع إصلاحات الأخطاء وتحسينات الميزات من تفرع واحد في التفرعات الأخرى، وفي النهاية تجد نفسك تتخلص من التشعبات الكاملة والاضطرار إلى إعادة إضافة ميزاتها إلى الشوكة "الأفضل".تجنب ذلك إذا كنت تستطيع.

المضي قدمًا:يمكن أن تنجح جميع الخيارات الثلاثة المتاحة لك، ولكن هناك مقايضات فيما يتعلق بتعقيد البناء، وتكلفة الصيانة، والنشر، ونفقات الاتصالات العامة، ومقدار إعادة البناء الذي يتعين عليك القيام به.

---

1.كل سوق هو مشروع منفصل

حل جيد إذا كنت ستقوم بالتطوير في وقت واحد لأسواق متعددة.

الايجابيات:

• فهو يسمح لمطوري السوق "أ" بكسر البنية "أ" دون التدخل في العمل المستمر على "ب".
• إنه يجعل من غير المرجح أن يؤدي التغيير الذي تم إجراؤه في السوق "أ" إلى حدوث خطأ في السوق "ب".

سلبيات:

• عليك أن تأخذ الوقت الكافي لفصل الكود المشترك
• عليك أن تأخذ الوقت الكافي لإعداد بنيات متوازية
• أصبحت التعديلات على الكود المشترك الآن تحمل المزيد من الحمل لأنها تؤثر على كلا الفريقين.

2.توسيع المشروع الحالي لاستهداف أسواق متعددة

يمكن جعلها تعمل بشكل جيد لفترة طويلة.إذا كنت ستعمل على إصدارات لسوق واحد في كل مرة، مع فريق صغير، فقد يكون هذا هو أفضل رهان لك.

الايجابيات:

• من المحتمل أن يكون عمل الترخيص ذا قيمة على أي حال، حتى لو انتقلت نحو (1) أو (3).
• تسمح قاعدة الكود الواحدة بإعادة البناء في جميع الأسواق.

سلبيات:

• حتى لو كنت تعمل فقط على شيء ما للسوق "أ"، فيجب عليك إنشاء التعليمات البرمجية وشحنها للأسواق "ب" و"ج" و"د" أيضًا - حسنًا إذا كان لديك قاعدة تعليمات برمجية صغيرة، ولكنها مزعجة بشكل متزايد عندما تصل إلى الآلاف من الطبقات
• إن التغييرات في أحد الأسواق قد تؤدي إلى كسر قواعد الأسواق الأخرى
• تتطلب التغييرات في أحد الأسواق إعادة اختبار الأسواق الأخرى

3.قم بإنشاء تطبيق أصلي وأعد تصميم المشاريع كمكونات إضافية

يبدو الأمر رائعًا من الناحية الفنية، وقد يسمح لك بمشاركة المزيد من التعليمات البرمجية.

الايجابيات:

• جميع إيجابيات (1)، محتملة، بالإضافة إلى:
  • فصل أكثر وضوحًا بين التعليمات البرمجية المشتركة والتعليمات البرمجية الخاصة بالسوق
  • قد يسمح لك بالانتقال نحو واجهة برمجة التطبيقات (API) العامة، والتي من شأنها أن تسمح بتفريغ بعض أعمالك على عملائك و/أو بيع مشاريع الخدمة المربحة

سلبيات:

• جميع سلبيات (1)، بالإضافة إلى أنها تتطلب المزيد من إعادة البناء.

---

أعتقد أن (2) هو المكان الذي تجد نفسك فيه الآن، بصرف النظر عن الترخيص.أعتقد أنه من المقبول البقاء هناك لبعض الوقت، ولكن بذل بعض الجهد للتحرك نحو (1) - نقل الكود المشترك إلى مشروع منفصل حتى لو تم إنشاؤه معًا، على سبيل المثال، محاولة التأكد من التبعيات من السوق التعليمات البرمجية إلى التعليمات البرمجية المشتركة كلها في اتجاه واحد.

سواء انتهى بك الأمر إلى (1) أو (3) فهذا يعتمد.في الغالب يتعلق الأمر بمن هو "المسؤول" - الكود المشترك أم الكود الخاص بالسوق؟يمكن أن يكون الخط الفاصل بين المكون الإضافي وفئة وحدة التحكم التي تقوم بتكوين بعض المكونات المشتركة ضبابيًا جدًا.نصيحتي هي أن تدع الكود يخبرك بما يحتاج إليه.

Answer 2

1) لا!لا ترغب في إدارة فروع مختلفة لنفس قاعدة التعليمات البرمجية ...لأنه على الرغم من شيوع الكود، فسوف ترغب في إجراء تغييرات شاملة، ولن يكون أحد المشاريع "في الوقت الحالي" بنفس أهمية المشاريع الأخرى، وبعد ذلك ستحصل على فرع واحد ينمو بشكل أسرع من الآخرين....أدخل كرة الثلج.

2) هذا هو معيار الصناعة إلى حد ما.ملف تكوين كبير، يحد من الأشياء بناءً على الترخيص/التكوين.يمكن أن يجعل التطبيق مرهقًا بعض الشيء، ولكن طالما أن الكود يشكو من أشياء حصرية متبادلة وأن جميع المطورين على اتصال مستمر حول الميزات الجديدة وكيفية انتشارها عبر التطبيق بأكمله، فيجب أن تكون على ما يرام.وهذا أيضًا هو الأسهل للاختراق، إذا كان هذا مصدر قلق.

3) هذا أيضًا "يمكن" أن ينجح.إذا كنت تستخدم C#، فإن المكونات الإضافية تكون بسيطة نسبيًا، وما عليك سوى القلق بشأن جحيم التبعية.إذا كان لدى المكونات الإضافية أي فرصة لتصبح مترابطة بشكل دائري (أي أن أ يتطلب ب يتطلب ج يتطلب أ)، فسوف ينفجر هذا بسرعة وستعود (بسهولة تامة) مرة أخرى إلى رقم 2.

ربما تكون أفضل الموارد التي لديك هي التجارب السابقة لزملائك في العمل في مشاريع مختلفة، وتجربة الأشخاص الذين يتذمرون حول هذا الموضوع هنا أو Slashdot أو في أي مكان.بالتأكيد أرخص.

إيجابيات رمز المشاركة:تغيير واحد يغير كل شيء.نموذج البيانات الموحد.هناك حقيقة واحدة فقط.(من الأسهل بكثير أن يكون الجميع في نفس الصفحة)

سلبيات رمز المشاركة:تغيير واحد يغير كل شيء..احرص.إذا كان هناك خلل واحد فيه، فإنه يؤثر على كل شيء.

إيجابيات النسخ/التفرع:عادةً ما يكون أسرع في تنفيذ ميزة معينة لعميل معين.يكون الاختراق أسرع عندما تدرك أن الافتراض A ينطبق فقط على السوقين B وC، وليس D.

سلبيات النسخ/التفرع:سيفشل واحد أو أكثر من المشاريع المنسوخة في النهاية، بسبب عدم وجود تماسك في التعليمات البرمجية الخاصة بك.كما قال أعلاه:تستغرق التغييرات الشاملة وقتًا أطول بكثير.

حظ سعيد.

Answer 3

لقد قلت "النسخ والتفرع" مما يقودني إلى الاعتقاد بأنك ربما لم تفكر في إدارة هذا "الشوكة" كفرع في نظام التحكم في المراجعة مثل SVN.من خلال القيام بذلك بهذه الطريقة، عندما تقوم بإعادة هيكلة الفرع لاستيعاب صناعة مختلفة، يمكنك دمج هذه التغييرات مرة أخرى في الصندوق الرئيسي بمساعدة نظام التحكم في المراجعة.

إذا كنت تتبع إستراتيجية طويلة المدى للانتقال إلى تطبيق واحد حيث يتم التحكم في جميع الاختلافات بواسطة ملف تكوين (أو قاعدة بيانات تكوين SQLITE)، فإن هذا الأسلوب سيساعدك.لا يتعين عليك دمج أي شيء حتى تكون واثقًا من أنك قمت بتعميمه على كلا الصناعتين، لذلك لا يزال بإمكانك بناء نظامين فريدين طالما كنت بحاجة إلى ذلك.لكنك لا تضع نفسك في الزاوية لأن كل ذلك موجود في شجرة كود مصدر واحدة، وجذع الصناعة القديمة، وفرع واحد لكل صناعة جديدة.

إذا كانت شركتك تريد حقًا مهاجمة صناعات متعددة، فلا أعتقد أن حل قاعدة بيانات التكوين سيلبي جميع احتياجاتك.ستظل بحاجة إلى وحدات تعليمات برمجية خاصة من نوع ما.يعد إنشاء بنية المكونات الإضافية أمرًا جيدًا لأنه سيساعد، خاصة إذا قمت بتضمين محرك برمجة نصية مثل Python في تطبيقك.ومع ذلك، لا أعتقد أن المكونات الإضافية ستكون قادرة على تلبية جميع متطلبات تنوع التعليمات البرمجية الخاصة بك عندما تصل إلى مقياس "آلاف الفئات".

أنت بحاجة إلى اتباع نهج عملي يسمح لك بإنشاء تطبيق منفصل اليوم للصناعة الجديدة، ولكنه يجعل من السهل نسبيًا دمج التحسينات في التطبيق الحالي مع تقدمك.قد لا تصل أبدًا إلى السعادة القصوى لصندوق واحد يضم آلاف الفئات والعديد من الصناعات، لكنك على الأقل ستكون قد روضت التعقيد، ولن يتعين عليك إلا التعامل مع الاختلافات المهمة حقًا حيث يوجد اختلاف حقيقي في احتياجات الصناعة.

لو كنت مكانك، فسأنظر أيضًا في جميع الميزات الموجودة في التطبيق والتي يمكن اعتبارها "تقارير" وأحاول استبعادها، وربما حتى في أداة إعداد التقارير الجاهزة.