مفترق طرق الاختبار والهندسة المعمارية: مقابلة مع نيل فورد

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

يعرض نيل فورد ثلاثة خيارات على موقعه على الويب: ThoughtWorker (موظف في ThoughtWorks ، والذي يعرفه الكثير من الناس بسبب مارتن فاولر) ، مهندس برمجيات و Meme Wrangler. قريباً ، في مؤتمر Heisenbug ، سيتحدث عن إنشاء "بنيات تطورية" ، والتي يمكن تغييرها مع تغير الظروف الخارجية. في غضون ذلك ، سأل ميخائيل xomyakus Druzhinin (عضو في لجنة برنامج Heisenbug) نيل: كيف يتقاطع كلامه مع الاختبار ، وأكثر من ذلك بكثير.

- هل يمكنك أن تبدأ بالقول عن نفسك وحياتك المهنية؟

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

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

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

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

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

- هذا هو طول ملموس جدا للعطلة ، بارد.

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

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

"ماذا يعني ميمي رانجلر؟"

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

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

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

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

- هل يمكنك توضيح ما يجب أن يفعله مهندس البرمجيات ، ماذا تفعل كمهندس برامج؟

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

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

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

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

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

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

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

- فيما يتعلق بمسألة الهندسة المعمارية والمشاركات: أرى "QA Architect" على بطاقات العمل و LinkedIn أكثر وأكثر.

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

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

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

- دعنا نتحدث في اتجاه خطابك في Heisenbug. سوف تتحدث في مؤتمر اختبار - ماذا عن جودة البرنامج بالنسبة لك؟

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

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

- هل يمكنك إعطاء دراسة الحالة الأكثر إثارة للاهتمام من الممارسة المتعلقة بالجودة؟

- من الصعب القول ، إن جميع المشاريع مختلفة ، لذا فإن الأفضل هو دائمًا آخر ما عملت عليه!

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

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

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

ومن الخارج ، تبدو هذه مهمة بسيطة. تطبيقات مثل Dropbox و Google Drive حلت هذه المشكلة حتى أصبحت غير مرئية. ويبدو سهلا. لكن عندما حاولنا حلها ، تبيّن أن هناك مليون حالة من خطوط الحدود. لذلك ، من دون ضمان جودة موثوق ، من الصعب العثور على كل منهم ، ويجب إرجاع كل منهم لمحاذاة هيكل التطبيق من أجل ضمان استمرار الهيكل العام.

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

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

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

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

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

, , Docker. , , . , , .

. , , , — , .

, , ?

— .

— ! ! , , , . (QA). , , , .

, , QA , . , , , . -, . -, .

, — . , QA , . , . , .

— , ?

— . , , , - QA-, -, , data science, . , .

, . , , . - : « ». - : «, , , , , ». , , , . .

, ThoughtWorks, « » . , , deployment pipeline. , , , , , . , QA, , , , , , , . , -.

— . , «-», «QA» - ?

— . ThoughtWorks , , , . , , . , , -, . , . , .

— QA ?

— , , . — . , .

- , . , , , . - , . , , . , , , . , .

, . , — , 1975 , .

— 1975-?

— « -» , . , . ( ), « ». , . , , - , . , . , .

, , , — , QA . , . , , . , , .

— .

— , , Apple , . Wi-Fi , , . . UI, . QA, .

— , . , ThoughtWorks — ?

— , , « , ». , , , .

, . ? UI, , , — , . , , , : «! !» , , 50 Jira, .

. , : , , , : , , , . , .

. , . , , , .

, — « , ». , . , , . , , . , , — , . , .

. HR, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
— .
— .

15- Jira, , , . , , , , . , , - Slack, , , , Slack.

, , . , 30 . ? , . , , , . -. , . , .

: , , , , . - QA: , , email Slack, , . , , , .

— . . , -, , . .

— , . , , . , , : , .

Slack! Slack — , . , , . « » , Slack. , « ». , , , , . - Slack, , , - .

, , .

-. , . — , , , . , . , - ?

— .

— ! , . , . Slack, , . , Slack, , , , , , , .

— -. - , , .

. , IT-, , , , . . , , - - ?

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

: - , . «, ». . , .

, . , , . ThoughtWorks, , , , . . , ThoughtWorks , .

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

, . -, . : «, , agile-, 1,3 , «», 30% ». , . : « , , , , ».

— , ?

— : ? ? , . , - — . ? - — , , .

, , . , , , . , -, QA , , , , . , . , , , — , , , .

— , , , - ?

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

— , , , . , : « », , , .

— «architecture is abstract until operationalized», . , , ?

- بالطبع. , , meme wrangler.

, DevOps-. , , . DevOps , , — , , .

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

— .
— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .

, , — , , .

— . !

Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .