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

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

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

أنت لست Google (إلا إذا كنت Google)

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

ولكن دعونا نواجه الأمر. من غير المحتمل أن يكون لديك 1000 مطور يعملون في مشروع ضخم مع أكثر من 10 سنوات من التاريخ.

فقط لأن Google تفعل ذلك لا يعني أنه يجب عليك القيام بذلك أيضًا.

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

كيف تبدأ معظم مشاريع البرامج؟

تبدأ العديد من المشاريع بشخص واحد يقوم بكل العمل. هناك ملايين الأمثلة ، لكن دعنا نلقي نظرة على Shopify. في البداية ، قامت الخدمة بتشفير Tobias Lyutke (كانت تستند إلى Ruby on Rails وما زالت ، بالمناسبة ، تعمل على القضبان).

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

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

1. تعلم تقنية جديدة أثناء كتابة المنتج الأصلي.
2. اكتب رمزًا غير قياسي إلى حد ما (سيء) ، ولكنه يعمل بشكل كامل.
3. شاهد كيف يعمل كل شيء معًا وتحمس.
4. إعادة هيكلة مثل "حرق بالنار" وتحسين الشفرة عند حدوث مشكلة.
5. كرر هذه الدورة عند إضافة ميزات جديدة والبدء في بيئة إنتاج.

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

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

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

تحدث عن تجريدات الشفرة

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

يجدر التكرار عند محاولة تجريد شيء ما بدون فهم كامل وإنشاء ما يسمى التجريد المتسرب.

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

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

مستويات التجريد ، من التعليمات البرمجية المضمنة إلى المكتبات الخارجية:

1. اكتب رمزًا مضمنًا.
2. كرر الرمز في عدة أماكن مختلفة.
3. استخراج كود مكرر في الوظيفة ، إلخ.
4. استخدم هذه التجريد لفترة.
5. انظر كيف يتفاعل هذا الرمز مع رمز آخر.
6. استخراج الوظائف العامة في المكتبة الداخلية.
7. لفترة طويلة استخدم المكتبة الداخلية.
8. افهم حقًا كيف تلتقي كل القطع معًا.
9. قم بإنشاء مكتبة خارجية (مفتوحة المصدر ، وما إلى ذلك) ، إذا كان ذلك منطقيًا.

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

ريلز مثال رائع. DHH (مؤلف ريلز) لم يستيقظ ذات يوم وقال: "أوه! حان الوقت لإنشاء نماذج / ، وحدات تحكم / ووجهات نظر /! ".

لا. قام بتطوير Basecamp (المنتج الحقيقي) ، ثم ظهرت قوالب معينة ، وتم تعميم هذه القوالب ثم استخراجها من Basecamp في ريلز. هذه العملية لا تزال مستمرة حتى اليوم ، وفي رأيي ، هذا هو السبب الوحيد الذي يجعل ريلز ناجحًا جدًا.

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

من التجريد إلى الخدمات الدقيقة

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

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

الهندسة القائمة على الخدمات الصغرى هي ما يمكن أن يتحول إليه المشروع بمرور الوقت عندما تواجه مشاكل حقيقية.

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

لا أعتقد أن أي شخص سيطلق عليهم صغارًا ، على الرغم من أنهم لا يعملون على مقياس Google.

تكسب Shopify 17 مليون دولار شهريًا على monolith

اعتبارًا من منتصف 2018 ، أعلنت Shopify علنًا أن أكثر من 600000 متجر عبر الإنترنت تعمل على منصتها.

Shopify هو تطبيق SaaS لديه أرخص سعر 29 دولارًا في الشهر ، ولدي شعور بأن العديد من الشركات تختار معدل 79 دولارًا في الشهر. على أي حال ، حتى لو استخدم 600000 عميل أرخص خطة مقابل 29 دولارًا ، فإن هذا دخل يبلغ 17.4 مليون دولار شهريًا فقط من خط SaaS من أعمالهم.

تطبيق Basecamp هو تطبيق متآلف رائع آخر. المثير للاهتمام في Basecamp هو أن لديهم حوالي 50 موظفًا فقط ، وبعضهم فقط هم مطورو برامج يعملون على المنتج الرئيسي.

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

متى يجب استخدام الخدمات الدقيقة؟

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

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

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

هل اللعبة تستحق الشمعة؟

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

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

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

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

يركز منتجهم بشكل أكبر على التطبيقات واسعة النطاق (من الممكن فهم السبب) ، ولكنه يعمل أيضًا للمشروعات الصغيرة. لقد سمعت عنها مؤخرًا لأنها قدمت في Cloud Cloud Day 4 .

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

الأفكار النهائية

في الأساس ، كتبت هذا المقال لسببين:

أولاً ، قبل أسبوعين زرت Cloud Field Day 4 وشاركت عن غير قصد في مجموعة بودكاست حول موضوع ذي صلة. يجب أن يتم إصداره في غضون بضعة أشهر ، لكني أردت هنا أن أتناول بعض النقاط.

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

يقوم العديد من المطورين "بتجميد" محاولين تقسيم تطبيقاتهم إلى خدمات معزولة حتى قبل كتابة السطر الأول من التعليمات البرمجية. يتعلق الأمر بأنهم يحاولون منذ البداية استخدام العديد من قواعد البيانات لمكونات التطبيق.

هذه اللحظة تمنعهم من المضي قدمًا ، وبصفتي زميلًا في التنمية ، فأنا أعلم مدى صعوبة التعثر في التردد.

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

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

ما رأيك بهذا؟ دعني اعرف في التعليقات