أو افعلها بشكل صحيح

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

عادة ما تتجلى الفكرة في نمط.

نحن بحاجة إلى {X} ، وعلى الرغم من أن جعل {Y} أسهل كثيرًا ، ولكن مع بداية {Z} ، فإن الخيار الأول سيبسط حياتنا.

حيث {Z} هو حدث قد يقع في المستقبل البعيد.

إليك بعض الأمثلة:

• تحتاج البنية التحتية إلى Kubernetes و Docker ، على الرغم من أن خادمًا كبيرًا أبسط بكثير ، ولكن عندما تضطر إلى التوسع إلى 11 خادمًا ، فسوف تبسط حياتنا.
• تتطلب معالجة البيانات تصميمًا موزعًا ، على الرغم من أن الحل المركزي أبسط بكثير ، ولكن عندما يتطلب العميل وقت تشغيل بنسبة 99.999٪ في اتفاقية مستوى الخدمة ، فسوف يبسط حياتنا.
• نحن بحاجة إلى توظيف فريق تطوير وإنشاء برامجنا الخاصة ، على الرغم من أن Wordpress و Shopify أبسط بكثير ، ولكن عندما تنمو قاعدة العملاء 100 مرة ، فسوف تبسط حياتنا.
• نحن بحاجة إلى استخدام تصميم يعتمد على نوع الميراث ، على الرغم من أن التركيب أبسط بكثير ، ولكن بعد 5 سنوات من زيادة قاعدة التعليمات البرمجية ، سيؤدي ذلك إلى تبسيط حياتنا.
• نحن بحاجة إلى كتابة التعليمات البرمجية في C ++ مع تمثيل التخزين المؤقت للتمثيل ، على الرغم من أن نص Python النصي مع الطلبات المباشرة إلى Postgres أبسط بكثير ، ولكن مع زيادة كبيرة في كمية البيانات ، فإن هذا سيبسط حياتنا.

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

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

النجاح أصعب من التعايش معه

بغض النظر عن مدى غرابة الأمر ، أعتقد أن أحد الأسباب الرئيسية لما يحدث هو عبادة المشاهير.

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

يتخيل الجميع ما يجب فعله بتلك القوة المذهلة التي لا يمتلكها. كما لو كان رئيس البلاد ، أو الملياردير ، أو المشاهير ، أو المؤدي الموهوب ، أو سوبرمان بقدرات خارقة.

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

هناك جانبان:

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

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

ومع ذلك ، من بين جميع شركات البرمجيات التي تم إنشاؤها على الإطلاق ، ربما بلغ 0.05 ٪ فقط هذا النطاق.

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

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

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

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

لذا ، إذا كانت التخيلات حول المستقبل لا تساعد ، فأنت لست بحاجة إلى التخطيط؟

لا بالطبع. التفكير في المستقبل مهم. يجب أن توضع عليه ، ولكن تفعل ذلك بشكل صحيح.

تصميم المرونة يخلق النقص

عندما يتعلق الأمر بالتفكير في المستقبل ، فإن الأقل هو الأفضل ، ولكن الأفضل.

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

من الصعب أن تقدم الخدمة أ و 90٪ من المستخدمين يحتاجون إلى ذلك بالضبط. عادةً ما تقدم الخدمة A ، و 90٪ من المستخدمين يحتاجون إلى الخدمة Z. ومع ذلك ، فإن A هو أقرب بديل لـ Z ولا أحد يقدم Z ... لذلك يقرر بعض العملاء طرحه.

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

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

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

"أكره الشفرة وأريد أن تكون صغيرة قدر الإمكان في منتجنا." - جاك ديديريش

يتطلب التصميم المثالي التضحية. عادة ما ترتبط بالمرونة.

غالبًا ما تكون البرامج غير الكاملة هي التي تحل مشكلات العالم ، نظرًا لأن البرامج غير الكاملة أكثر مرونة. النقص ، بحكم تعريفه ، يترك مجالا للتحسين.

تصميم متفائل ، قد يفاجئك المستقبل

من المهم أيضًا أن تتذكر أن العالم من حولك ليس ثابتًا.

يجب معالجة المشاكل المستقبلية من خلال التقنيات المستقبلية.

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

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

أعتقد أن جزءًا من السبب هو أن معظم المطورين في 2018 لا يزالون يفكرون في خوادم 2005. لكن أجهزة الكمبيوتر تتحسن كل عام ، ويبيع العديد من مقدمي الخدمة خوادم مخصصة رخيصة.

على سبيل المثال ، هنا خادم كبير رخيص:

• اثنان Xeon E5-2680v4 (28 مركز ، 56 خيط ، سرعة الساعة من 2.4 جيجا هرتز إلى 3.3 جيجا هرتز)
• 512 جيجا بايت DDR4-2400 رام
• محركا أقراص NVMe SSD بسعة 1.2 تيرابايت (كل منهما 3 جيجا بايت / ثانية للقراءة ، ~ 1.5 جيجا بايت / ثانية للكتابة)

أراهن أن معظم البرامج الموزعة تتطلب أقل من نصف عبء العمل على خادم الهواة هذا.

يكلف هذا الخادم من ~ 800 إلى 1300 دولارًا أمريكيًا شهريًا اعتمادًا على الموقع. يمكنك أن تأخذ عشرات مقابل راتب مهندس DevOps ذو خبرة في لندن.

ولحسن الحظ ، سيصبح الخادم أرخص في النصف في غضون عامين أو ثلاثة أعوام.

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

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

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

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

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

على الرغم من ذلك ، لا يزال الناس ينشئون برامج لأجهزة الكمبيوتر المنزلية من طراز 2012. يستخدمون Babel ، على الرغم من أن 99٪ + من المستخدمين يستخدمون ES6 متصفحات ممكنة.

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

لكني أتطرق ...

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

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

لن يساعدك البرنامج الذي يحتوي على احتياطي لعام 2020 ، والذي تم إنشاؤه بروح أوائل العقد الأول من القرن الحادي والعشرين.

لذا لا تتوقف عن التفكير في المستقبل

فقط ابدأ التخطيط بشكل صحيح.

التصميم مع مراعاة ليس فقط منتجك ، ولكن النظام البيئي المحيط بأكمله.

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