نلفت انتباهك اليوم إلى
الترجمة المستمرة
للمواد حول مخاطر ما يسمى بالبرمجة "الوظيفية".
النجاح هو الطريق وليس الهدف.
دعنا نعترف بأننا مبرمجون يدفعون مقابل وقتنا. تمامًا مثل البناة الذين يحفرون الثقوب بالقرب من منزلي منذ عامين (بالمناسبة ، إنهم يبنون جدارًا ، أي طريقًا).
دعنا نبحث عن صيغة إنتاجية المبرمج. كل من عمل في أي شركة كبيرة جادة يعرف صيغة بسيطة للنجاح:
= __ x __
▍ عدد الأخطاء الثابتة
الدماغ البشري غير متكيف بشكل سيء للغاية للعمل مع ما يسمى "حالة التطبيق" في البرمجة. يمكننا ، في وقت ما ، تخزين حوالي خمسة عناصر فقط في ذاكرتنا القصيرة الأجل. عادةً ما تكون "الحالة" في البرمجة مخزنة في الذاكرة. في OOP ، هذه ، على سبيل المثال ، حقول الكائنات أو المتغيرات. العمل مع حالة قابلة للتغيير يشبه إلى حد كبير شعوذة. القليل من أصدقائي يمكنهم التوفيق بين ثلاث كرات ، ناهيك عن خمس كرات.
OOP يستفيد بشكل جيد من نقاط الضعف هذه. في OOP ، أي شيء تقريبًا يمكن أن يتحور. أشكر القوى العليا على حقيقة أن المبدعين من OOP أخذوا على محمل الجد ما تعتمد عليه إنتاجية المطورين! في OOP ، تتوفر جميع حالات التغيير أيضًا في أماكن مختلفة من البرامج حسب المرجع. هذا يعني أن المبرمج لا يحتاج فقط إلى التفكير في الحالة القابلة للتغيير للكائن الذي يعمل معه حاليًا. إنه بحاجة إلى أن يتذكر الحالات القابلة للتغيير لكائنات 10-50 الأخرى التي يتفاعل معها هذا الكائن! هو مثل شعوذة 50 كرات في وقت واحد. هذا الوضع أيضا لديه قيمة مضافة. هذا تمرين عظيم للدماغ.
الأخطاء؟ نعم - أثناء عملية شعوذة ، تسقط بعض الكرات. قد يفوت المبرمج بعض الأشياء الصغيرة فيما يتعلق بتفاعل 50 كائنًا. لكن من بصراحة يهتم؟ يجب الإبلاغ عن أخطاء الإنتاج من قبل المستخدمين. هذه هي الطريقة التي تعمل بها المنظمات الكبيرة والجادة. بعد ذلك ، انتقلت رسائل الخطأ إلى مجلة JIRA (هذا ، كما تعلم ، منتج برمجي مهم على مستوى المؤسسة). لن تمر بضع سنوات ، وسيتم تصحيح الأخطاء. تم حل المشكلة!
يا رب ، كيف أحب تطبيقي المصرفي عبر الهاتف المحمول. إنه وظيفي للغاية ، ويقدر البنك أعمالي ويعتني ببياناتي الشخصية. الأخطاء هي مجرد احتمالات (قيل لي)!
لا يفهم ما يسمى المبرمجين "الوظيفيين" سبب عزل الدولة وجعلها غير قابلة للتغيير. وهذا يستتبع العواقب المحزنة المتمثلة في تقليل تعقيد البرامج ، وبالتالي تقليل عدد الأخطاء. إذا كان هناك عدد أقل من الأخطاء في قاعدة الكود ، فهذا يعني أن المبرمجين سيتعين عليهم حل مشاكل أقل. لن تتمكن شركات التطوير من فرض رسوم على العملاء لإصلاح الأخطاء. باستخدام الأساليب الوظيفية ، سيبدو المبرمجون الذين يعملون في أي شركة كبيرة وجادة في عيون مديريهم ، وفي الوقت نفسه ، سيضرون بشدة بفرصهم الوظيفية.
▍ عدد أسطر الكود
يحتاج المبرمج إلى الفرصة ليوضح للمديرين نتائج عمله ، ونتائج الانتقال نحو الهدف. ما هي الطريقة الأكثر فعالية للتعبير عن نتائج مبرمج؟ هذا ، بالطبع ، هو عدد أسطر التعليمات البرمجية التي كتبها! إذا تحولنا جميعًا إلى البرمجة الوظيفية ، فإننا سنزعج المدراء بشكل كبير ونثير شكوكًا جدية حول فعالية عملنا. نهج "التصريح" يؤدي إلى كتابة رمز أكثر إيجازاً. استخدامه يقلل بشكل كبير من عدد أسطر التعليمات البرمجية في البرامج. أعتقد أنه من غير المقبول تمامًا اتباع نهج تعريفي لتحقيق نفس الهدف ، حيث يلزم وجود كود أقل من 3-5 أضعاف عند استخدام OOP.
بمعنى آخر ، في الانتقال إلى البرمجة الوظيفية ، فإن إنتاجيتنا ستنهار حرفيًا في أعين مديري الشركات الجادين. وهذا بدوره سيعرض وظائفنا للخطر. لذلك ، من مصلحتنا القصوى الابتعاد عن البرمجة "الوظيفية".
تنطبق نفس النصيحة على المقاولين الذين يتقاضون رسومًا بناءً على ساعات العمل. فيما يلي صيغة نجاح بسيطة لهم:
__ = ____ = $$$$$$
وبطبيعة الحال ، تنطبق صيغة النجاح هذه أيضًا بشكل مباشر على المقاولين الجادين الذين يدفعون مقابل عدد سطور الكود:
if (1 == '1') { doStuff(); } else { // }
كود السباغيتي هو الخبز والزبدة
على عكس البرمجة الوظيفية ، يقدم لنا OOP منهجًا ثابتًا لكتابة كود السباغيتي. هذا مفيد للغاية لإنتاجية المطورين. كتابة رمز السباغيتي يعني قضاء ساعات إضافية في كتابة الكود. هذا هو فائدة مباشرة لأي مبرمج وجوه المنحى خطيرة. معكرونة ليست فقط لذيذ جدا. إنه أيضًا مفهوم مهم للغاية بالنسبة لأولئك الذين يكتبون بأسلوب OOP.
OOP هي هدية حقيقية للمقاولين وموظفي الشركات الجادة.
قسم منع الأخطاء
يجب أن لا تخاف من استخدام OOP. أكرر - الأخطاء المزعجة هي تافه لا يجب أن تقلق بشأنه. في أي مؤسسة جادة ، يوجد قسم لمنع الأخطاء (يطلق عليه أيضًا قسم دعم المستخدم) ، وتتمثل مهمته الرئيسية في حماية مطوري الشركة من العملاء الغاضبين. في النهاية - إذا لم يتمكن العميل من استخدام التطبيق بشكل صحيح - فهذه هي غلطته فقط.
لا ينبغي أن يزعج المطورون أشياء ليست ذات صلة بأعمالهم ، مثل تقارير الأخطاء. هذا يساعد على ضمان الحالة التي لا تضيع فيها موارد الشركة. نتيجة لذلك ، يحصل المطورون على الفرصة لتطبيق ميزات التطبيق الجديدة بهدوء وتوجيه كل انتباههم إلى إنشاء نماذج تجسيدية للكائنات من فئة المؤسسات وتطبيق أنماط تصميم معقدة.
reporting عملية الإبلاغ عن الخطأ
عادة ما توجد هذه العملية المصممة بعناية والمخطط لها بشكل جيد لحماية الموارد البشرية للمنظمات. بمجرد أن يواجه المستخدم خطأ ، يبحث عادةً عن رقم هاتف قسم دعم العملاء. ثم يتم تقديم المستخدم مع قائمة هاتفية تفاعلية كبيرة ، والتي تشمل خيارات مختلفة. عادة ، يستغرق حوالي 2-5 دقائق للاستماع إلى المعلومات حول القائمة وتحديد الخيار المطلوب. تتيح لك هذه الخطوة تصفية العملاء الأقل ثباتًا.
ثم يتم إخبار العميل عادة أن الشركة تواجه "حجمًا كبيرًا جدًا من المكالمات" وأن "متوسط وقت الانتظار هو 56 دقيقة". في الوقت نفسه ، عادة ما يعتذرون للعميل عن أي إزعاج ويتحدثون عن كيفية تقديره له وعن عمله. في هذه الخطوة ، يقرر معظم العملاء عدم الإبلاغ عن خطأ. من أجل الترفيه عن أولئك الذين ما زالوا يجرؤون على الانتظار ، عادة ما يعزفون الموسيقى الملهمة. بالإضافة إلى ذلك ، عرض عليهم تجربة تطبيق جديد رائع. هذا هو التطبيق الذي واجه فيه العميل مشكلة.
بعد انتهاء فترة الانتظار البالغة 56 دقيقة ، تتم إعادة توجيه المكالمة إلى مركز اتصال موجود في مكان ما في أمريكا الشمالية. عادة ما يخضع موظفو مراكز الاتصال هذه لتدريب خاص يتيح لهم التحدث بلهجة هندية أو بلغارية قوية. يرد موظف مركز الاتصال على أن التطبيق المعني خارج نطاق مسؤوليته ، لكنه سوف يسعد العميل بالتبديل إلى قسم آخر.
بعد فترة انتظار أخرى ، والتي تستغرق الآن 42 دقيقة ، يخبر موظف آخر في مركز الاتصال مع ملاحظات عن السعادة في صوته العميل أن الخطأ الذي واجهه هو في الواقع أحد ميزات التطبيق. بعد ذلك ، ينصح العميل بالرجوع إلى قسم المساعدة في التطبيق. إذا استمر العميل في الإصرار على أنه يتعامل مع خطأ ما ، فيمكنهم حتى إنشاء طلب للحصول على الدعم. قد يحصل العميل على إجابة - شيء بروح "فشل التشغيل".
آمل أن تكونوا مقتنعين الآن بأن الأخطاء ليست هي ما ينبغي أن يهتم بها المبرمج. عادة ما تتخذ المنظمات تدابير جادة لحماية المطورين من تضييع الوقت غير الضروري.
تجنب "أخطاء المبتدئين" في المقابلات
إذا كنت تبحث بنشاط عن عمل - بذل بعض الجهد لإزالة كل هذا الهراء "الوظيفي" من سيرتك الذاتية. خلاف ذلك ، لن يأخذك أحد على محمل الجد. لا أحد في عالم الشركات الحقيقي يقضي وقتًا في دراسة لعب الأطفال مثل "تكوين الوظائف" أو "النقاء" أو "الموناديات" أو "الحصانة". أنت بالكاد تريد أن تكون مثل الغرباء. إذا بدأت الحديث عن مثل هذه الأشياء ، فستجعل الشخص الذي يجري مقابلة معك يشعر بعدم الارتياح. وإذا شعر ممثل شركة صاحب عمل محتملة بأنك أكثر ذكاءً منه - فإن فرصك في الحصول على وظيفة في هذه الشركة تميل إلى الصفر.
المتخصصين في الموارد البشرية ، وتوظيف الكوادر الفنية في الشركات الكبيرة ، بالإضافة إلى التدريب المكثف الإلزامي. هذا يتيح لهم التمييز بثقة بين التقنيات الجادة - مثل Java و JavaScript.
تأكد من أن سيرتك الذاتية تحتوي على مراجع لما يوضح معرفتك الواسعة للتكنولوجيا التي تقدرها الشركات الكبيرة. قم بتضمين كلمات وعبارات مثل "class" و "الوراثة" و "أنماط التصميم" و "حقن التبعية" و "SOLID" و "مصنع الملخص" و "المفرد".
عندما يُطلب منك حل مشكلة FizzBuzz ، والتي يتم تقديمها غالبًا في المقابلات ، على قطعة من الورق ، يرجى تذكّر بالتوصية التالية ، والتي تحتاج إلى أن تكون مستعدًا مقدمًا لحل هذه المشكلة. هذه هي فرصتك لاظهار معرفتك العميقة في مجالات البرمجة التي يتم تقديرها في عالم الشركات. يجب أن تبدأ بمشروع حل شامل يتضمن استخدام أنماط التصميم وتقنيات OOP الأخرى. يمكن أن تكون نقطة الانطلاق الجيدة في حل هذه المشكلة هي
FizzBuzzEnterpriseEdition . العديد من المتقدمين يرتكبون نفس الخطأ الذي هو نموذجي للمبتدئين. يكمن هذا الخطأ في حقيقة أنها تعتمد على تقنيات محدودة مثل الوظائف. بعد هذا ، لا يوجد ما يدعو للدهشة أنه بعد المقابلة ، لا أحد يناديهم ويكتب إليهم.
ربما لا يمكن استخدام البرمجة الوظيفية لتطوير حلول برمجية جدية.
بعد النظر في الحجج المذكورة أعلاه ، جادة ودقيقة ، يمكن لأي شخص الآن أن يرى بوضوح أنه لا يمكن توقع شيء جيد من استخدام ما يسمى البرمجة "الوظيفية". من الواضح جدًا أنه يجب تجنب نهج البرمجة هذا بأي ثمن.
أثير الكثير من الضوضاء حول البرمجة "الوظيفية" على مدار العامين الماضيين. ولكن الشيء الجيد هو أن هذه هواية قصيرة الأجل من مجتمع المبرمجين يموت بالفعل بعيدا! أدرك اللاعبون الكبار في السوق ، مثل Facebook و Microsoft ، قيود البرمجة الوظيفية والتفوق المطلق للمناهج وجوه المنحى لتنظيم التعليمات البرمجية عليها. يوجهون جهودهم إلى جيل جديد من اللغات ذات الوجهة ، على وجه الخصوص - إلى
ReasonML و
BosqueOOP . تأخذ هذه اللغات قابلية تغيير حالة التطبيق إلى مستوى جديد تمامًا ، ولحسن الحظ ، لا تدعم هذا الهراء الوظيفي عديم الجدوى مثل هياكل البيانات غير القابلة للتغيير.
ملخص: هدية الآلهة
هنا قد يكون لديك سؤال حول البدائل لما يسمى بالبرمجة "الوظيفية". هذا ، بالطبع ، هو البرمجة وجوه المنحى. يتم إرسال OOP لنا من قبل الإله الحقيقي للبرمجة. OOP هي قوة يحسب لها حساب. هذه أداة كبيرة تجعل المبرمجين منتجين. بفضل OOP ، ستكون أنت وفريقك مشغولين دائمًا بالعمل (ولن تفقد وظيفتك).
إليكم مقالتي التي أتحدث فيها بالتفصيل عن OOP.
قد تكون قوة (وجوه المنحى) معك. ورمزك. أنا واحد مع القوة. السلام للجميع.
لأن الكثير منكم ربما خمنت ، هذه مادة ساخرة. إذا كنت مبرمجًا للمبتدئين ، فلا تأخذ كل هذا بعين الاعتبار.
البرمجة الوظيفية كبيرة. قضاء بعض الوقت في استكشاف هذا النموذج البرمجة وسوف تجد نفسك قبل العديد من زملائك في الفريق.
آمل أن تكونوا مهتمين بقراءة هذا أثناء الكتابة.
أعزائي القراء! ما الذي لا يعجبك أكثر شيئ في OOP؟
