مساء الخير في الآونة الأخيرة ، كثيراً ما سمعت أن غروب الشمس لمنظمة التحرير قد حان. اليوم ، ينتقل المزيد والمزيد من الناس إلى نموذج وظيفي. قريبًا ، لن يتم ترك الأشخاص الذين يكتبون بلغة C ++ / C # / Java على الإطلاق. هل هذا صحيح؟ لا أعتقد ذلك. في رأيي ، يمكن أن يصبح الاستخدام غير المدروس لـ FP (البرمجة الوظيفية) مستهلكًا للوقت وصداعًا إضافيًا ، وهو أمر لا يتوافق تمامًا مع قرارات التصميم الحالية. دعونا نتأكد من ذلك!
أريد أن أشير: هذا لا يتعلق بتعابير لامدا في Java / Python ، ولكن حول FP أكثر تقدمًا مثل Haskell أو Scala مع القطط / scalaz.
لذا ، أؤكد أن:
- التركيز البؤري التلقائي بعيدًا عن التطبيق في كل مكان.
- تجلب الصداع عند دمجها مع الحلول الجاهزة.
- إن قضاء الوقت على التركيز البؤري التلقائي ليس من الحكمة دائمًا.
سنحلل هذه النقاط بمزيد من التفصيل ونقيم حجم المأساة.
1. AF بعيد عن التطبيق في كل مكان
يبدو هذا مفاجئًا ، لكن لا يفهم الجميع ذلك. علاوة على ذلك ، فإن لغات مثل C بعيدة جدًا عن غروب الشمس. أبعد بكثير من هاسكل أو سكالا. ألق نظرة على أي محرك لعبة. مع احتمال 90 ٪ ، معظمها مكتوب في C. ألق نظرة على البرامج الثابتة لأي جهاز منزلي في شقتك. على الأرجح هذا مرة أخرى C! أنظمة التشغيل؟ بالطبع ج.
لماذا يحدث هذا؟ والحقيقة أن كل ما سبق يعمل مباشرة مع الحديد. لا يعرف الحديد أي وظائف ذات ترتيب أعلى. الحديد هو مجموعة من السجلات (التي هي بالفعل حالة قابلة للتغيير) ، والمقاطعات (مرة أخرى ، والتي تغير الحالة) والأوامر التي تنقل الأصفار والأصفار من خلية إلى أخرى.
بالطبع ، يمكنك استخدام التجريد ونسيان كل هذه الأشياء الحديدية. لكن أولاً ، هذا ليس معقولًا دائمًا. إذا كان برنامجنا بسيطًا جدًا ، فلا فائدة من الختام مع بعض طبقات التجريد. ثانيًا ، غالبًا في مثل هذه البرامج ، يتم وضع سرعة العمل على أحد المناصب الرئيسية. لذلك ، فإن التكلفة الإضافية لـ "شرح" الغدة FP ستدمر تمامًا فائدة تطويرك. AF لا يمكن أن يظهر نفسه هنا.
2. يجلب الصداع عند التكامل مع حلول تسليم المفتاح
كل لغة برمجة تحترم نفسها لديها عدد كبير من الحلول الجاهزة. في C # ، على سبيل المثال ، Entity Framework و .Net. في Java ، هذه هي السبات والربيع. ويهدف كل إطار عمل تقريبًا إلى العمل بأسلوب OOP المعتاد لدينا. دائمًا ، تحتوي هذه الحلول على حالات متغيرة وهي غير مناسبة تمامًا للعمل مع انتقالات الطور النقي.
سيقول أي مبرمج وظيفي صلب أنك بحاجة للتخلص من هذه الحلول والعمل بدونها. حسنًا دعنا فقط نكتشف ما سنفقده من مثل هذا القرار كمرجع:
- دائمًا ما تؤدي هذه القرارات إلى كود مرجعي.
- نحن نخسر طبقة ضخمة من الوظائف. بالطبع ، يمكننا أخذ مكتبة جاهزة للعمل في نموذج وظيفي. ولكن دائمًا ما يكون هذا الحل أقل شيوعًا بكثير ، مما يعني أنه لا يمكنه تقديم نصف جميع إمكانيات الحلول الشعبية.
- ستحتاج المنتجات النهائية التي تستخدم هذا الحل إلى إعادة بنائها بالكامل تقريبًا.
- نحن نخسر حلاً تم اختباره جيدًا وحتمًا للغاية. بدلاً من ذلك ، نحن نتجه نحو المجهول. هل هناك أي مشاكل في الحلول الشعبية؟ بالطبع! ولكن عنهم ، كقاعدة عامة ، كان كل شيء معروفًا منذ فترة طويلة. في نهجنا الجديد ، هذا لن يحدث بالتأكيد.
في الواقع ، تستمر القائمة لفترة طويلة. في رأيي ، فإن إجمالي الخسائر يجعل AF ، على الأقل ، ليس في كل مكان وليس مناسبًا دائمًا.
3. إن قضاء الوقت على التركيز البؤري التلقائي ليس من الحكمة دائمًالكن ما يثير الدهشة هو أن المبرمجين لا يرون غالبًا ما وراء الكود. ليست لغة البرمجة والنموذج دائمًا يحددان جودة المنتج. في الخلف ، كل شيء يذهب إلى الحاوية. يكاد لا يكون مهمًا ما تكتب عنه: Python ، Java ، Scala. يمكن لف الرمز في أي من هذه اللغات في صورة وتقديمه كحاوية.
في مثل هذا العالم ، ليس من المهم ما يوجد داخل الحاوية إذا استوفت جميع المتطلبات المحددة. من المهم هنا كيفية تنظيم النظام بأكمله. السؤال الذي يطرح نفسه: هل أنت متأكد حقا أن وقتك يستحق الاستثمار في دراسة FP مع نظرية الفئة الخاصة به؟ قد يكون من المفيد الاستثمار في تطوير بنية النظام بشكل عام. بالإضافة إلى ذلك ، من السهل جدًا العثور على أشخاص لا يعرفون FP ومستعدين لتزويدك بهذه الحاويات.
تخيل هذا الوضع. تجلس ليلا وتدرس النظرية كلها. أنت تشاهد مقاطع الفيديو على YouTube ، وتقرأ الكتب ، وتتعمق في حسابات الرياضيات. بمرور الوقت ، يمكنك بالفعل إنشاء تطبيق صغير ، ولكن ليس كل شيء واضحًا. تبدأ في ممارسة المزيد: خذ كتبًا أكثر تقدمًا ، وانتقل إلى الاجتماعات ، وقم بإجراء محادثات مع الزملاء حول المستوى العالي. ولكن بعد ذلك ظهر مشروع حقيقي. بمعرفتك تقع في دور قيادي في هذا المشروع. الحياة طيبة! وهكذا كتبت فقط الخدمة المثالية. تبقى مشكلة واحدة فقط. ماذا تفعل بعد ذلك؟ كيفية تكوين عملية الأتمتة؟ كيفية إعداد موازنة ذكية؟ كيف تجد خدمتك الأخرى؟ قد لا يكون لديك ببساطة إجابة على هذه الأسئلة! هل ما زلت على يقين من أن التركيز التلقائي ضروري للغاية بالنسبة لك؟
الاستنتاجات
في الواقع ، لدي موقف إيجابي للغاية تجاه AF. كل ما أريد أن أقوله هو أداة بعيدة كل البعد وفي كل مكان. في رأيي ، لا ينبغي للمهندس أن يفكر في فئات مثل / يكره. بدلاً من ذلك ، يجب أن يكون هناك أكثر الأسباب موضوعية لاستخدام هذا الحل أو ذاك.
قبل دراسة / تقديم نموذج وظيفي ، يجب على المرء أن يطرح ثلاثة أسئلة على الأقل: إمكانية التطبيق في مجالك المهني ، وكم يمكن أن يؤثر عند الاندماج مع الحلول الجاهزة ، وما إذا كان الوقت والموارد التي سيتم إنفاقها ستؤتي ثمارها. إذا لم يكن لديك نوبة هلع من أي من هذه المشكلات ، فيمكنك أخذها في الخدمة.
شكرا لكم على اهتمامكم!