🛍️ 🤴🏼 👩‍🏭 لعنة CRM القديمة 🆔 🔤 🔹

طوال العام الماضي ، أنهى رفاقنا CRM 2.0 مع BPMS Camunda وعشر عمليات فقط بدلاً من مئات الحالات ، ثم حاولوا طرحه للمستخدمين والخدمات دون التخلي عن أي شيء. آمل أنه بعد قطع أول tcm-ku (الجزء الأقدم من كل Skyeng) من نظامنا البيئي ، سيتشاركون أشعل النار ويكتشفون هنا.

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

مرحبًا ، أنا نفس "Seryozha from Bryansk" الذي قرر زيادة المعرفة التنموية من خلال المدونات والتسجيلات الصوتية حول موضوع PHP. أريد هذا العام إضافة بودكاست إلى أنشطتي: دعوة زملاء الصناعة إليه. في الحلقة الأولى قصة الانتقال من أول Zend إلى Symfony. إذا كنت تريد المزيد من التفاصيل الفنية ، فاطلع أيضًا على حديث ديما على Youtube . حسنًا ، في مناقشتنا بعد التقرير ستعرف:

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

لماذا أي وثائق إذا كانت لا تكذب ، إنها تكذب ،

وكيف يتم تنظيم عملية إعادة الهيكلة لمدة عامين دون التوقف عن إنتاج الميزات باستخدام مثال مشروع حقيقي وفريق.

استمتع بالقراءة أو الاستماع .

ما الأطر التي تم اختيارها بين 2011؟ وكيفية اختيار واحد جديد في 2016

ديما ، فينام: لقد بحثت بشكل خاص في التحضير للإصدار: لدينا بالضبط 4600 ملف في الأب ، حيث لا يكون رمزنا بالضبط بائعًا ، وليس أي شبيبة. هذا الأب يزن 16 مترا. والالتزام الأول الذي كنا سنفعله بالفعل في ديسمبر 2011 - مؤلفه لا يزال يعمل ، هذا هو قائد فريقنا.

في البداية ، تم تحديد المكدس بشكل صحيح. وحتى في عام 2012 ، كانت حديثة جدًا - كانت Zend الأولى ذات صلة تمامًا. ثم عملت في وظيفة أخرى ، لكنني أتذكر أنه في الثاني عشر في مكان ما في أواخر الربيع ، اخترنا المكدس لمشروع جديد. نظرنا إلى:

Zend - الثانية خرجت للتو ، لكنها كانت صغيرة جدًا ، ولم يكن هناك مجتمع له ،

أول Yii - لكننا لم نحب مفهوم ActiveRecord ،

فالكون ،

وشيء آخر من الغريب.

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

في النهاية ، توقفت Zend الأولى ببساطة عن دعمها. على سبيل المثال ، في الإصدار 7.0 ما زالوا يطلقون تصحيحًا للتحديث الأمني ، وقمنا بتصحيح 7.2 و 7.3 بأنفسنا.

لقد انسحبنا قليلاً مع بداية عملية النقل.

لم يكن هناك خطر عالمي - نظرنا للتو إلى ما هو حديث وملائم. مقارنةً بالمشاريع الأخرى: نحن لسنا فريق PHP الوحيد في الشركة. لقد أدركنا أن Symfony كانت سعيدة مع الجميع - فقد بدا وكأنه مشروع سيعيش لعدة سنوات ، ولديه مجتمع واسع ، والعديد من المكتبات الجاهزة ، والمرافق الجديدة ، وما إلى ذلك.

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

حسنا. لقد اخترنا إطار عمل. ماذا بعد؟

Seryozha ، Skyeng: هناك طريقتان - يمكنك إعادة كتابة كل شيء في وقت واحد. يمكنك محاولة السحب والإفلات ببطء. من أين بدأت؟

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

هناك مبدأ: أول 80٪ من العمل يستغرق 80٪ من الوقت. ستستغرق نسبة 20٪ المتبقية من العمل 80٪ أخرى من الوقت.

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

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

ثم تذكرنا تجربة أخرى كان لدى فريقنا بالفعل.

هذه هي تجربة إعادة كتابة طبقة للوصول إلى البيانات. لأنه ذات مرة ، مع أول Zend ، تم اختيار Mongo كقاعدة بيانات رئيسية. لكن الممارسة أظهرت أن الاختيار ليس صحيحًا تمامًا.

Seryozha ، Skyeng: نعم ، لديك كل الاتصالات العلائقية ، لكنك اخترت قاعدة بيانات موجهة نحو المستندات.

ديما ، فينام: نعم ، وعندما وصلت ، كان الرجال في طور النسخ من مونغو إلى PostgreSQL ... ولدينا فكرة أن لدينا طبقة وصول إلى البيانات. ونظرًا لأننا نعرف بالفعل كيفية إعادة كتابة الطبقات للوصول إلى البيانات ، فربما نأخذها على نطاق أوسع قليلاً ونستغل طبقة ORM على الفور.

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

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

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

مسكت البق ، تدحرجت ، خرجت

Seryozha ، Skyeng: مع ذلك ، إعادة البيع هي أمر بالغ الأهمية ، كيف يمكنك تأمين نفسك؟

ديما ، فينام: لدينا عدد من اختبارات الوحدة - وهي تغطي النقاط الرئيسية. هناك عدد من الاختبارات الوظيفية المؤتمتة من قبل مختبرينا. المهمة الرئيسية لإدارة علاقات العملاء هي العمل مع البيانات. وللاختبار بدون بيانات ، مع اختبارات الوحدة ، ليس من الممكن دائمًا: من السهل إرسال حزمة ، وتحقق من معالجتها بشكل طبيعي ، وأنه تم إنشاء كيان بالمعلمات الضرورية عليه.

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

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

Seryozha ، Skyeng: بعد أن قطعت كل الطريق ، ولكن الآن ربما يكون الأمر أكثر من نصف الطريق ، فماذا تنصح بعد ذلك؟

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

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

ليس في الخطوات الأولى ، ولكن عندما يكون لديك بالفعل شيء مكتوب ، خذها على هذا النحو ، وقم بالتصوير لمدة عام مقدمًا ، وقم بتنظيم آلة التوقيت المحلي هذه ، وتأكد من أنك تفعل كل شيء بشكل صحيح - فهذا سيعطيك القوة. وسوف تذهب أبعد من ذلك.

ملاحظة

شكرا للقراءة والاستماع. يمكن العثور على المزيد من ملفات بودكاست PHP هنا .

وإذا كنت تريد المزيد من التقارير والمحادثات المثيرة للاهتمام حولها ، "تعال" إلى اجتماع PHP الافتراضي الثالث في 30 مايو.

لعنة CRM القديمة