عبادة البضائع في تطوير البرمجيات

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

مناقشات الصباح اليومية (الملقب ستاندوب اليومية)

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

سحابة النشر

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

تغطية الرمز مع اختبارات الوحدة

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

إدارة عملية التطوير

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

إدارة الفريق

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

كيف لا تصبح / لا تكون خبير بضائع

1. اتبع دائمًا نهجًا حاسمًا لإدخال كيانات جديدة (الخدمات والتقنيات). إذا كان هناك أشخاص في فريقك يعرفون MySQL جيدًا ولكنهم لم يعملوا مع Postgres ، فلا فائدة من اختيار Postgres إذا لم يمنحك هذا مزايا كبيرة.
2. يجب تكييف عملية التطوير مع الفريق والعمل. إذا كان Vasya يعمل على Scrum ويغطي كل شيء مع اختبارات الوحدة ، فإن هذا لا يعني أن هذا النهج سوف يكون مناسبًا لك أيضًا ، يجب عليك دائمًا إجراء تقييم نقدي ومقارنته مع الخيارات الأخرى (الشلال). كقاعدة عامة ، ما يصلح لفريق صغير يتوقف عن العمل لفريق كبير والعكس صحيح.
3. حدد نقاط قوة أعضاء الفريق واستخدمها إلى الحد الأقصى. سيؤدي ذلك إلى زيادة كفاءة الفريق بأكمله ، وسيكون الموظفون أكثر سعادة ، لأنهم يجلبون المزيد من الفوائد بأقل مجهود.