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