كيفية إثبات مستقبل المشروع الفني؟

في الحياة اليومية للمطور ، هناك ثلاثة أنواع مختلفة من المشاريع:

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

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

1. قابلية التوسع

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

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

2. الصيانة

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

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

هذا ليس صحيحًا تمامًا مع npm ، لأن التبعيات الداخلية ليست ثابتة دائمًا ...

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

قد يبدو الأمر تافهاً حقًا ، لكن له في الواقع الكثير من الفوائد:

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

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

3. الاتساق

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

  • أنت قادر على تحديد قواعد الشفرة واستخدامها كمادة (مثل Airbnb). أو يمكنك أيضًا تمديد القاعدة التي أنشأتها Airbnb وإضافة القواعد الخاصة بك.
  • لا تريد أن تكلف نفسها عناء الكتابة الخاصة بك ، وليس لديك أي وقت لقضائه مع فريقك حول قاعدة محددة. يمكنك استخدام Prettier أو قياسي.

أي خيار جيد ، طالما أنك تستخدم واحدًا.

4. الكفاءة

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

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

مثال آخر سيكون لدينا هوك قبل الالتزام. في BlaBlaCar ، لدينا بعض البرامج النصية التي تختبر إصدار عقدة البيئة ، تنسيق الحزمة. تأكد من إصلاح جميع التبعيات (النقطة المرجعية رقم 2 الصيانة).

ثابت سير العمل → أتمتة → لا أخطاء الإنسان

5. هيكل

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

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

6. الوعي

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

  • كيف يعمل API؟ (SDK ، وثائق API ...)
  • كيف تراقب الموقع؟ (موارد مثل ترقب ، New Relic ...)
  • كيفية الافراج؟ (حرر البرامج النصية وعملية ...)

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

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

اختبارات نهاية إلى أخرى مثيرة للاهتمام أيضًا لنفس الغرض ، لترجمة "مواصفات منتج wiki" إلى مواصفات مطورة.

كتابة المواصفات قلت؟!

7. الثقة

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

  • وجود جيد جيم
  • فحص التبعيات الإصدار
  • من السهل التراجع
  • من السهل الدفع إلى الإنتاج (زر "الدفع إلى الإنتاج" هو الكأس المقدسة)

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

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

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

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

8. البيانات يحركها

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

اسمحوا لي أن أقدم لكم مثالا على الإصدار الأول من العمارة الأمامية الجديدة من Blablacar. لقد انتقلنا من مكدس Symfony2 / Twig / Jquery القديم إلى جانب الخادم الجديد الذي تم تقديم تطبيق ReactJS عليه. قررنا اختباره في صفحة تسجيل الدخول ، لذا فإن أول شيء فعلناه هو التحقق من التعقب على الصفحة "القديمة" ، لتحديثه. بعد ذلك ، أصدرنا الصفحة الجديدة ، ولكن بنفس HTML / CSS ، وبالتالي نفس UX / UI. لماذا فعلنا ذلك؟ بسيط: إذا قمنا بتغيير الكثير من الأشياء في وقت واحد ، لما تمكنا من التحقق من صحة البنية ، فقد تغيرت المقاييس لأسباب كثيرة للغاية.

الآن ، قمنا بتوحيد نظام التتبع ، ولدينا لكل تدفق:

  • حدث بدء التدفق.
  • محاولة الاكتمال: وصل العضو إلى نهاية التدفق ويحاول إجراء مكالمة API للتحقق من صحة إجراءه.
  • تليها نجاح أو حدث فشل.

من خلال إصدار صفحات جديدة ، لدينا على الفور ردود فعل مثيرة للاهتمام تقودنا إلى تحديث / تحسين بعض الميزات. إنه ذو قيمة عالية!

ليستنتج…

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