نستمر في مشاركة مقتطفات من
الدليل لأولئك الذين يستعدون لرئاسة فريق التطوير.
في الجزء السابق ، تحدثنا عن كل شيء غريب ، والذي يكمن في انتظار القائد الفني في المنصب الجديد ، ولكن الآن نعود إلى أشياء الأقارب والأصدقاء - في الواقع البرمجة. هنا ، يمكن أن يشعر مطور الأمس بعنصره ، لكنه ليس مضطرًا للاسترخاء - مجال المسؤولية ينمو ويتغير. تحت cat ، نقدم لمحة موجزة عن جميع المسؤوليات الجديدة ونصائح التكيف التي يجلبها Rainwater في كتابه.
الفرق الأساسي يكمن في اثنين من الفروق الدقيقة. أولاً ، الدخول قبل العملية كثيرًا ولا يتم إيقافها حتى النهاية المنتصرة. ثانياً ، بينما يركز المطور على المهمة الضيقة التي تم تعيينها له ، يراجع رئيسه المنتج بالكامل ، بينما لا ينسى الخوض في التفاصيل عندما يتطلب الموقف ذلك. دعنا نذهب مع المؤلف من أجل محاولة تحديد دور قائد الفريق في كل مرحلة من مراحل إنشاء التطبيق.
تعريف المتطلبات والمواصفات
يبدأ التكليد الجيد في العمل مع المنتج حتى عندما يكون في حالة ما حول الولادة - أي في شكل فكرة عامة أو طلب أو قائمة وظائف. ومع ذلك ، فأنت بحاجة إلى توضيح ذلك على الفور: تؤمن Rainwater بشدة بأنه لا ينبغي للمطور أن يشارك في عمل أحد المسوقين أو مدير المنتج - أو بالأحرى ، يجب عليه تجنب هذا السيناريو بكل قوته. لا يعني أنه كان من المستحيل أو المشين لـ "فني" فهم حقائق السوق والمتطلبات التجارية ، ولكن الجمع بين هذين الدورين أمر صعب للغاية. من بين أمور أخرى ، هناك خطر أكبر من أن يفوز المطور الداخلي وأن خصائص المنتج سوف تتناسب مع اهتمامات فريق المبرمجين ، بدلاً من المستخدم النهائي. من الأسهل والأكثر أمانًا العمل عندما تكون الرؤية العامة للمنتج من حيث وظائفه جاهزة بالفعل ويتم اختبارها للتأكد من صلاحيتها من قبل أشخاص مطلعين.
من أجل الاختلاط بين الدورتين ، غالبًا ما ينادي المطورون الذين ينتمون إلى تصنيف رعاة البقر في كثير من الأحيان - يتوقون إلى أوقات "المرآب" عندما تصنع فرق صغيرة المنتج بأكمله من وإلى وإلى هناك حاجة للتفاعل الخارجي. المؤلف في عجلة من أمره لتبديد كل الأوهام في هذه النتيجة: في الظروف الحديثة ، يجب أن يحدث التفاعل بين المجموعات الفنية وغير الفنية بشكل منتظم ، طوال دورة حياة التطبيق بأكملها. تعقد الاجتماعات الأولى للإعداد المشترك للمواصفات. يتعرف مدير التطوير (أو أحد المطورين الرائدين) على وصف المنتج ، ويستبعد كل ما يبدو له غير مبرر أو غير واقعي من الناحية الفنية ويلتقط الخطة النهائية لترجمتها إلى لغة التقنيات. ثم تجتمع المجموعات من وقت لآخر "للتحقق من الساعة" والتأكد من أن التطبيق لا ينحرف كثيرًا عن الخطة الأصلية.
التكرار الموصى به لمثل هذه الاجتماعات هو حوالي مرة واحدة في الأسبوع ، على الرغم من أنك تحتاج بالطبع إلى إجراء تعديلات على الوتيرة العامة للتنمية وميزات تنظيم العمليات لشركة معينة.
ستكون هناك حاجة أيضًا لعقد اجتماعات منتظمة لسبب آخر - من المرجح ألا تأتي محاولات الخروج عن المسار الأصلي فقط من جانب التطوير. معظم التطبيقات ، لكي تظل قادرة على المنافسة ، تنمو باستمرار باستخدام أدوات وقدرات إضافية. لذلك ، يمكن تكرار عملية النظر في الأفكار وتقييمها وتسربها إلى ما لا نهاية ، فقط على نطاق أصغر من المواصفات الأساسية. من المهم للغاية أن تحافظ Tehlid على مواكبة خطط تطوير المنتج - وهذا لا يمنحه مساحة للمناورة من وجهة نظر تنظيمية (تخصيص المسؤوليات وتحديد الشروط) فحسب ، بل يسمح لك أيضًا بحساب التبعات المسبقة للعواقب على النظام ككل وتوافقه و الاستدامة.
قبل الموافقة على تولي وظيفة جديدة للعمل ، يجب أن تسأل نفسك عددًا من الأسئلة:
- ما هو التأثير الذي سيحدثه التغيير المقترح على بنية النظام في الأجلين القصير والطويل؟
- كيف سيؤثر التغيير المقترح على البنية التحتية للشبكة التي سيحدث فيها؟
- كيف سيؤثر التغيير المقترح على قدرة المستخدم على التفاعل بفعالية وإنتاجية مع هذا المنتج؟
- ما هو تأثير التغيير المقترح على تصرفات الموظفين الذين يتعين عليهم العمل عن كثب معه - للتنفيذ ، لمرافقة؟
ستساعد مثل هذه الانعكاسات في تحديد المزالق وتحديد اتجاهات عامة للحوار مع المجموعات الأخرى.
تصميم
عندما تتم الموافقة على المتطلبات وتباركها من قبل جميع المشاركين في العملية ، فقد حان الوقت لما تسميه Rainwater تنسيق القرارات المعمارية والتصميم. بمعنى آخر ، يحتاج الدليل الفني إلى وصف النظام الذي سيؤدي الوظائف المحددة في مرحلة المواصفات ، والتفكير في المكونات المسؤولة عن إجراءات محددة. من الأهمية بمكان التصرف بهذا الترتيب:
العمارة أولا ، ثم المكونات.
يؤكد المؤلف هذا عدة مرات ، لأن العديد من المطورين الذين ليسوا على دراية بفن تصميم المنتج يقعون في هذا الفخ. يبدو من المنطقي أن تأخذ قائمة من المتطلبات ، وتصف المكونات اللازمة لكل منها ، واعتبر المنتج مزيجًا بسيطًا منها. ولكن في الواقع ، فإن هذا النهج الميكانيكي يؤدي إلى وحوش جامدة منظمة بشكل عشوائي تمتص جميع العصائر من المطورين المشاركين في دعم المشروع. لتجنب هذا ، تحتاج إلى الذهاب في الاتجاه الآخر ، من الكل إلى الخاص. لديك بالفعل رؤية وظيفية مشتركة للمنتج من منظور تطوير - تحتاج إلى "عكسه" في رؤيتك التقنية العامة من خلال منظور التطوير ، أي الهندسة المعمارية.
بناء العمارةإذا لجأنا إلى استعارة مخترقة ، فإن العمارة هي الهيكل العظمي للمنتج ، الذي يتم بناء عليه تجسيدًا للقرارات الخاصة بتنفيذ الإجراءات. نعيد إحياء هذا الاستعارة قليلاً ، مضيفين توضيحا: يجب شحذ الهيكل العظمي من أجل نمو أطراف جديدة. المطلبان الرئيسيان للهندسة المعمارية هما التنظيم المنطقي الواضح للمكونات والمرونة التي ستضيف مكونات جديدة مع نمو المشروع.
ربما يمكن اعتبار هذه المرحلة من التطوير هي الأكثر مسؤولية - يقول الخبراء إن هذا هو الإهمال الدقيق لقضايا الهندسة المعمارية التي تؤدي في معظم الأحيان إلى انهيار المشاريع. من بين الأسباب الشائعة للفشل ، يسمون:
- عدم وجود فكر ، منظمة قذرة (أو غيابها الكامل).
- صلابة مفرطة واستقامة النظام ، مما يمنع توسعه وفقًا للاحتياجات التجارية.
- الترابط المفرط للمكونات ، وعدم وجود مرونة في التكوين.
- التعقيد المفرط في المستويات العليا ، مما يجعل من الصعب تعديل المكونات الأساسية.
تبعا لذلك ، ينبغي التعامل مع مهمة بناء الهندسة بكل جدية ، وليس توفير الموارد. تذكر أنك تضع الأساس الذي يجب أن تعمل به حتى النهاية - يجب أن تصمد أمام جميع التغييرات التي تنتظر المشروع في المستقبل. هذه العملية إبداعية ورؤية إلى حد كبير ، ولكن الطرق القياسية للهيكلة مفيدة لموازنة النظام. على سبيل المثال ، ارسم رسم تخطيطي للكتل مع مجموعة كاملة من الاتصالات أو حتى قم بتطبيق تخطيط بسيط (مجموعة من المكونات ذات المستوى المنخفض ذات الحواجب وقيم الإرجاع) للتأكد من أن البنية تعمل في إسقاط رأسي. من المستحسن القيام بهذا الأخير قبل البدء في تطوير مكونات حقيقية كاملة المكونات - التخلص من الأخطاء بعناصر "لعبة" أسهل كثيرًا وغير مؤلم.
بنهاية العمل في هذه المرحلة ، يجب أن تكون مستعدًا للإجابة على الأسئلة التالية:
- كيف سيتفاعل المستخدم مع النظام؟
- ما المكونات التي يجب تجميعها لضمان عمل النظام؟
- ماذا ستكون آلية تفاعل المكونات التي تضمن عمل النظام؟
- ما هي التقنيات الأكثر ملاءمة لإنشاء هذا التطبيق؟
- كيف يفترض تسليم النظام للعميل؟
تخطيط المكوناتعندما يتم تطوير الإطار العام ، فقد حان الوقت للتعمق بشكل خاص وزرع المكونات ذات الصلة حاليًا في التركيب العضوي. تكمن الصعوبة الرئيسية هنا في تحمل المقياس الضروري للترابط. من ناحية ، لا ينبغي اعتبار المكونات حاويات معزولة تمامًا لمجموعات محددة من العمليات - بدلاً من ذلك ، كنظام من الأجهزة ، يتواصل كل منها مع الآخرين ، ولكنه يؤدي وظائفه. في الوقت نفسه ، يجب تجنب الترابط القوي بين المناطق ، مما يؤدي إلى تعديل مكون واحد إلى سلسلة كاملة من التغييرات ، أو حتى الأعطال ، في جميع أنحاء النظام.
تم تحديد حزمة التكنولوجيا في المرحلة الأخيرة ، والآن يتعين عليك فهمها بالتفصيل. في اختيار اللغة والمكتبات ، ومن المنطقي أيضًا أن يتم الاسترشاد ليس فقط بالدوافع المهنية ، ولكن أيضًا بالدوافع العملية الصارمة. قل ، هل سيكون لديك عدد كاف من الموظفين المؤهلين لدعم الأنظمة المبنية على أساس التقنيات المتقدمة أو النادرة أو المعقدة؟ والعكس بالعكس ، إذا أعطيت الأفضلية للتقنيات القديمة ، فكم هي واعدة - هل ستبقى تعمل طوال دورة الحياة بأكملها ، هل ستبدأ مشاكل التوافق؟ يجب مراعاة جميع المشكلات المتعلقة بحلول الأجهزة وإنشاء البنية التحتية وتكوينها وصيانتها بنفس العناية.
تطوير ومراقبة الجودة
وهكذا ، تم الانتهاء من التخطيط أخيرًا وسيبدأ العمل في المشروع - يبدأ التطوير الفعلي للتطبيق. يتمثل دور القائد الفني في هذه العملية بشكل أساسي في المراقبة ، بحيث يتم كل شيء وفقًا للشروط والمعايير ؛ يشارك بشكل مباشر في إنشاء الشفرة ، كقاعدة عامة ، فقط في حالات القوة القاهرة. بالنسبة للجزء الأكبر ، يؤدي الرأس وظائف شرطة الشفرة ، أي ، إجراء مراجعات نقدية منتظمة للكود للتأكد من أنها لا تتعارض مع الإطار المعماري والمبادئ الأساسية للبرمجة.
أثناء عمليات التفتيش ، قد يواجه قائد فني أنواعًا مختلفة من الأخطاء. يركز ماء المطر القارئ على نوعين:
- انتهاك المعايير . يتضمن ذلك التصميم والتسمية والتعليق - بشكل عام ، كل ما يساعد جهة خارجية على فهم ما يحدث في الكود ، بالإضافة إلى الإهمال بروح العديد من نقاط الخروج أو مشغلي GoTo المكروهين. من الضروري التأكد من أن جميع المشاركين في عملية التطوير يتحدثون نفس اللغة - وهذا يجعل الشفرة شفافة ويسمح لك بسرعة كشف التحركات الخاطئة. يجب أن تشير أسماء المعلمات والمتغيرات بوضوح إلى محتواها ، وينبغي أن تساعد التعليقات في تتبع شفرة أفكار المطور ، وتبرير قراراته. بالمناسبة ، إذا كان شخص ما من الفريق يرفض بعناد التعليق على الكود ، فإن الأمر يستحق النظر في السبب. غالبًا ما يكون هذا مجرد كسل أو خصوصية في التفكير ، ولكن في بعض الحالات ، قد يتضح أنه ليس من أعراض أن الموظف نفسه لا يفهم حقًا ما يفعله - الخلط أو مجرد نسخ أجزاء من رمز شخص آخر لسبب وجيه. من الضروري أيضًا مراقبة الأشخاص الذين يتجاهلون معالجة الأخطاء بشكل منتظم: فعدم القدرة على تحديد مصادر الأخطاء هو عيب خطير بالنسبة للمطور.
- ضعف الاتصال والترابط القوي هما مجالان للانتهاكات التي يمكن اعتبارها معًا ، لأن وجود أحدهما يدل على وجود الآخر. هنا ، في الواقع ، كل شيء يعتمد على درجة المتفرعة ونوعه. مع وجود درجة عالية من التفرع من حيث الإخراج ، فإن تشغيل الإجراء ينطوي على الوصول إلى العديد من الإجراءات الأخرى ، والتي ، بالطبع ، غير مرغوب فيها. التفرع عند المدخل ، على العكس من ذلك ، له تأثير إيجابي ، لأنه يشير إلى تغليف صارم. إذا كانت لديك شكوك عند تحليل الشفرة لهذه المعلمات ، فسيكون من الجيد وضع رسم تخطيطي للكتل مع تسلسل هرمي محدد للكائنات. يكشف على الفور كل ما تحتاج إلى معرفته: هل من الممكن تتبع نسب الكائن ، هل هناك منطق في ترتيب الأسهم ، أو هل يبدو كل شيء فوضويًا.
إذا كشفت شرطة الشفرة عن انتهاكات في هذه المناطق وغيرها ، فإن إجراء الاعتقال يبدو كالتالي: يتم إرسال الرمز مرة أخرى إلى المطور مع التعليقات اللازمة ، يتم تعليق العمل على المكون المقابل حتى يتم إصلاح العيوب. من المرغوب فيه للغاية أن يتعامل المطور مع هذا بنفسه ، ولكن مع النصائح - إذا كنت تفعل كل شيء من أجله ، يتم فقد عنصر التوجيه الخاص بفحص التعليمات البرمجية.
لا تؤجل المراجعة حتى أوقات أفضل. بادئ ذي بدء ، يمكن أن يعود بقوة في المستقبل ويتطلب المزيد من الموارد لإصلاح كرة الثلج كاملة من المشاكل. ثانياً ، تعمل نظرية النوافذ المكسورة أيضًا على البرمجة - حيث تعمل الشفرة غير المنظمة والمربكة على إنشاء كود غير مرتب ومربك أكثر ، لأنه ببساطة يبدو صحيحًا.
أخيرًا ، عند الحديث عن مراقبة الجودة ، لا يسع المرء إلا أن يتطرق إلى مشكلة العامل البشري الشهير. توصي شركة Rainwater بأن يتخذ المدير موقعًا متوسطًا. درجة من المقاومة للتداخل مع الكود طبيعية ولطيفة. إن الاستعداد الكامل لاتباع تعليمات شخص آخر وقبول رأي شخص آخر يجب أن ينبهك - غالبًا ما يعني هذا أن المطور ، في الواقع ، لا يهتم بما يصدره. ولكن من ناحية أخرى ، فإن عدم القدرة على إدراك النقد السليم يعيق كل من النمو المهني والعمل الجماعي. وبناءً على ذلك ، سيتعين على هذه التقنية أن تنمو بشرة أكثر ثخانة وألا تخشى الإصرار من تلقاء نفسها ، دون رد فعل سلبي على قلبها.
تجريب
هنا ، من المهم للقائد أن يضع في اعتباره قاعدتين أساسيتين: يجب إجراء الاختبار وتنظيم مسؤوليته على عاتقك. إذا كان لدى الشركة قسم اختبار يشارك بشكل طبيعي في العمليات ، فلن تكون هناك مشاكل في ذلك. إذا لم يكن الأمر كذلك ، فسوف يتعين عليك تخصيص مورد من احتياطياتك الخاصة لهذه المسألة.
في السيناريو الثاني ، وفقًا للمؤلف ، هناك مزايا معينة: الاختبار مهارة مفيدة للمطور. من المفيد بشكل خاص جذب القادمين الجدد إلى هذه المهام ، حتى يكتسبوا مؤهلات بسرعة. في البداية ، يمكنك القيام بمهام الاختبار لمدة تصل إلى نصف وقت العمل.
بخلاف ذلك ، لضمان جودة فحص جيدة ، من الضروري التأكد من عدم طهي المنتج طوال الوقت في نفس المجموعة - من الناحية المثالية ، يجب اختباره "على الجانب". إذا كان لدى الشركة العديد من فرق التطوير ، فقد يكون من المنطقي الاتفاق مع القادة الآخرين لإنشاء مجموعة مختلطة.