في نوربيت نتعامل مع حلول SRM . سنخبرك اليوم عن مشروع خاص لفريقنا - تطوير منصة NBT BPMS. لم نقم فقط بإنشاء حل تجاري للعميل ، ولكننا طورنا منتجنا الخاص من البداية - كل هذا يتضمن نهجًا مختلفًا تمامًا للتصميم والتطوير وإدارة الفريق وتنظيم عمليات تسليم التغيير وتخطيط الإصدار.
بشكل عام ، المقالة ليست فقط حول KDPV الجميل. سوف تتعلم أيضًا:
- حول خبرتنا في تصميم بنية الخدمات المصغرة (اختيار الأدوات ، وأساليب استخدام هذه الأدوات ، أي تجريد استخدامها) ؛
- حول تطوير مصمم كائنات الأعمال وتنفيذ مصمم للعمليات التجارية في الحل لضمان نهج تطوير الكود المنخفض ؛
- حول كيفية تنظيم العمل في المشروع وحفظنا للمطورين من بعض الجوانب الروتينية أو المشتتة للانتباه عند العمل على النظام (تفاعلات مجردة بين الخدمات ، والتوليد التلقائي للكود ، وأجواء الفريق) ؛
- وحول الميم الذي ساعدنا في الأوقات الصعبة.
يعمل قسمنا في شركة NORBIT بشكل أساسي في أتمتة عمليات الشراء ، حيث يقوم بإنشاء أنواع مختلفة من الحلول على منصة .Net.
بدأ تطوير مثل هذه الحلول مع ASP.NET WebForms ، ثم تم إنشاء إصدارات جديدة من هذه الحلول على أساس ASP.NET MVC. بالإضافة إلى التطورات في .NET ، كان لدينا ولا يزال لدينا مشاريع وحلول أخرى ، ولكن مع ذلك ، فإن التطوير في .NET يمثل حوالي 80٪ من جميع مشاريع القسم.
تشير قيود كل من ASP.NET WebForms و ASP.NET MVC إلى أنه لكي تعمل الحلول على هذه الأنظمة الأساسية ، كان النشر على نظام تشغيل لعائلة Windows Server مطلوبًا ، وعلى جانب DB (قاعدة البيانات) ، تم تنفيذ حجم المنطق الذي لم يسمح بانتقال سريع وغير مؤلم على نظام DBMS غير MS SQL Server. هذا لم ينص على أي عقبات وصعوبات قبل بدء التحول الهائل إلى البرمجيات المحلية.
بدءًا من 2014-2015 ، بدأ سوق تكنولوجيا المعلومات في التحرك بجدية كبيرة نحو استبدال الواردات ، وكانت مسألة نشر أنظمتنا على أنظمة التشغيل وأنظمة إدارة قواعد البيانات (DBMS) التي تناسب المتطلبات الجديدة حادة للغاية. في الواقع ، أصبح السؤال رقم 1كنا بحاجة إلى حلها بحيث يمكن أن تغطي حلولنا متطلبات العملاء المحتملين على المدى الطويل.
في الوقت نفسه ، مع وجود كفاءات قوية وفريق كبير إلى حد ما من مطوري .NET ، لم يكن من المنطقي البدء في تطوير نواة جديدة متعددة الأنظمة بخلاف .NET. كان إصدار منصة .NET Core مفتوحة المصدر موضع ترحيب كبير بالنسبة لنا ، بما في ذلك بسبب توافقه مع أنظمة التشغيل مثل Windows و Linux و macOS.
السؤال رقم 2 ، الذي كنا بحاجة إلى حله ، هو أن معظم الحلول التي تم إنشاؤها مسبقًا افترضت البرمجة الإلزامية لإضافة سمات كائنات الأعمال أو تغيير عمليات الأعمال في النظام.
يرتبط بجانبين.
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
و السؤال رقم 3 ، وهو ما تم تواجه لسنوات عديدة، هو النقص في البنى النظم التي يتم إنشاؤها، والتي لا تسمح لإعادة كتابة بسرعة جزء من دون الحاجة إلى إعادة كتابة وحدات فردية، أو يخلق عتبة دخول عالية بما فيه الكفاية للمبرمجين ومحللين واختبار عند الاتصال المشاريع.
كان هناك العديد من الأسئلة والمشكلات عند مدخل المشروع ، والتي سيتم مناقشتها لاحقًا. لكن هؤلاء الثلاثة (استبدال الاستيراد والمصدر المفتوح ، والرمز المنخفض ، وعتبة الدخول المنخفضة ومعدل الانغماس السريع لأعضاء الفريق الجدد) نعتبر العناصر الرئيسية التي يتعين علينا حلها.
التصميم
قادنا التفكير في هذه الأسئلة إلى إدراك أننا بحاجة إلى نوع من المُنشئ يمكن للمحللين "اللعب" به وتصميم نظام (كائنات الأعمال وعمليات الأعمال) وفقًا لاحتياجات العميل. يبدو الأمر جريئًا ، لكنه أكثر إثارة من كتابة نظام آخر للعميل. في الواقع ، قررنا أن نصنع منتجنا في شكل مُنشئ ونطوره.
بالتأكيد لم نتوصل إلى أي شيء ثوري ، وهناك الكثير من المنتجات المماثلة في السوق ، ولكن كان من المهم بشكل أساسي بالنسبة لنا حل أسئلتنا المتراكمة ، خاصة أنه ، للأسباب الموضحة سابقًا ، كان من الصعب علينا ، بعبارة ملطفة ، اتباع مسار إعادة هيكلة الأنظمة الحالية.
في مرحلة التصميم ، كان علينا إعادة التفكير في حقيقة أننا لا نعرف دائمًا مقدمًا من هو عميلنا المحتمل ، كبيرًا كان أم صغيرًا ، متطلبًا أو مخلصًا ، وما هي العمليات التجارية لديه ، وما نوع البنية التحتية. بدأت بعض متطلبات النظام المستقبلي في الظهور من تلقاء نفسها: تحتاج إلى توسيع نطاق ، تحتاج إلى منصة مشتركة ، تحتاج إلى تخصيص مرن وسريع لأشياء الأعمال / العمليات التجارية ، وواجهة ، وربما "عربة وعربة صغيرة" من عمليات التكامل. أصبح الأمر مخيفًا ، مخيفًا جدًا.
صورتنا المفضلة ولكن ، كما يقول أحد قادة فريقنا ، "يحتاج الفيل إلى أن يؤكل شيئًا فشيئًا ، بدءًا من القدم". في هذه المرحلة ، حددنا لأنفسنا مهمتين: اختيار بنية الخدمات المصغرة واختيار الأدوات. نعم، فقط microservice على الفور (توصي مارتن فاولر MonolithFirst ، ولكن قررنا أن يعصي عليه وسلم)، لأنه مع كتل نحن منذ فترة طويلة على "أنت" وحان الوقت لقبول التحدي للمضي قدما. لكن على محمل الجد ، فإن شرط القياس الأفقي للنظام وحده يكفي تمامًا ، في رأينا.
اختيار العمارة والأدوات
عند تصميم العمارة ، سعينا إلى عدة أهداف:
- تجريد الأدوات المستخدمة بحيث تكون هناك فرصة في أي وقت لاستبدال أداة غير مناسبة بأداة أخرى ؛
- ( , );
- , .
نظرًا لأن فريقنا متخصص في تقنيات Microsoft ، فقد تم اختيار .NET Core الإصدار 2.1 كنظام أساسي للتنفيذ. في الوقت الذي بدأ فيه تطوير منتجنا ، كان هذا الإصدار هو LTS (دعم طويل الأجل) ، وكان هذا معيارًا مهمًا بالنسبة لنا ، نظرًا لأن بعض أنظمة التشغيل المحلية (التي يمكننا نشر النظام عليها) تدعم فقط إصدارات .NET Core LTS ...
قرروا إنشاء الواجهة الأمامية في React + TypeScript ، حيث يسهل تعلمها. قررنا تعزيز نهج المكدس الكامل للمطورين.
قررنا جعل الاتصال بين الخدمات متزامنًا، لأنه كان من المفترض أن تكون سلاسل الاتصال الخاصة بنا قصيرة ، ولا يزال الاتصال بين الخدمات مجردة. خدمة تستدعي خدمة أخرى من خلال وكيل مجرد. ويمكن أن تحتوي على أي منطق. في حالتنا ، هذه دعوة لخدمة أخرى عبر http عبر Service Discovery. سمح لنا هذا التصميم ، من ناحية ، بتبسيط حياة المطورين (يمكنهم ببساطة استخدام واجهة الخدمة للاتصال بها ، ولكن في الواقع ، في حاوية خدمة ASP.NET Core ، يكون التنفيذ المسجل لهذه الواجهة هو نفس الوكيل) ، ومن ناحية أخرى - لتوفير القياس الأفقي للنظام تلقائيًا ، نظرًا لأننا نسأل دائمًا Service Discovery عن كيفية الاتصال بخدمة ما ، وهذا بدوره يمكن أن يعيد إحدى مثيلات هذه الخدمة قيد التشغيل.
في مرحلة ما ، أصبح هيكل الخدمة قياسيًا ، وقمنا بعمل ملحقات لـ Visual Studio ، والتي ، عند إضافة مشروع جديد إلى الحل ، تنشئ هيكل مشروع مع الحد الأدنى من تنفيذ الخدمة ، مرة أخرى ، حتى لا يضطر المطورون إلى القيام بهذا الروتين. بالإضافة إلى ذلك ، قمنا بعمل عدة نصوص لإطلاق النظام بأكمله بحركة طفيفة لليد (فكرنا لاحقًا في نفس النشر السريع لمنسق خفيف الوزن من المطور).
كانت عملية الاختيار مثيرة للاهتمام أيضًا. كان علينا أن نقرر الوظيفة التي نكتبها بأنفسنا وأيها نأخذها "خارج الصندوق" (نتحدث عن الأدوات الحالية) ، ولكن ، بالطبع ، نستخلص كل التفاعلات معها ، بحيث يمكن ، إذا لزم الأمر ، استبدال هذه الأداة أو المكتبة بتطبيق آخر. احتجنا إلى الأدوات التالية: محرك بحث ، محرك عمليات الأعمال (BPMN Engine) ، بروتوكول اكتشاف الخدمة (اكتشاف الخدمة) ، المجدول. كانت المعايير مختلفة: التراخيص ، وسرعة العمل ، وسرعة انغماس فريق المشروع ، إلخ. والنتيجة هي القائمة التالية: Elasticsearch، Camunda، Consul، Hangfire.
قدموا على الفور دعمًا لـ PostgreSQL و SQL Server على الأقل ، لكنهم ركزوا بشكل أساسي على PostgreSQL والنشر ضمن Linux. البرمجيات الحرة ، كما تعلم. في هذا الصدد ، حدثت قصة غريبة. لقد وضعنا الدعم لـ SQL Server في المراحل المبكرة ، لكننا لم نتوقع بشكل خاص أن بعض عملائنا المحتملين سيكونون مهتمين بالنشر على Windows + SQL Server ، لذلك قمنا بتأجيل اختبار هذا التكوين إلى وقت لاحق (بعد كل شيء ، من المعروف دائمًا مسبقًا ما هي البيئة التي يمتلكها العميل؟!) ... وبعد ذلك في أحد الأيام ، أثناء عمل منصة اختبار أخرى لعميل محتمل ، كنا جاهزين بالفعل لنشر AltLinux + PostgreSQL كالمعتاد ، لكننا اكتشفنا فجأة أن العميل مع ذلك غير رأيه وقرر النشر على Windows + SQL Server ، ولدينا يومان للقيام بكل شيء إعداد. لحسن الحظ ، أصبحت الشفرة المكتوبة منذ فترة طويلة والمنسية مفيدة ،الذي قدم لنا هذا الدعم مع تحسينات طفيفة ، وتمكنا من إعداد كل شيء في الوقت المحدد ، وبدأ النظام في العمل كما لو لم يحدث شيء (المجد لـ .NET Core).
تنفيذ أفكار العمل
اقتربنا من التنفيذ بقائمة معدة من مراحل العمل ، وكان أهمها الحصول على MVP (الحد الأدنى من المنتجات القابلة للتطبيق) في المستقبل القريب. منذ التكرارات الأولى تقريبًا ، بدأنا العمل مع التركيز على الحصول على نموذج أولي في أسرع وقت ممكن مع جزء مرئي يمكن عرضه للعملاء (الذين كانوا قادتنا في البداية) بشكل دوري. ساهم هذا النهج ، كما هو متوقع ، في إعادة التفكير في بعض المفاهيم التي تم تصورها مسبقًا. تمكنت من التقاط العديد من التناقضات ومحاربتها مسبقًا. يتعلق الأمر بتصميم Web API للاتصال بالواجهة الأمامية والخلفية.
مُنشئ كائن الأعمال
لقد سبق ذكره أعلاه أن إحدى الأفكار الرئيسية للمنتج هي القدرة على إنشاء هيكل كائن أعمال بواسطة مستخدم مكون. لقد بدأنا بالفعل بتنفيذ مُنشئ كائنات الأعمال. كانت النسخ الأولى بالطبع أكثر تصورية ، لكنها قدمت لنا فيما بعد طعامًا غنيًا للتفكير. تطورت كائنات العمل التي كانت ذات يوم بسيطة مع بضع حقول بسيطة في وقت لاحق إلى وحدات متعددة الوظائف متعددة المستويات مع مجموعة واسعة من جميع أنواع الإعدادات. لقد تعلمنا كيفية تخصيص ليس فقط الحقول البسيطة ، ولكن أيضًا الحقول مع الاختيار من الدلائل الهرمية ، ومجموعات الكائنات ذات الصلة مع التصفية ، وما إلى ذلك.
يحتوي كائن الأعمال الذي تم إنشاؤه بواسطة فأرة التهيئة على بيانات وصفية كافية لتتمكن من جمع سجلات مخصصة قابلة للبحث ونماذج عرض مختلفة.
إن مسألة التحقق من كائنات الأعمال لم تسلمنا أيضًا. اكتشفنا بسرعة أن التحقق من الصحة لا يمكن إلا أن يكون مصحوبًا بمنطق العمل المطلوب في مرحلة ملء كائن الأعمال بالبيانات. "إذا كان" الحقل 1 "يحتوي على" القيمة 1 "، فإن" الحقل 2 "يجب أن يكون مخفيًا" أو "الحقل 1 هو مجموع الحقل 2 والحقل 3" هما مجرد مثالين من أبسط الأمثلة التي يمكن تقديمها. ما هي مدتها قصيرة ، ولدينا الآن محرك حدث يمكن من خلاله تكوين مثل هذا السلوك. يمكن أيضًا تكوين الأحداث باستخدام الماوس. تم بالفعل تنفيذ العديد من الخيارات ، بما في ذلك الحسابات المعقدة. لكن هذا موضوع لمحادثة أخرى. يرجى الكتابة في التعليقات إذا قمت بحل مشكلة مماثلة ، فسيكون من المثير للاهتمام تبادل المشاعر.
مصمم إجراءات الأعمال
كما نود أن نكرر: "من يحتاج إلى كائنات أعمال بدون عمليات تجارية؟"
النتائج
مضى عام ونصف على بدء المشروع. لقد زاد الفريق عشرة أضعاف ، ونما
أول شيء يبدو رائعًا هو حقيقة أنه كلما زاد عدد الوظائف التي نقدمها ، زاد عدد الأفكار التي نحصل عليها. يبدو أننا لا ننتقل من بداية المشروع إلى اكتماله ، ولكن ببساطة من البداية وما بعدها - هذا جانب مهم. بعد سنوات عديدة من دعم الحلول الجاهزة (وهذا يحدث كثيرًا في حياة متخصص تكنولوجيا المعلومات) ، فإن هذه الحالة محفزة للغاية.
ثانياالشعور الكبير هو مشاهدة مثل هذا الفريق المتحمس وأن تكون بداخله. إن عملية إنشاء منتج جديد ليست مجرد سلسلة من المهام والمراحل. هذا هو قبل كل شيء الجو. جو من حقيقة أنك كثيرًا ما تفعل شيئًا لم تفعله من قبل ، على الرغم من أنك شاركت في عشرات المشاريع. كل عضو في الفريق يتنفسه وفي وقت ما يدرك أنه غادر منطقة الراحة بعد أول نفس. وأصعب وأهم مهمة هي جعل هذا الجو منعشًا ومريحًا وممتعًا. لا يمكننا الاختباء من الأخطاء ، والمواعيد النهائية ، وما إلى ذلك ، ولكن الافتقار إلى بيئة داعمة نجد أنفسنا فيها يمكن أن يكون أكثر تدميراً.
نحاول أن نولي اهتماما خاصا لعملية تطوير منتجاتنا. هذه العملية ليست ثابتة. يخضع لتغييرات ، إذا لزم الأمر ، لكنه يجعل من الممكن حل مشاكله بشكل مريح ومساعدة زملائه على القيام بذلك.
ملاحظة: من الصعب وصف كل شيء بالتفصيل في مقال واحد ، لذلك اتضح أنه مزيد من نظرة عامة. نأمل حقًا أن تكون قد وجدت شيئًا مثيرًا للاهتمام فيه ، وسنكون سعداء للإجابة على أسئلتك في التعليقات ، أو وصف بعض جوانب نظامنا بمزيد من التفصيل في مقال منفصل.