يبدو أن المبرمجين قد نسيوا الغرض الحقيقي للبرنامج وهو حل المشكلات الحقيقية.
قبل 50 عامًا ، في عام 1968 ، تم تنظيم
مؤتمر عمل حول هندسة البرمجيات ، تم تنظيمه بدعم من لجنة العلوم التابعة لحلف الناتو. في ذلك الوقت ، بدأ الناس يلاحظون أن البرامج أصبحت جزءًا أساسيًا من المجتمع. ومع ذلك ، أصبح من الصعب للغاية فهم. بعد هذا المؤتمر ، أصبحت البرمجة صناعة. وبدأت الابتعاد عن السيطرة على رجال الأعمال.
بغض النظر عن كيفية عمل البرمجة منذ ذلك الحين ، لا تزال هناك مشكلة في الفصل بين تطوير الأعمال والبرامج - أو "هندسة" ، كما أطلق عليها المؤتمر لأول مرة. إذا كان المطورون يركزون بشكل كبير على التطوير ، فقد يفقدون هدف البرنامج الذي يكتبونه. قد لا يرون حلولًا مخفية لا تتطلب أي تعليمات برمجية.
هنا مثال.
كان هناك بدء تشغيل أنشأ جهازًا سمح للشخص بفتح باب منزله عبر البلوتوث. تم استخدام عنصر واجهة المستخدم كواجهة مرئية ، والتي كانت مرئية حتى عندما يكون الهاتف مغلقًا. كان لديه زر واحد يسمى "افتح الباب".
عندما اقترب المستخدم من المنزل ، أخذ الهاتف ووجد القطعة ثم ضغط على زر لفتح الباب.
نظر إليه أحدهم وسأل:
إذا استخدمنا تقنية Bluetooth ويتيح نموذج أعمالنا لأي شخص لديه هاتف الدخول إلى المنزل ، فلماذا يجب أن نجبر شخصًا على أخذ الهاتف والضغط على الزر؟ اترك الباب مفتوحًا عندما يقترب الجهاز من متر واحد. وبالتالي ، نحن لسنا بحاجة لدفع تكاليف تطوير وبرمجة الواجهة البصرية!
تعتبر قصة Bluetooth هذه مثالًا رائعًا للتركيز الضيق: كان الهدف هو فتح الباب بأقل جهد ممكن. لا معنى لتطوير واجهة مرئية إذا كانت المستشعرات لاسلكية.
إذا كنت تعرف الأهداف التي يريد العمل تحقيقها وما هي القيمة بالنسبة للمستخدم ، فيمكنك عندئذ دمج هذه المعرفة مع معرفتك بالتكنولوجيا. عندها فقط سيكون لديك معلومات كافية للتوصل إلى أفضل الإجابات واستنتاج أن المنتج لا يحتاج إلى واجهة.
هذا مثال رائع على كيفية حل مشكلة فنية دون الحاجة إلى كتابة أي رمز إضافي إلى جانب رمز فتح القفل. ومع ذلك ، كما هو الحال مع
Tech Debt ،
لا ينبغي أن يبرر كتابة رمز غزر.
ليس كل رمز يستحق الكتابة.
في بعض الأحيان ، قد لا يكون إصلاح الخطأ الجسيم أولوية. إذا كان لديك تبادل للعملات المشفرة وقام النظام بالدفع نفسه مرتين ، فقد يكون التدخل البشري هو الحل الأفضل من حيث التكاليف والفوائد ، إذا كانت تكلفة حل هذه المشكلة مرتفعة.
هذه المفاضلة بين الجدية والأولوية تذكرني بالنموذج الذي أظهره لي
زميلي مؤخرًا. يطلق عليه "مصفوفة الأولوية" ، وهو
نموذج ثنائي الأبعاد يمكن استخدامه لتحديد أولويات الأخطاء بناءً على عدد المستخدمين الذين تؤثر عليهم وشدتها.
تندرج مشكلة إعادة الإيداع الموضحة أعلاه في فئة الإزعاج التي تؤثر على مستخدم واحد. لذلك ، الأولوية 3.
ليس كل خطأ يستحق الإصلاح.
هذا أمر شائع جدًا عندما يحاول المطورون كتابة برنامج نصي لكل شيء. ومع ذلك ، فإن بعض المهام المتكررة لا تستحق التشغيل الآلي. لا تحتاج إلى قضاء بعض الوقت في برمجة البرامج النصية إذا كنت ستقوم بإخفاء المعرفة اللازمة حول كيفية عمل الفريق الرئيسي.
هناك فرق بين تغليف المنطق المعقّد وتجريد المعرفة المفيدة. في بعض الأحيان يجب أن تكون المعلومات واضحة. إذا قمت بتجريدهم ، فقد يكون لهم تأثير معاكس وسيكون فهمهم أكثر صعوبة.
من المفيد استخدام بعض أنواع الأوامر ذات المستوى المنخفض في CLI أكثر من استخدام أمر عالي المستوى يلخص المعرفة ، مثل
Git .
قبل بضع سنوات كنت أعمل في مشروع باستخدام
التسليم الإضافي . لقد كان نظامًا للتحقق من الهوية يتطلب من المستخدم تقديم بعض البيانات الشخصية للتحقق من قِبل جهة خارجية.
كانت هذه ميزة خاصة للتحقق من صحة المجال أراد الفريق إنشاؤها. ومع ذلك ، فقد تم إعطاء الأولوية لسجل المراجعة في التخطيط لكل سباق ، لأن الموعد النهائي كان يقترب أكثر فأكثر. في النهاية ، اكتشف الفريق أنه لا فائدة من التحقق من الصحة على الإطلاق.
وهنا السبب: التحقق إلزامي!
من مصلحة المستخدم توفير معلومات موثوقة. إذا قدم المستخدم بيانات غير صحيحة ، فلن يتم التحقق منها ولن يتمكن من استخدام النظام. بالإضافة إلى ذلك ، دعمت معظم المتصفحات التحقق من صحة HTML القياسي ، والذي كان جيدًا.
في أسوأ الحالات ، يمكن للمستخدمين الذين لم يتمكنوا من التحقق من أنفسهم الاتصال بالدعم للتحقق من كل شيء يدويًا.
ليس كل وظيفة تستحق البرمجة.
إذا كنت مطورًا وفهمت المشكلة التي تحاول حلها ، فيمكنك التوصل إلى رمز أفضل ، وأحيانًا يمكنك التعامل دون وجود رمز على الإطلاق. أنت لست "
رمز القرد " الذي يتم دفعه لكتابة الأحرف على الشاشة. أنت محترف يحصل على المال مقابل حل المشكلات.
ومع ذلك ، إذا حاولت حل جميع المشكلات بمساعدة التكنولوجيا ، دون أي تفكير ، فستواجه مشكلات في فهم ما هو مهم للعميل والتوصل إلى أفكار رائعة.
هدفك والهدف من الكود الذي كتبته هو خلق قيمة وجعل العالم الحالي مكانًا أفضل ، وليس لإرضاء نظرتك الأنانية حول كيف ينبغي أن يكون العالم.
هناك قول مأثور: "إذا كان لديك مطرقة فقط ، فكل شيء يبدو وكأنه مسمار".
من الأفضل أن يكون لديك مسمار أولاً حتى تتمكن من التفكير في الحاجة إلى مطرقة.
هذا هو ، إذا كنت بحاجة إلى مسمار أولا.
شكرا لقراءة المقال!
إذا كان لدي أخطاء في الترجمة ، يرجى الكتابة عنها في التعليقات!
تحقق أيضًا من موقعي للوصول السريع إلى أسئلة وأجوبة javascript -
أسئلة وأجوبة JavaScript
سأكون ممتنا جدا و ممتنا لك)
أنا على
تويتر و
كيهشكرا جزيلا لاهتمامكم!