كيف تعيش وتتطور في مشاريع ذات تاريخ. ما يمنح المطور خبرة العمل مع قاعدة أكواد كبيرة ، ولماذا لا توجد حاجة للسعي لإعادة كتابة كل شيء من البداية ، حتى لو كنت تريد ذلك حقًا.
المحتوى
- لمن هذا النص
- ما يمكنك تعلمه من مشروع القصة
- ما هي الأسئلة التي يجب طرحها في مقابلة
- نصائح لأولئك الذين بدأوا للتو العمل في مشروع قديم
- موجز
أنا بافل نوفيكوف ، أشارك في تطوير تطبيقات الهاتف المحمول "مستندات MyOffice" و "MyOffice Mail". هذا تطبيق للتعاون مع المستندات وعميل البريد الإلكتروني ، والذي بدأ إنشاؤه في عام 2013 ، بحيث يمكن تسميتها بالمشاريع ذات قاعدة الرموز الكبيرة ، حيث يوجد مكان يتضمن الإرث.
لا تنطبق التجربة الموضحة هنا فقط على العمل على تطبيقات الهاتف المحمول والمقاييس لتطوير التطبيقات بشكل عام.
إخلاء المسؤولية للصغار
في هذا المقال ، جمعت أفكارًا حول عملي بناءً على الخبرة التي أمتلكها حتى الآن. أي مقالات من هذا النوع تكون ذاتية للغاية دائمًا. أنا متأكد من أن هناك أشخاصًا لديهم تجارب تتعارض مع ملاحظاتي. سأكون سعيدًا لمناقشة هذه التناقضات في التعليقات.
لمن هذا النص
النص مخصص لكل من أولئك الذين يعتبرون أنفسهم على مستوى المبتدئين وأولئك الذين يقعون في الفئة المتوسطة / العليا.
هناك الكثير لنتعلمه من العمل مع المشاريع طويلة العمر في أي مستوى من مستويات التطوير. لتكون على نفس الطول الموجي لفهم المستويات ، اقرأ منشورات Vastrika: تسجيل الدخول و K - Team . يعجبني تصنيفه لمستويات المطورين ، وسألتزم به في المستقبل.
في الكتلة التالية ، سنحلل بإيجاز ما هو الاستخدام لكل مستوى من المستويات في المشاريع الطويلة.
نجارة
مهمة المطورين المبتدئين هي زيادة تطوير المهارات التقنية إلى أقصى حد. يتم استخدام كل شيء: اللغات ، والأطر ، والمكتبات ، وأساليب التطوير ، إلخ. في أي مشروع به فريق قوي ، يمكنك تعلم حل المشكلات المختلفة.
ولكن في المشاريع الناضجة ، أولاً ، ستتاح لك الفرصة للتعمق في أي منطقة ، وثانيًا ، ستكون قادرًا على دراسة أمثلة للقرارات الناجحة وغير الناجحة. التعلم من أخطاء الآخرين مكلف. خاصة إذا كان هناك زملاء أكثر خبرة في الجوار يمكنهم أن يشرحوا لك بالتفصيل معنى هذه الأخطاء وكيف يمكنك تجنبها.
الأوسط
تتمثل مهمة المطور الأوسط في زيادة استقلاليته. يجب أن تصبح عضوًا في الفريق يمكن الوثوق به في أي مهمة تقريبًا في المشروع. هذا يعني أنه كلما زادت المهام المتنوعة في المشروع ، زادت مناطق النمو المحتملة لديك.
أول
وظيفة كبير المطورين هي أن تفهم تمامًا أنك لا تحصل على أجر مقابل الكود ، ولكن مقابل حل المشكلات. في بعض الأحيان (في كثير من الأحيان حتى الآن) من خلال كتابة التعليمات البرمجية ، وأحيانًا من خلال إدارة مطورين آخرين ، وأحيانًا من خلال التواصل مع غير المطورين. المشاريع الناضجة هي مجرد مخزن للمهام التي يمكن ويجب حلها.
بعد ذلك ، سأخوض في مزيد من التفاصيل حول بعض الأشياء التي يمكنك تعلمها من المشاريع الحالية.
وهنا تراث؟
تحتاج أولاً إلى فهم المصطلحات. لقد اكتسب مفهوم "الإرث" دلالة سلبية منذ فترة طويلة ، ولكن ما هو بالضبط تأثير الكود القديم؟
يجادل مايكل فيذرز ، مؤسس R7K Research & Conveyance ، بأن الكود القديم ليس رمزًا لا تغطيه الاختبارات. ميزة هذا النهج أنه ، للوهلة الأولى ، يدعي أنه موضوعي. لكن في الواقع ، يمكن أن يكون هناك سيناريوهان:
- هناك اختبارات ، لكنها مكتوبة بشكل سيئ: مربك ، هش ، غير منظم بشكل واضح.
- لا توجد معايير ، ولكن الكود مصمم بشكل جيد للغاية. هذا يجعل من الممكن تغييره بأمان نسبيًا ، وفي هذه الحالة سيسمح لك بكتابة اختبارات له بسرعة في المستقبل.
نظرة أخرى على ماهية الإرث من المطور Dro Helper (Dror Helper): لم يعد مصممًا هندسيًا - مصححًا واختراقًا باستمرار ("رمز قديم - رمز - رمز مكسور باستمرار ومدعوم بالعكازات بدلاً من تطويره") ... يعتقد
مطور الويب نيكولاس كارلو أن الكود القديم هو رمز غير مريح للعمل به. من كل هذا ، يمكننا أن نستنتج أن الإرث هو بالأحرى خاصية ذاتية للشفرة. قد تعمل الشفرة نفسها وقد لا تعمل ، ولكنها ستصبح قديمة عندما يظهر مطور لا يمكنه تعديله بشكل فعال.
سمة موضوعية أخرى نسبيًا لتقييم Legacy هي الإجابة على السؤال "هل هناك أي تبعيات غير مدعومة في المشروع". لا يمكن إنشاء الكود إلا من خلال بعض إصدارات المترجم المتقادمة المحددة. أو قام المؤلفون أنفسهم بتصحيح بعض المكتبات الخارجية ، وأصبحت الآن جزءًا من المشروع الرئيسي. في هذه الحالة ، في الواقع ، يصبح المشروع محددًا ، وهناك حاجة إلى جهود إضافية لدعمه.
بشكل عام ، إذا كان عمر المشروع أكثر من ستة أشهر ، فمن المرجح أن يحتوي على إرث.
ماذا يمكنك أن تتعلم من مشروع القصة؟
لذلك ، اتخذت قرارًا وحصلت على وظيفة في شركة حيث تم بالفعل كتابة التعليمات البرمجية من قبلك وكان الكثير من الأشياء الأخرى تحدث. سأضيف أنك لست بحاجة للذهاب إلى مكان جديد لترقية ملفات التعريف الخاصة بك. من المرجح أن يكون الإرث في كل مشروع ، ما عليك سوى معرفة كيفية تقييمه. وما أتحدث عنه يمكن بالتأكيد تطبيقه على الأشياء التي تعمل عليها الآن.
في أي مجالات سيكون الضخ مفيدًا لك وللمشروع؟ هنا تحتاج إلى فهم أن الموقف عندما تتطور حيث يضر المشروع هو بيئة مثالية للنمو المتبادل. لأنه إذا طورت في العمل على بعض الأشياء اليسارية ، فقد تكون هذه ميزة إضافية لك شخصيًا ، ولكن في نفس الوقت سيكون من الصعب شرح سبب قيام الشركة بمساعدتك في ذلك.
حلل المشروع
أول شيء يمكنك تعلمه من مشروع تراثي هو تحليله. لنفترض أنك أتيت إلى مشروع به ثغرات في التوثيق ، أو لا يوجد أي شيء على الإطلاق. في هذه الحالة ، سيكون لديك فقط الكود المصدري للمشروع ، لذلك من المهم أن تكون قادرًا على تحليله وفهم هيكله وجوهره بسرعة. هذا مهم لأنه كلما تعلمت التنقل فيه بشكل أسرع ، كلما بدأت في الاستفادة من المشروع بشكل أسرع.
أهم شيء يمكنني أن أوصي به لفهم أعمق لتحليل المشروع هو قراءة كتاب "العمل الفعال مع الكود القديم" لمايكل فيذرز. إنها عجوز ومشهورة. يصف عددًا كبيرًا من الممارسات للعمل مع التعليمات البرمجية القديمة.
نصيحة أخرى هي زيارة موقع Understand Legacy Code .... هذه مدونة مخصصة لموضوع واحد - العمل بالإرث. من المهم أن تتمكن من الاشتراك في النشرة الإخبارية هناك. أنا متأكد من أن العديد من مطوري Android يعرفون عن Android Weekly و Kotlin Weekly البريدية. النشرة الإخبارية ULC مفيدة جدًا أيضًا. إنه ليس تدخليًا ، مع مقالات إرشادية حول إعادة البناء والتشفير.
مُعاد تصنيعه
تعد المشاريع القديمة مكانًا رائعًا لممارسة مهاراتك في إعادة البناء. أنت تأتي إلى مشروع به مشاكل على الأرجح ، ولا تحتاج إلى تغييره فحسب ، بل تحتاج أيضًا إلى تحسينه وتوسيعه ورؤية ميزات جديدة. سيحدد مدى جودة وكفاءة إعادة البناء (بسرعة وبقليل من الانحدار) مدى فائدة وجودة مطور البرامج.
في مشروع ناضج بثقافة هندسية صحية ، يجب أن تكون إعادة البناء جزءًا مستمرًا من التطوير.
يجب أن يعجبك المنتج الذي تعمل عليه. مثالي إذا كنت تستطيع استخدامه بنفسك. في هذه الحالة ، سيكون لديك دافع داخلي للعمل على تحسين جودته لفترة طويلة.
تصميم وإنشاء العمارة
هذه النقطة تتبع النقطة السابقة - ستحتاج حتمًا إلى الضخ في تصميم البرامج وهندستها. مع ثقافة التطوير الصحيحة ، لن تضطر إلى اتخاذ قرارات معمارية كبرى في المواعيد النهائية الضيقة. سيكون لديك الوقت لتصميم العمارة وستكون مسؤوليتك أن تفعل ذلك بشكل جيد. ما الذي أوصي به دائمًا هنا؟ اقرأ كتب.
أجد أن الكتب لا تقل أهمية عن مصادر المعلومات الأخرى. كلما اكتسبت المزيد من الخبرة من الكتب ، زادت سرعة فهمك لكيفية حل المشكلات الشائعة. هناك دائمًا حلول نموذجية للمشكلات النموذجية / النموذجية التي يمكن العثور عليها في الكتب. يتضمن العمل مع أي نوع من الإرث أيضًا حل المشكلات النموذجية.
(Robert C Martin). « », « »
(Martin Fowler). «. »
UML — .
PlantUML (PUML) — , UML-. git, , .
عندما تعمل مع منتج لا تفهمه تمامًا ، ستحتاج بطريقة ما إلى تعلم كيفية تقييم العمل الذي يتعين القيام به. وسيكون لديك دائمًا شيء لا تعرفه ، بعض المزالق.
تعد القدرة على تقسيم مهمة كبيرة ومعقدة إلى مجموعة من القطع الصغيرة المترابطة مهارة قيمة للغاية. تتمثل إحدى طرق تطويره في العمل بأثر رجعي باستمرار على أخطاء التحلل والتقدير. في عملية التحليل ، يمكنك إنشاء قائمة تحقق من الأخطاء التي يتم مواجهتها بشكل متكرر. في المستقبل ، سيكون قادرًا على مساعدتك في منع هذه الأخطاء مرة أخرى.
أتمتة وتكون قادرة على تطبيق CI / CD
تحتاج إلى فهم ما يحدث للرمز الخاص بك من اللحظة التي تكتبه فيها إلى لحظة وصوله إلى جهاز المستخدم. وستكون لديك القدرة على التشغيل الآلي و CI / CD لتخصيص وصيانة وتحسين. في الشركات التي لا يوجد فيها فريق بنية تحتية مخصص ، يمكن ويجب (أنا مقتنع بهذا) أن يقررها أعضاء فريق التطوير الأساسي. الأدوات الحديثة (Cloud CI ، Docker) ليست معقدة بشكل لا يصدق ، لكنها تبسط إلى حد كبير حياة الفريق. ستتمكن من فعل الكثير لها إذا أتقنت هذه المهارات.
للتواصل
كلما زادت مسؤوليتك ، زاد عدد الأشخاص الذين سيتعين عليك التواصل معهم. لقد توقف تطوير البرمجيات منذ فترة طويلة عن أن يكون الكثير من الأفراد: فجميع المشاريع الكبيرة تقريبًا يتم تنفيذها بواسطة فرق. مرة أخرى ، كلما تعلمت التفاعل مع من حولك بشكل أكثر فاعلية ، زادت الفوائد التي يمكنك تحقيقها.
سيتعين عليك التواصل مع الأشخاص الأكثر ذكاءً وخبرة منك. في المشاريع الكبيرة ، هناك دائمًا "كبار السن" يمكنك تعلم الكثير منهم. أيضًا ، ستلتقي بأشخاص أغبى منك. الخبر السار هو أنك على الأرجح مخطئ بشأن قدرتك العقلية - من المفيد جدًا أن تكون قادرًا على تصحيح مثل هذه الأخطاء في الإدراك.
أعتقد أن تطوير مهارات الاتصال يمكن اختزاله في تنمية الشعور بالتعاطف. كلما تعلمت فهم دوافع وأهداف الأشخاص من حولك بشكل أفضل ، كلما أصبحت مفيدًا لهم بشكل أسرع. على سبيل المثال ، عندما تشرح لشركة ما فوائد إعادة البناء والعمل على الديون التقنية ، يجب عليك استخدام مصطلحات العمل ، وليس مصطلحات المبرمج. تبدو فكرة واضحة ، لكنني رأيت مرارًا وتكرارًا كيف يتواصل بعض الأشخاص الأذكياء مع أشخاص أذكياء آخرين ولا يمكنهم فهم بعضهم البعض.
ما هي الأسئلة التي يجب طرحها في مقابلة
سأبدأ هنا من الأسئلة التي سأطرحها قبل الذهاب للعمل في مشروع لا أعرف عنه إلا القليل.
كيف يعمل سير العمل ولماذا بالضبط
عادةً ما يعملون الآن على أنظمة Scrum أو Kanban. لكن في الوقت نفسه ، غالبًا ما يقومون بتكييفها لأنفسهم: "لقد أخذوا الأفضل ، وتخلصوا من غير الضروري". السؤال هو: ما الذي طردوه بالضبط وماذا تركوا؟ لأن دليل Scrum ، الذي على أساسه بُنيت عملية التطوير ، به بعض الممارسات الشيقة والمفيدة.
تكون منطقية عند تطبيقها ، أولاً ، بوعي ، وثانيًا ، يتم تطبيقها جميعها. لأنهم يشكلون مثل هذا النظام الذي يتحكم في نفسه ويسمح لك بتحسين ليس فقط المشروع ، ولكن أيضًا عملياتك الخاصة.
على سبيل المثال ، إذا كان الفريق يعمل على Scrum ، فسأطلب ما تمت مناقشته في آخر معرض بأثر رجعي. ما مدى نشاط الفريق في هذا الاجتماع؟ هل القضايا المثارة قيد المعالجة؟
سؤال آخر مثير للاهتمام بالنسبة لي حول العمليات الداخلية: كيف يتم إجراء مراجعة الكود في الفريق؟ هل توجد أي قواعد داخلية لإجراء المراجعة يمكن أن تساعد في تقليل وقتها؟ هل هناك قاعدة معرفية مشتركة حيث يتم إدخال نتائج الهوليفار حتى لا تناسبها في كل مرة؟
كيف يعمل التخطيط ، ومن يشارك ومدى نشاط الفريق
هذا سؤال أود أن أطرحه لمعرفة مدى قوة الثقافة الهندسية داخل الفريق. هناك خيار عندما يخطط قائد الفريق فقط ويكون الفريق إلى جانبه.
خيار آخر هو عندما يشارك الفريق بأكمله في التخطيط. وعندما تأتي مهمة ما ، يتم تكليفها برسمها من قبل شخص لديه خبرة كافية في هذا الشأن. ثم يناقشون جميعًا ويتخذون قرارًا. هذا يجعل الفريق أكثر تنظيمًا ذاتيًا وسير العمل أكثر إمتاعًا.
كم عدد الأشخاص في الفريق الذين لديهم الصورة الكاملة
نقيضان ممكنان هنا. الحد الأول هو عندما تأتي إلى فريق كان يعمل على منتج خلال 2-4 سنوات الماضية. إذا لم يتغير الفريق كثيرًا في نفس الوقت ، ولكن تم توسيعه فقط ، فهذا جيد جدًا ، لأنه سيكون لديك دائمًا أشخاص يمكنك اللجوء إليهم لطلب المساعدة. سيكونون قادرين على اقتراح شيء ما ، وشرح السبب ، وإخبارك بتاريخ المشروع. إن معرفة السياق ولماذا يعمل كل شيء بهذه الطريقة وليس غير ذلك أمر مهم للغاية.
الطرف الثاني هو عندما تأتي إلى فريق ليس لديه أي من أولئك الذين كانوا في البداية. على سبيل المثال ، تم تجميد المشروع وفك تجميده وبقيت قاعدة بيانات كبيرة. لا يمكنك إعادة الكتابة من الصفر. وفقًا لذلك ، من الضروري استعادة التطور. أي أنك تحصل على مشروع تحتاج فيه إلى حفر كل شيء مرة أخرى.
بناءً على هذه المعلومات ، ستكون قادرًا على اتخاذ قرار أكثر استنارة بشأن ما إذا كنت تريد الذهاب إلى هناك أم لا ، وربما تبالغ في تقدير بعض متطلباتك للمقترحات التي تحتاج إلى الرد عليها.
كيف يتم الحفاظ على تراكم الديون الفنية
توجد مشاكل في أي مشروع ، ومن المهم فهم كيفية عمل الفريق معهم. لقد كتبت جيدًا عن التعامل مع الديون الفنيةالكسندرليبيدففي مقال “Lannisters يدفعون ديونهم دائماً! (وتقني أيضًا) " .
إذا كان الفريق على علم بالمشكلات ، لكنه لا يعرف كيفية التعامل معها بطريقة منهجية ، فهذه علامة سيئة. لكن يمكنك النظر إلى هذا كفرصة لتصبح الشخص الذي سيساعد في حل هذه المشكلات.
نصائح لأولئك الذين بدأوا للتو العمل في مشروع قديم
قاوم إغراء التسرع في إعادة كتابة كل شيء من الصفر
موقف شائع: تبدأ العمل على تطبيق موجود وترى أن كل شيء يتم "بشكل خاطئ". ومع هذا "ليس كذلك" تحتاج إلى مزيد من العمل. إنها رغبة طبيعية تمامًا في هذه الحالة - لأخذها وإعادة كتابتها مرة أخرى. هذا رد فعل طبيعي.
أعتقد أنه يقوم على عدم الرغبة في الرد على أخطاء الآخرين. بعد كل شيء ، إذا ظهرت عيوب جديدة بعد تعديلاتك ، فسيتعين عليك اكتشافها. من الأفضل إذن إعادة كتابته بالكامل ، وسيكون كل شيء على ما يرام.
إذا لاحظت أن لديك مثل هذه الأفكار ، اسأل نفسك بعض الأسئلة:
هل هناك بالتأكيد مشاكل كافية في الكود ، أو أنك لم تفهمها بعد؟
هل أنت متأكد من أنك تفهم بالضبط جميع نقاط تكامل الكود المعاد كتابته؟
هل تعرف المشروع جيدًا بما يكفي للتنبؤ بشكل صحيح بالوقت القادم للعمل؟
بينما أنا مقتنع بأن نية التسرع على الفور لإعادة كتابة كل شيء من الصفر فكرة سيئة. يجب أن تكون التحسينات متكررة ويمكن التحكم فيها.
ذات مرة شاهدت عندما قال الفريق "كل هذا هراء ، دعونا نعيد كتابته" ، أعادوا الكتابة لمدة ستة أشهر ولم يعيدوا كتابتها. ونتيجة لذلك ، نشأ موقف مثير للاهتمام إلى حد ما عندما كان المشروع يجب أن يقود من الصفر مرة أخرى ، لتعيين فريق جديد ، لأن الفريق القديم سقط. حاول إطفاء هذه الرغبة الطبيعية تمامًا لإعادة كل شيء من الصفر.
توقع تغييرات المشروع
عليك أن تتعلم أن تكون وحيًا قليلاً. من خلال العمل مع مشروع لفترة طويلة ، ستتعلم فهم مكون المنتج الخاص به ، وتعلم كيفية فهم الأعمال ، وكيف يكسب هذا المشروع ، وكيف يعيش. سيوفر هذا فرصة لتقييم المنظور طويل المدى للقرارات التي تتخذها.
هذه مهارة مفيدة للغاية ، لأنها حالة سيئة عندما يأتي إليك صاحب المنتج ويطلب منك القيام بشيء بسيط من وجهة نظره. على سبيل المثال ، أضف معيارًا جديدًا لفرز القائمة. ومن جانبك ، هذا يعني أنك بحاجة إلى إعادة كتابة هذا المكون بأكمله. لم يكن هذا ليحدث إذا كنت تعتقد مسبقًا أن الطرق المختلفة لترتيب تلك القائمة هي وظيفة منطقية تمامًا. على الرغم من أنه لم يُطلب منها القيام بذلك في المقام الأول.
فقط لا تذهب إلى أقصى الحدود وحاول دائمًا اتخاذ القرارات الأكثر عالمية. هذا مسار مباشر لإطالة الوقت ومشاكل مع مزيد من الدعم لمثل هذه الحلول. بيت القصيد من هذه المهارة على وجه التحديد لإيجاد التوازن.
قم ببحث
عندما تعمل في مشروع طويل ، فإن مقدار ثقة الشركة في الفريق مهم. قبل تطوير أي ميزة رئيسية ، نجري بالتأكيد بحثًا كاملًا عن مجال الموضوع. قد يبدو الأمر وكأنه قائد قبطان ، لكنني أعرف حالات اندفع فيها الناس فورًا إلى العاصفة برؤوسهم ، وتحولت المهام التي تبدو بسيطة إلى عمليات إعادة بناء مطولة كان من الممكن تجنبها ببساطة عن طريق إجراء بحث قبل التطوير.
خذ وقتك في التوثيق
قم بتوثيق ما تتفاوض عليه ، عمليات المستندات ، هندسة المستندات. هنا أحاول الالتزام بالنهج القائل إنه إذا لم يكتبوه ، فلن يوافقوا. لأنه في المشاريع التي تستغرق أكثر من نصف عام ، يصبح من الضروري تعلم عدم فقدان المعلومات.
عندما تتخذ قرارًا معماريًا ، يبدو الأمر واضحًا لك. لماذا تشرحها بطريقة ما؟ بعد ستة أشهر أو سنة ، ظهرت مشاكل في هذا الحل المعماري. وتفكر: "لماذا قبلته؟ ما هو السياق؟ " يعد تعلم كيفية كتابة هذه القرارات المعمارية استثمارًا رائعًا وسيفيدك في المستقبل.
إحدى طرق الاحتفاظ بمثل هذه السجلات هي "سجلات القرارات المعمارية"... فكرتها الرئيسية هي أنه لكل حل معماري غير تافه ، تحتاج إلى إنشاء ملف به عدة عناصر: العنوان والتاريخ والسياق ووصف الحل والعواقب المقصودة. يتم تخزين هذا الملف مع الرمز ولا يتغير بعد إنشائه. قيمته الرئيسية هي أنه عندما يحين الوقت لتغيير هذا الحل المعماري ، سيكون من الأسهل بكثير فهم الدافع الذي أدى إليه.
موجز
- يعد المشروع الذي له تاريخ مكانًا جيدًا للمطور لينمو إذا أصبح مهتمًا ليس فقط بكتابة التعليمات البرمجية ، ولكن أيضًا بالمهام التي ستساعد في التطوير ليس فقط كمبرمج.
- في المشاريع ذات الخلفية ، لا يتم إنشاء المشكلة عن طريق الكود ، ولكن بواسطة الأشخاص ، أي مثل هذه الإدارة عندما يطلبون منك شيئًا سريعًا جدًا كما هو الحال دائمًا في تطوير اللعبة ، على سبيل المثال.
- . , , , .
GDG.