بيئة خالية من اللوم: لا ينبغي لأحد أن يكتب رمز الجودة

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

هل سبق لك العمل في عمل سيء؟

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



عندما أقول أن كل شيء سيء ، أعني أن لدينا:

• كود غير صحيح - لم يفكر أحد في جودة الشفرة ، ولا يمكن لأحد حتى صياغة جودة الكود.
• عمليات سيئة.
• لم نتمكن من التواصل بشكل طبيعي ،
• لم نفعل ما يريده العميل.

نعم ، لقد كانت تنمية خارجية ، لكن ذلك لم يجعلها سيئة. جعلها الناس هكذا.

"الناس يقومون بعمل سيء ، فالأشخاص الذين يتحملون المسؤولية عن حقيقة أن العمليات سيئة ، والكود رديء والعملاء سيئون" - هذا الفكر عذبني لسنوات عديدة. يتحمل الناس مسؤولية عدم الاستمتاع بعملي.



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

بكل جدية ، فكرت في حقيقة أن الشركات الأخرى توظف أشخاصًا مختلفين اختلافًا جذريًا يختلفون في صفاتهم الداخلية وكفاءتهم المهنية ، وأن هؤلاء الأشخاص هم من اختبار مختلف.

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

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

كانت هناك مشكلة واحدة فقط - كانت شركتي .



أنا الشخص الذي بدأ هذه الثورة.

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

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

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



لكن عندما تنظر إلى الفوضى ، لا ترى أنماطًا - لا شيء يشير إلى كيف يجب أن يكون.

إن خلق النظام من الفوضى هو عمل صعب.

تحتاج إلى أن تبدأ من البداية حتى تفهم متى حل كل شيء بالفوضى. تحتاج إلى تحديد طلب جديد وشرح ما يجب عليك فعله. هذه كلمات جميلة: "دعونا نفعل كل شيء جيدًا!". لكنك تأتي إلى العمل ولا تفهم حقًا ما يجب القيام به من أجل تغيير كل شيء ، لا توجد أفكار.

لا يساعد التعليم الذي حصلت عليه والكتب التي تقرأها ، لأن كل ما قمت به قبل أن تتعلمه من هذه الكتب ومن هذا التعليم.

بيان المشكلة

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

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

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



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

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

يقال القليل جداً عن ترتيب المهام: يتم إحضارها إلى Jira أو Trello ، ثم يتم نقلهم من هناك. لكن قلة من الناس يفكرون ، وبأي ترتيب ولماذا ولماذا الترتيب هو هذا فقط.

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

عندما أصبحت المهام فردية وقصيرة ومنظمة ، بدأ الناس في القيام بها بالطريقة التي أريدها.

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

لقد فشلنا في كثير من الأحيان العميل ، لم تفعل ما سيفيده. اعتقدت أنه إذا بدأ المطورون في فهم مهامنا والقيام بها كما ينبغي ، فهل يمكنهم فهم ما يريده العميل حقًا ويفعله كما يريد العميل؟

لقد حاولت دمج هذا في نوع من الشكل ذي الوجهين ، والذي من ناحية يفكر كمطور ، من ناحية أخرى - كعميل.



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

كانت المهمة صعبة للغاية ، وما زلت أعمل على حلها. لكنني وضعت صيغة بسيطة لنفسي.

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

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

الوثائق والمتطلبات هي أخوة توأم ، هذه وحدة مزدوجة. المتطلبات - هذا ما عليك القيام به ، والوثائق - كيفية القيام بذلك.

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

الاختبارات . الخطوة المنطقية التالية هي التحقق من نجاحه. بدأنا في اختبار متطلباتنا للتأكد من أننا نقوم فعلاً بما هو مطلوب.

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

كانت الخطوة المنطقية التالية هي سحب الكود في كل شيء ، لأن الكود هو ما نشارك فيه بشكل مباشر.

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

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

للتأكد من أننا ننفذ ، لدينا اختبارات مكتوبة في شكل متطلبات ، وهذه المتطلبات واضحة بما يكفي ليتم تنفيذها بلغة مفهومة في التعليمات البرمجية ، وكتابة رمز جيد وفقًا لهذه المتطلبات.

اتصالات

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

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

بادئ ذي بدء ، يصرف الناس بعضهم البعض ويمزقوا من حالة التدفق. جاء الرجل للتو وقال شيئا - ماذا علي أن أفعل هذا الآن؟ لماذا أخبرني أنه يريد أن ينقل هذا؟

أو المسيرات. أنا أكرههم ، أشعر دائمًا بأني أحمق عندما أجلس في الاجتماعات. يبدو أن الجميع يفهمون شيئًا ما ، ولهم وجوه ذكية ، وأفتقد أحدهم ويفكر في موعده. أريد أن أغادر لأن كل ما نناقشه يمكن مناقشته بشكل أسرع.

المسيرات تسرق وقتًا كبيرًا ولا تفعل شيئًا جيدًا.

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

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

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

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



لتنظيم الاتصالات ، يكفي اتخاذ خطوتين:

• انتقل إلى Telegram الآن وحذفه. بمجرد حذف جميع صفحاتك على الشبكات الاجتماعية ، لن يتمكن الأشخاص من الكتابة إليك.
• بعد ذلك ، ابدأ قناة واحدة وأقول أنه لا يمكنك التواصل إلا بهذه الطريقة.

عندما تكون في وضع يتيح لك إملاء إرادتك على الآخرين ، فأنت تعلمهم التواصل. تظهر أن التواصل يجب أن يكون منظمًا ومفيدًا لجميع المشاركين .

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

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

التواصل المنظم يجعل مختلف الناس هو نفسه. يحتوي GitLab حتى على تجسدات شخصية عن نفسه - يحتوي أحدهم على الحرف K والآخر C ، ولا أعرف من هؤلاء الأشخاص. لا يهمني ما هو عليه ، الشيء الرئيسي هو أنهم يتواصلون داخل الهيكل.

بعد أن نظّمنا التواصل ، وأنشأنا العمل مع العميل ، وتعلمنا كيفية كتابة تذاكر مفهومة ، فقد حان الوقت للوصول إلى الكود.

قانون

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

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

ولكن إذا كان الأمر كذلك ، فيمكنك القيام بشيء ما بهذا الأمر ومعرفة كيفية العمل في هذه الظروف.



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

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

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

بمجرد أن تصبح المؤسسة جاهزة ، يمكنك المضي قدمًا.

ولكن لا يزال الناس يرتكبون أخطاء ، لأنه لا يمكن لأي CI ، حتى يتم ضبطها بالطريقة الأكثر صرامة ، أن تلحق كل الأخطاء . وسوف تظهر في أماكن لا يفكر فيها أي شخص آخر.

ما الذي يمكن عمله حيال ذلك؟ يمكنك العودة إلى التكتيكات المعتادة والقول: "لقد ارتكبت خطأ ، وقم بتصحيحه. لقد كتبت رمزًا سيئًا - اذهب لتعلم كتابة التعليمات البرمجية. " هذا طريق سيء لا يؤدي إلى التنمية.

من أجل الكتابة بشكل صحيح وتطوير منتجك ، فأنت بحاجة إلى نهج جديد وعقلية جديدة.

بيئة خالية من اللوم

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



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

العمل المستمر على الأخطاء يأخذ المطور إلى مستوى مختلف بشكل أساسي. تبدأ في ابتكار أدوات للمطورين وتنفيذها والترويج لها ، إلخ.

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

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

يبقى النهج ، نحن في انتظار استجابة الجهاز ، لقد تم تنفيذ البرنامج بشكل جيد أم لا.وهو يعمل ، لأن هذه الأدوات تساعد في العمل.

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

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

كل خطوة تالية تكون منطقية فقط عندما يكون هناك أساس للخطوة السابقة.

, , , - CI . , , . - — .



— .

— . . : « , ?!» , , .

: , . , , , — : . , .

- — . , , , : « ? . , - ». — , - , - . .

— , — .

— , . , .

, , . . . , .

, , , , . , , , .

, , , , , , , .

— . , — , , , .

, . , , . open source , .

. , , , — .

. , , , , . , — , — . , .

. , . : — , — . .

. , , — ? , , , . .

. , , — , . - , , . , . open source.

. , , , , , . , , , .. !

. : . - , . , , . . , , . .

. , , - , . -, .

. , . - — , . , .

, . , . , .

Agile , . QualityConf , ++, — . , , .