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

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

حول سبب التناقض

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

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

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

جزء من اليوم نعمل من أجل أنفسنا ، وجزء من اليوم لصاحب العمل أو العميل. سأسمح لنفسي بالتعبير عن هذا باستخدام الصيغة التالية للقيمة:

حيث

ج هو رأس المال الثابت ، أي أدوات المنظمة التي تسمح لها بالقيام بأنشطتها (أجهزة الكمبيوتر والبرامج وغيرها).
v - رواتب الموظفين.
م هو الربح النظري لأولئك الذين يملكون الإنتاج.

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

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

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

  
  

• ث - يمكن للعميل رفع سعر منتجاته وخدماته. يمكن للاحتكارات جيدًا زيادة التكلفة والأرجح أنها تفعل ذلك. لكن من المرجح أن العميل يهتز دائمًا بظروف السوق.

  
  

• v - يمكنك التخلي عن راتب شخص آخر ، وهناك خيارات.
  1) سوف تضحي لك. ستقوم بمعالجة أو إنشاء مشروع مفتوح المصدر يساعدك في العمل.
  2) يمكنك أتمتة عمل شخص آخر ، مما سيتيح لعدد أقل من الناس استخدامه.

  
  

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

  
  

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

تناقض المتطلبات

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

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

للعثور على قاسم مشترك ، أقترح طرح الأسئلة التالية على العميل قبل كل مشروع جديد:

• ماذا نفعل بالضبط للعميل ، ما هي الفائدة المتوقعة؟
• تواتر انطباق هذا الحل.
• احتمال حدوث تغييرات / متطلبات التوسع.
• هل هناك اتصال مع الأنظمة / الخدمات / السياقات الأخرى؟

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

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

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

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

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

تحدد الدورة التكنولوجية (في نفس الوقت) التنمية - للدخول إلى المرحلة التالية من التطوير ، من الضروري تجاوز العملية التكنولوجية الحالية. أي توسيع ممارساتك ، جرب شيئًا جديدًا ، وقم بإعداد تجارب محكومة.

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

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

من ميزان المتطلبات إلى توازن العمل

عندما نتحدث عن دورة حياة البرنامج ، لن يتذكر المدربون العصريون ومدربو Agile الرسم التخطيطي الشهير لـ I. Adizes.

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

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

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

في الشكل أعلاه ، تبدو فكرتي عن كيفية قضاء الوقت المستغرق في تنفيذ فرصة العمل X والعمارة Y ، حيث يعكس المحور Z فائدة المنتج.

استنتاج

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

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

أوصي بالنظر في العلاقة بين التوليف والأعمال في تقرير من حروب Cyril Skrygan Platform (IDE) .