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

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

التحديث - أضاف بعض النص إلى القات.

من الفكرة إلى النموذج الأولي

افترض أن صديقي فاليرا وقررت أن نبدأ شركة ناشئة. Uber لـ X ، أو أي شيء آخر من هذا القبيل. جمعت في شريط ، ناقش هذه الفكرة ، موضوع رائع. يجب القيام به. ثلاثة أشهر لم تنم ، ولم تأكل ، ولم تغادر المنزل. مطور. بدأوا وأدركوا أنه لا أحد يحتاج إليها.

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

اختيار التكنولوجيا

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

اللغة

من أجل. ما لغة الكتابة؟ يمكنك أن تأخذ الوظيفة الوظيفية: Haskell ، Erlang ، Lisp (من المألوف للغاية بين الأجداد فوق 70). أو قاتل آخر JS ، وهو رائع جدًا ، تم تجميعه في JS ، لديه كل الميزات الضرورية. ولكن على الأرجح ، لن يكون لدينا أي شخص للتوظيف في عام واحد ، لأن القاتل التالي JS لن ينطلق ، وسيتعين عليه إعادة التعلم مرة أخرى أو إعادة كتابة المشروع.

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

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

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

قاعدة البيانات

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

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

حسنًا. أخذوا بعض القاعدة ، خبطت ORM أمامه لتسهيل الانتقال من SQL إلى أخرى. يوما ما (المفسد: أبدا).

العمارة

ما هي العمارة التي يجب اتخاذها؟ يكتب الرجال في حبري أن الخدمات الصغيرة رائعة. يقول أوليغ بونين: "خذ الخدمات الدقيقة".

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

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

من أين تبدأ المشروع؟

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

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

الفريق

التنمية

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

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

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

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

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

ضمان الجودة

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

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

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

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

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

الملخص

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

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