نحن نقدم لك ترجمة وظيفة Gergel Oros ، الذي يشغل منصب مدير الهندسة في Uber. في ذلك ، يشاركه رأيه في تصميم الأنظمة واسعة النطاق ، بناءً على خبرته العملية في Uber و Microsoft. بالاقتران مع تعليقات على Hacker News ، التي تضيف حججاً مضادة ثقيلة وتكمل وجهة نظر المؤلف ، أصبح مقالته أحد أكثر المشاركات نشاطًا في الأسبوع. يستخدم مصطلح "تصميم الكود" في المقال لمقارنته بـ "الهندسة المعمارية" التقليدية - يمكن العثور على المزيد حول هذا الموضوع هنا .لدي خبرة كافية في تصميم وإنشاء أنظمة واسعة النطاق. شاركت في إعادة كتابة
نظام دفع موزع في Uber ، وتصميم وإصدار Skype على Xbox One ، وإصدار
RIBs علنًا ، وهو إطار بنية متنقلة تم إنشاؤه بواسطة Uber. كل هذه الأنظمة لديها تصميم مدروس بعناية ، مرت بالعديد من التكرارات ، وعقدت العديد من الاجتماعات على السبورة ، ومناقشات أخرى. ثم جاء التصميم بوثيقة تصميم ، تم توزيعها بين مطورين آخرين لجمع تعليقات إضافية ، والتي استمرت حتى انتقلنا إلى التطوير.
كل هذه الأنظمة كانت واسعة النطاق: مئات المطورين قاموا بإنشائها - أو استخدموها في تصميماتهم - واليوم يتغلبون على قلوب الأنظمة التي يستخدمها ملايين الأشخاص يوميًا. علاوة على ذلك ، لم يتم إنشاء هذه المشاريع من الصفر. كان من المفترض أن يحل نظام الدفع محل نظامي دفع آخرين موجودين يستخدمهما العشرات من الأنظمة الأخرى وعشرات الفرق ، وكل ذلك دون أي ضرر على الشركة. إعادة كتابة تطبيق Uber كان مشروعًا عمل عليه مئات المهندسين في نفس الوقت - تضمن نقل جميع الوظائف الحالية إلى الهيكل الجديد.
اسمحوا لي أن أبدأ بشيء قد يبدو غير متوقع.
أولاً ، لم نستخدم أبدًا أدوات تخطيط هندسة البرمجيات القياسية للعمل على تصميم هذه الأنظمة. لم نستخدم
UML ولا نموذج
4 + 1 ولا
ADR ولا
C4 ولا
مخططات التبعية . لقد رسمنا العديد من المخططات ، لكن أيا منها لم يتبع أي قواعد صارمة. كانت هناك حاجة فقط إلى مستطيلات وسهام قديمة جيدة - وحصلنا على مخططات مماثلة لهذا المخطط ، الذي
يصف تدفق المعلومات ، أو آخر ، والذي
يصور هيكل الفئة والعلاقة بين المكونات . غالبًا ما يكون للمخططين في نفس وثيقة التصميم نمط مختلف ، حيث يتم إضافتهما أو تحريرهما من قِبل أشخاص مختلفين.
ثانياً ، لم يكن لدينا مهندسون معماريون يمتلكون التصميم. لم يكن هناك
مهندس تكنولوجيا المعلومات ولا
مهندس المشاريع . هذا صحيح - لا Uber ، ولا Skype / Mircrosoft لديه وظيفة بدوام كامل لمهندسي البرمجيات. لا يزال من المتوقع أن يكتب المهندسون ذوو المستوى العالي ، مثل أولئك الذين يشغلون منصب مهندس الموظفين ، الكود بانتظام. جميع مشاريعنا لديها مهندسون ذوو خبرة - ومع ذلك ، لا يوجد شخص واحد يمتلك الهندسة المعمارية أو التصميم وحده. على الرغم من أن المهندسين ذوي الخبرة كانوا القوة الدافعة وراء عملية التصميم ، فقد شارك مطورو آخرون في المناقشة ، بما في ذلك "يونيو" الأخضر - علاوة على ذلك ، تحدوا في كثير من الأحيان قرارات الآخرين وطرحوا خيارات بديلة للمناقشة.
ثالثًا ، لم نشير أبدًا إلى الأنماط المعمارية الشائعة وغيرها من المصطلحات المقبولة عمومًا ، والتي تستخدم في الأدب الشعبي حول هندسة البرمجيات مثل
دليل مارتن فاولر . لم تكن هناك إشارات إلى خدمات micros ، أو هندسة بدون خادم ، أو
حدود للتطبيق ، أو
هندسة تستند إلى الحدث ، أو أي شيء آخر. ظهرت بعض هذه المصطلحات خلال جلسات العصف الذهني ؛ ومع ذلك ، لم نكن بحاجة إلى الإشارة إليهم بأنفسنا في وثائق التصميم.
تصميم البرمجيات في شركات التكنولوجيا والشركات الناشئة
فكيف تعاملنا مع كل شيء؟ ولماذا لم نتبع الطرق الشائعة في هندسة البرمجيات؟
ناقشت هذه المشكلة مع زملائنا المهندسين العاملين في شركات التكنولوجيا الأخرى - أحجام FANG (Facebook ، Amazon ، Netflix ، Google) ، والشركات الناشئة الصغيرة. معظم الفرق والمشروعات - سواء كانت كبيرة أو صغيرة - تجمع بين نهج مماثل للتصميم والتنفيذ:
- ابدأ بمهمة عمل. ما المشكلة التي نحاول حلها؟ ما المنتج الذي نحاول خلقه ولماذا؟ كيف يمكننا قياس نجاحها؟
- العصف الذهني ل "النهج" المختار. اجتمع مع الفريق وإيجاد حل عملي في بضع جلسات. لا تأخير مفرط مع هذه المرحلة. ابدأ من المستوى العلوي وقم بتخفيض نفسك تدريجياً إلى المستويات أدناه.
- ارسم منهجك على السبورة. اجمع الفريق معًا ، ودع أحدكم يصور النهج الذي يميل إليه الفريق. يجب أن تكون قادرًا على شرح بنية النظام / التطبيق الخاص بك بوضوح بمساعدة لوحة - بدءًا من أعلى مستوى ، وإذا كان ذلك ضروريًا ، فأقل وأقل. إذا كنت تواجه صعوبة في أي تفسير أو أنه غير واضح بما يكفي للزملاء ، فأنت بحاجة إلى معرفة تفاصيل قرارك بشكل أفضل.
- قم بإصلاحه في شكل وثائق بسيطة مع رسوم بيانية بسيطة بناءً على ما سبق شرحه باستخدام السبورة البيضاء. حافظ على المصطلحات إلى الحد الأدنى: تريد حتى الصغار لفهم ما يقال. استخدم لغة واضحة وسهلة في وصفك . في Uber ، نستخدم مستندًا يشبه RFC استنادًا إلى قالب بسيط.
- ناقش المفاضلات والبدائل . التصميم الجيد للبرامج والهندسة الجيدة هما الاختيار الصحيح للمبادلات. في حد ذاته ، لا يكون أي من خيارات التصميم سيئًا أو جيدًا: كل هذا يتوقف على السياق والأهداف. هل العمارة مقسمة إلى خدمات مختلفة؟ اذكر سبب قرارك عدم تقديم خدمة واحدة كبيرة ، والتي قد تكون هناك مزايا أخرى مثل نشر أبسط وأسرع. هل قررت توسيع الوحدة أو الخدمة بوظائف جديدة؟ بدلاً من ذلك ، قم بتقييم إمكانية تطوير خدمة أو وحدة منفصلة ، وما هي إيجابيات وسلبيات هذا النهج.
- توزيع وثيقة التصميم داخل الفريق / المنظمة وجمع التعليقات. في السابق ، في Uber ، أرسلنا جميع مستندات التصميم للبرنامج إلى جميع مهندسينا - حتى الوقت الذي نما فيه موظفونا إلى 2،000 شخص. الآن بعد أن بلغنا هذا الحجم ، ما زلنا نحاول الوصول إلى أكبر جمهور ممكن - ولكن في الوقت نفسه بدأنا في التأكد من أن مستوى ضوضاء المعلومات لا يتجاوز الحد المسموح به. شجع الآخرين على طرح الأسئلة واقتراح البدائل. كن واقعياً حول الحدود الزمنية لمناقشة التعليقات وإدراجها في المستند عند الضرورة. يمكن تطبيق رغبات محددة على الفور وبسرعة ، بينما من الأفضل تفكيك الملاحظات التفصيلية مع شخص ما.
لماذا يختلف نهجنا عن ما هو مذكور عادة في الأدبيات حول هندسة البرمجيات؟ في الواقع ، نهجنا لا يختلف اختلافًا جوهريًا عن ما هو موصوف في أدلة الهندسة المعمارية. تقترح جميع الأدلة تقريبًا البدء بمهمة العمل ، بالإضافة إلى وصف الحلول والمفاضلات - نحن نقوم بذلك أيضًا. ما لا نفعله هو عدم استخدام أدوات أكثر تطوراً يدافع عنها الكثير من المهندسين المعماريين وكتب الهندسة المعمارية. نحن نوثق التصميم بأقصى قدر ممكن ، باستخدام أبسط الأدوات وأكثرها وضوحًا ، مثل محرّر مستندات Google أو Office 365.
أعتقد أن الفرق الرئيسي في نهجنا يعود إلى الثقافة الهندسية للشركات المختلفة. تعد درجة عالية من الاستقلالية والتسلسل الهرمي إلى الحد الأدنى ميزة شائعة بين شركات التكنولوجيا الحديثة والشركات الناشئة ؛ في حالة الشركات الأكثر تقليدية ، هذا ليس صحيحًا دائمًا. هذا هو أيضًا السبب وراء اللجوء في هذه الأماكن غالبًا إلى "التصميم على أساس الفطرة السليمة" بدلاً من التصميم القائم على عملية ذات قواعد صارمة.
أعرف أن البنوك وشركات السيارات ، حيث يتم تشجيع المطورين بنشاط من اتخاذ أي قرارات معمارية دون الاضطرار إلى الصعود ، الحصول على موافقة من المهندسين المعماريين عدة مستويات أعلى ، الذين يشرفون على عدة فرق. هذا يجعل العملية أبطأ ، ومع وجود عدد كبير من الطلبات ، يصبح المهندسون المعماريون مثقلين. لذلك ، ينشئ هؤلاء المهندسون المعماريون مستندات أكثر رسمية ، على أمل أن يصبح النظام أكثر قابلية للفهم - باستخدام جميع الأدوات التي يصفها لك الأدب. يتم دعم هذه المستندات بنهج من أعلى إلى أسفل ، حيث إنها تعمل بطريقة تخويفية على المهندسين - فهم ليسوا مهندسين بعد كل شيء ، ولا يجب أن يشكوا أو يتخذوا قرارات بشأن النزاع ، لأنهم قد تم توثيقهم بالفعل باستخدام أساليب رسمية يكونون على دراية بها. لذلك ، فإنها عادة لا تفعل ذلك. بصراحة ، تفعل هذه الشركات الشيء نفسه من أجل جعل المطورين مورداً قابلاً للتبادل - لأن هذا يتيح لهم نقل الأشخاص من مشروع إلى آخر في وقت قصير. ربما لن يكون مفاجأة لك أن الأدوات المختلفة مناسبة بشكل أفضل للبيئات المختلفة.
تصميم برنامج بسيط دون المصطلحات بدلا من الأنماط المعمارية
يجب أن يكون الهدف من تصميم النظام هو البساطة. كلما كان النظام أكثر بساطة ، كان من الأسهل فهمه - وأسهل لإيجاد مشاكل فيه ، وكذلك تنفيذه. كلما كانت اللغة الموصوفة بها أكثر وضوحًا ، أصبح تصميمها أكثر سهولة. تجنب استخدام المصطلحات التي لن يفهمها كل عضو في الفريق - حتى أكثر الزملاء الذين يفتقرون إلى الخبرة يجب أن يكونوا قادرين على فهم ما هو على المحك على مستوى الآخرين.
التصميم النظيف يشبه الكود النظيف: إنه سهل القراءة وسهل الفهم. هناك العديد من الطرق الرائعة لكتابة رمز نظيف. ومع ذلك ، سوف تسمع غالبًا أن شخصًا ما يقترح البدء في تطبيق
أنماط تصميم "gang of four" على شفرتك. تبدأ الشفرة النظيفة بمبدأ المسؤولية الفردية والأسماء الواضحة والاتفاقيات السهلة الفهم. تنطبق هذه المبادئ بالتساوي على الهندسة المعمارية الخالصة.
إذن ما هو دور الأنماط المعمارية؟ أجدها مفيدة - مثلها مثل أنماط تصميم الأكواد. يمكنهم تزويدك بأفكار حول كيفية تحسين التعليمات البرمجية أو الهندسة المعمارية الخاصة بك. خذ أنماطًا لتصميم الأكواد البرمجية: ألاحظ بنفسي عندما ألاحظ وجود
مفرد في الكود - وأرفع حواجبي وحفر أعمق عندما أرى فصلًا يتصرف
كواجهة ، ولكنه في الواقع يقوم بإجراء مكالمات. لكن اليوم لم يحن بعد عندما كنت أفكر ، "
المصنع التجريدي يطلبه هنا فقط". في الحقيقة ، استغرق الأمر وقتًا طويلاً لأكتشف ما الذي يفعله هذا النمط وقبل بزوغه فجرًا ؛ جاء الفهم كنتيجة للعمل الشاق مع
حقن التبعية ، واحدة من المجالات القليلة التي يكون هذا النمط
واسع الانتشار ومفيد للغاية . أعترف أيضًا أنه على الرغم من أنني قضيت الكثير من الوقت في قراءة وفهم عصابة أنماط التصميم الأربعة ، إلا أنها كان لها تأثير أقل بكثير على تطوري المهني كمبرمج من التعليقات التي تلقيتها من مطورين آخرين بخصوص الكود الخاص بي.
وبالمثل ، فإن معرفة الأنماط المعمارية الشائعة أمر جيد: فهو يساعد في تقليل الوقت الذي تقضيه في المناقشات مع الأشخاص الذين يفهمونها بالطريقة نفسها التي تفعل بها. لكن الأنماط المعمارية ليست هي الهدف ، ولن تكون بديلاً عن خيارات تصميم النظام الأكثر بساطة. عندما تقوم بتصميم نظام ، قد تدرك فجأة أنك طبقت بطريق الخطأ بعض الأنماط الشائعة - وهذا أمر جيد ، لأنه في وقت لاحق سيكون من السهل عليك الرجوع إلى الطريقة المستخدمة. لكن يجب ألا تأخذ أبدًا نمطًا واحدًا أو أكثر وأن تستخدمها كمطرقة ، حيث ستشاهد دائمًا أظافرك.
ظهرت الأنماط المعمارية عندما لفت المهندسون الانتباه إلى حقيقة أنه في بعض الحالات يكون من المنطقي اتخاذ قرارات مماثلة فيما يتعلق بالتصميم وتنفيذه. بمرور الوقت ، حصلت هذه القرارات على أسماء ، وتم تسجيلها ومناقشتها من قبل الجمهور العام. الأنماط المعمارية هي الأدوات التي ظهرت
بعد إيجاد الحلول ، على أمل أن يساعد ذلك في جعل الحياة أسهل للآخرين.
كمهندس ، يجب أن تقوم كهدف هدفك بالبحث المستقل عن حلول لمشاكلك والتعلم خلال هذه العملية - بدلاً من اتخاذ نمط معماري "الضجيج" على أمل أن يحل ذلك مشكلتك.كيفية تعلم كيفية تصميم أنظمة أفضل
غالبًا ما يسألني الناس عن كيفية: "ضخ" في هندسة وتصميم النظم؟ يوصي المهندسون ذوو الخبرة عادةً بالقراءة عن الأنماط المعمارية ، وكذلك الكتب حول هندسة البرمجيات. أنا أؤيد تمامًا التوصية بقراءة أكبر قدر ممكن - لا سيما الكتب ، لأنها تتيح لك الغوص في الموضوع بشكل أعمق بكثير من الوظائف القصيرة - ومع ذلك ، لدي العديد من التوصيات العملية.
- إشراك أحد أعضاء الفريق والقيام بالسبورة البيضاء معًا. ارسم على اللوحة ما تعمل عليه واشرح معنى الصورة. تأكد من أن زملائك يفهمون ما يقال. وعندما تفهم أخيرًا ، اطلب التعليقات.
- صف التصميم الخاص بك في مستند بسيط وشاركه مع فريقك ، واطلب منهم تلقي ملاحظات. لا يهم مدى بساطة أو تعقيد المهمة التي تعمل عليها - يمكن أن يكون إما إعادة بناء صغيرة أو مشروع واسع النطاق - يجب عليك تلخيصها بإيجاز. قم بذلك بطريقة تجعل هذه الوثيقة منطقية بالنسبة لك والباقي مفهومة ؛ للإلهام - إليك مثال على كيفية القيام بذلك في أوبر . شارك هذا المستند مع فريقك بتنسيق يسمح بالتعليق - على سبيل المثال ، باستخدام محرّر مستندات Google أو Office 365 أو شيء مشابه. اطلب من الآخرين استكمالها بأفكارهم وأسئلتهم.
- إنشاء اثنين من التصاميم المختلفة والتباين بينهما. عندما يصمم معظمنا الهندسة المعمارية ، فإنهم عادة ما يسيرون في اتجاه واحد: الطريقة التي تنبثق في رؤوسهم. ومع ذلك ، الهندسة المعمارية ليست شيئا بالأبيض والأسود. تعرف على خيار تصميم معماري ثانٍ قد يعمل في وضعك أيضًا. قارن بين التصميمين وشرح لماذا يكون أحدهما أفضل من الآخر. أشر إلى أنك قد نظرت إلى الخيار الثاني لبعض الوقت كبديل ، واشرح لماذا اتخذت قرارًا وليس لصالحه.
- حدد التسويات التي تكون مستعدًا لتقديمها - اكتشف سبب قبولك لها وما تريد تحقيقه من خلال مساعدتهم. حدد بوضوح القيود الحالية التي أجبرت على أخذها في الاعتبار.
- إجراء مراجعة لتصاميم الآخرين. وافعلها بحكمة. إذا كانت شركتك لديها ثقافة مشاركة التصاميم التي يشاركها الأشخاص باستخدام السبورة البيضاء أو الاجتماعات أو المستندات - احصل على المزيد منها. عادة أثناء المراجعة ، يرى الأشخاص تصميم رمز شخص آخر كمراقبين ؛ بدلاً من ذلك ، اطرح أسئلة توضيحية للأجزاء التي لا تفهمها تمامًا. اسأل عن البدائل التي بحثوها. اسأل عن الحلول الوسط التي قاموا بها والقيود التي اعتبروها. كن من دعاة الشيطان واقترح بديلاً آخر ، ربما أكثر بساطة - حتى لو لم يكن أفضل من حلهم - واسأل عن رأيهم في اقتراحك. على الرغم من أنك لم تفكر جيدًا في التصميم الخاص بك مقارنةً بالتصميم الذي يقدمه ، فإن مناقشتك لا تزال قادرة على تقديم شيء جديد وتساعدك على فهم المهمة التي تقوم بها بشكل أفضل.
أفضل تصميم للبرامج بسيط وسهل الفهم. في المرة التالية التي تبدأ فيها مشروعًا جديدًا ، بدلاً من التفكير في السؤال "
كيف يمكنني تصميم هذا النظام ، ما هي الأنماط التي يجب أن أستخدمها في المعركة ، وما هي المنهجية الرسمية التي يجب أن أوثقها؟ " ، فكر - "
كيف يمكنني الوصول إلى أبسط تصميم ممكن - تصميم يفهمه أي شخص بسهولة؟ "
إن أفضل ممارسات هندسة البرمجيات ، والأنماط المعمارية لتطبيقات المؤسسات ، والطرق الرسمية لوصف الأنظمة ، كلها أدوات مفيدة لامتلاكها ، لأنها في يوم من الأيام يمكن أن تكون مفيدة لك. ولكن
عند تصميم الأنظمة ، فإن الأمر يستحق أن تبدأ بالنظام البسيط والاستمرار في إبقائه بسيطًا قدر الإمكان. حاول تجنّب التعقيدات التي تجلبها بنيات أكثر تعقيدًا وأدوات رسمية إلى أنظمتك.تسبب هذا المنشور في نقاش ساخن بين العاملين في الصناعة الذين تبادلوا خبراتهم ومواقفهم تجاه هندسة البرمجيات. يمكنك قراءة هذه المناقشات في Hacker News و Lobste.rs و Reddit .
بينما يوافق معظم المعلقين على الرسالة الرئيسية للمقال ، يلاحظ آخرون أن هذا النهج في الواقع قد يكون ضعيفًا في عالم "المشروع الدموي" ، حيث "المهندسون المعماريون" يأكلون خبزهم لسبب وجيه ؛ — 20 « », 300 IT- , — API, 5000 7000 .