أطر - ناقص أكثر من الإيجابيات

سبب هذا المقال هو منشور آخر عن حبري. يطلق عليه "لا تتعلم الأطر ، وتعلم العمارة" ويمكنك قراءتها هنا .

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

أولا ، قليلا عن نفسك

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

وعود كبيرة إنجازات صغيرة

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

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

وهذه المرة ... وهذا اثنين ...

إراست فاندورين

شكواي الأولى هي إلى RoR و Yii و Symfony ، وتقريباً جميع الشكاوى الأخرى التي اضطررت إلى مقابلتها - وحوشهم وأطنانًا من الشفرة الزائدة عن الحاجة والتي تنتهي دائمًا في المشروع. اعتدت على مدى سنوات عديدة من العمل ، أن تكون الشفرة نظيفة وموجزة قدر الإمكان ، وأن يكون الطلب في أسرع وقت ممكن ، لا يمكنني الموافقة على القمامة (عفوا ، لا أستطيع أن أقول خلاف ذلك) أنني انتهى بي الأمر في المشاريع.

الادعاء الثاني هو محاولة من قبل الجميع ، دون استثناء ، مؤلفي الألعاب النارية للاختراع ، مثل لغة البرمجة الخاصة بهم. اسمحوا لي أن أشرح ما أعنيه. خذ على سبيل المثال مكتبة js jQuery الأكثر شيوعًا. في الوقت نفسه ، سأبدي تحفظًا على الفور ، فأنا أعتبره ما يقرب من الألقاب المفيدة والمختصة والكثير والكثير من الألقاب الأخرى ، من بين الأشياء المشابهة. أعطي jq كمثال فقط لأنه بالتأكيد سيتفهم الجميع ما أقصده. وبذلك يمكنك الوصول إلى العنصر بمعرف على js أصلي مثل document.getElementById ("id") ، ومثل jQuery $ ("# id"). حقيقة أنه تم كتابة عشرات الشخصيات أقل ليست مؤثرة جدا. في الوقت نفسه ، لدى jq مجموعة من المزايا الأخرى التي أكون مستعدًا لتعلم بناء جملة جديد لها. بالإضافة إلى ذلك ، فهي موثوقة ولا تتعارض أبدًا مع المكتبات الأخرى. ما لا يمكن أن يقال ، وكومة من نوعها ، والتي من المتوقع أن تحل محل.

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

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

وهذه ثلاثة ...

هو

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

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

السؤال الأبدي

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

1. يحتوي على مجموعة دنيا من الوظائف القياسية والحد الأقصى الأمثل
2. لا ينبغي أن تجبر الأداة المبرمج على تعلم شيء يشبه "un-language" جديدة من البرمجة التي تعطل الدماغ تمامًا
3. وكل هذا ، من الناحية المثالية ، ينبغي تحويله إلى مكتبة خفيفة لا تحاول التنافس من حيث مقدار الكود مع نظام التشغيل.

ربما أكون مخطئًا ، لكن حتى الآن ، لم يتمكن أحد من إقناعي بخلاف ذلك. على استعداد للاستماع إلى أي آراء.