ظهرت هذه المقالة في الأصل على واسطة. لقد أعطانا تيم أوبراين الإذن بإعادة النشر هنا على الرادار.
أحد أكثر التغييرات غير المتوقعة في تطوير البرمجيات حاليًا يأتي من إنشاء التعليمات البرمجية. لقد عرفنا جميعًا أنه يمكن أن يؤدي إلى تسريع أنواع معينة من العمل، ولكن ما أصبح واضحًا هو أنه يعيد أيضًا تشكيل اقتصاديات المكتبات، وأطر العمل، وحتى الطريقة التي نفكر بها في المصادر المفتوحة.
فقط للتوضيح، أنا لا أعتبر هذا بمثابة تهديد لتوظيف المطورين. أعتقد أننا سنحتاج في نهاية المطاف إلى المزيد من المطورين، وأعتقد أيضًا أن المزيد من الأشخاص سيبدأون في اعتبار أنفسهم مطورين. لكنني أعتقد أن هناك ممارسات على وشك الانتهاء:
- شراء البرمجيات– سيصبح بيع البرامج أكثر صعوبة ما لم توفر منتجًا مقنعًا ويصعب إعادة إنتاجه.
- اعتماد الأطر مفتوحة المصدر– لا تفهموني خطأ، سوف تستمر المصادر المفتوحة في لعب دور ما، ولكن سيكون هناك المزيد منه، وسيكون هناك عدد أقل من مشاريع “المرحلة النجمية”.
- مهندسي البرمجيات– مرة أخرى، أنا لا أقول أنه لن يكون لدينا مهندسي برمجيات، ولكن العملية البشرية المتمثلة في النظر في بدائل الهندسة المعمارية وإجراء مناقشات مكلفة للغاية حول التجريدات بدأت بالفعل في الاختفاء.
لماذا تدفع ثمن ذلك؟
خذ المكتبات المدفوعة كمثال. لسنوات، دفع المطورون مقابل فئات معينة من البرامج لمجرد أنهم قاموا بحل المشكلات التي بدت مملة أو معقدة في إعادة إنشائها. قد يكون عارض الجدول الذي يحتوي على ترقيم الصفحات وعرض الخلايا المخصصة والتصفية قد برر رسوم الترخيص بسبب الوقت الذي يوفره. من هو المطور الذي يريد إيقاف منطق ترقيم الصفحات وإعادة كتابته لمكتبة جدول React؟
مؤخرًا، بدأت أجيب بـ “أنا”. بدلاً من ترقية الترخيص ودفع بعض الرسوم السخيفة لكل مطور، لماذا لا نطلب فقط من كلود سونيت “عرض هذا المكون باستخدام جدول HTML الذي يدعم أيضًا ترقيم الصفحات عند الطلب”؟ في البداية، يبدو الأمر وكأنه خطأ، ولكن بعد ذلك تدرك أنه من الأرخص والأسرع أن تطلب من نموذج توليدي كتابة تطبيق مخصص لهذا الجدول – وهو أبسط.
ينتهي الأمر بمعظم المطورين الذين يشترون مكتبات البرامج باستخدام ميزة أو اثنتين من الميزات، في حين تظل معظم مساحة سطح المكتبة دون تغيير. يؤدي النقر على المفتاح والانتقال إلى أسلوب مخصص أبسط إلى جعل تصميمك أكثر نظافة. (أعلم أن البعض منكم يدفع مقابل مكتبة مكونات React المشهورة جدًا مع تطبيق جدول واسع النطاق والذي أدى إلى رفع الأسعار مؤخرًا. وأعلم أيضًا أن بعضًا منكم بدأ يتساءل: “هل أنا حقًا بحاجة إلى هذا؟”)
إذا كان بإمكانك توجيه IDE الخاص بك إليه والقول، “مرحبًا، هل يمكنك تنفيذ ذلك بتنسيق HTML باستخدام بعض جافا سكريبت البسيطة؟” ويولد رمزًا لا تشوبه شائبة في خمس دقائق، فلماذا لا تفعل ذلك؟ يصبح السؤال التالي: هل سيبدأ منشئو المكتبات في إضافة بنود قانونية جديدة لحبسك؟ (توقعي: هذا هو التالي.)
يستمر الخندق المحيط بالمكتبات المتخصصة في التقلص. إذا كان بإمكانك الإجابة بـ “هل يمكنني استبدال ذلك؟” خلال خمس دقائق، ثم استبدله.
هل كنت بحاجة إلى تلك المكتبة؟
هذا التحول نفسه يمس أيضًا المصادر المفتوحة. العديد من المكتبات التي نستخدمها جاءت نتيجة لجهود مجتمعية طويلة الأمد لحل المشكلات المباشرة. يوضح التسجيل ذلك جيدًا: توجد حزم مثل log4j أو Winston لأن المطورين يحتاجون إلى تسجيل متسق عبر المشاريع. ومع ذلك، تستخدم معظم الفرق جزءًا صغيرًا فقط من هذه الوظيفة. في هذه الأيام، غالبًا ما يكون إنشاء مكتبة تسجيل خفيفة الوزن تحتوي على المستويات والتنسيقات التي تحتاجها بالضبط أمرًا أسهل.
على الرغم من أن اعتماد مكتبة مشتركة لا يزال يوفر فوائد التشغيل البيني، إلا أن التوازن يميل نحو الحلول المخصصة. أنا فقط بحاجة إلى تنسيق السجلات بطريقة قياسية. بدلاً من إضافة تبعية، قمنا بكتابة مكتبة داخلية مكونة من 200 سطر. منتهي.
قبل خمس سنوات، ربما كان ذلك يبدو غريباً. لماذا إعادة كتابة ونستون؟ ولكن بمجرد أن ترى مستوى التعقيد الذي تحمله هذه المكتبات، وتدرك أن كلود أوبوس يمكنه إنشاء مكتبة التسجيل نفسها وفقًا لمواصفاتك الدقيقة في خمس دقائق، فإن المناقشة بأكملها تتغير. مرة أخرى، أنا لا أقول أنه يجب عليك التخلي عن كل شيء وإنشاء مكتبة التسجيل الخاصة بك. لكن انظر إلى التبعيات المائة الموجودة في برنامجك، فبعضها يضيف تعقيدًا لن تستخدمه أبدًا.
قل وداعًا لـ “دعونا نفكر”
يظهر تغيير طفيف آخر في كيفية حل المشكلات. في الماضي، كان المتطلبات الجديدة تعني التوقف مؤقتًا للنظر في البنية أو الواجهات أو الأنماط قبل تنفيذ أي شيء. وعلى نحو متزايد، أقوم بتفويض خطوة “التفكير” هذه إلى النموذج. إنه يعمل بالتوازي، ويقترح الحلول بينما أقوم بالتقييم والتحسين. الوقت بين الفكرة والتنفيذ يتقلص باستمرار. بدلاً من الاختيار بعناية بين الأطر أو المكتبات، يمكنني أن أطلب تنفيذًا مخصصًا والتكرار من هناك.
قارن ذلك بما كان عليه قبل خمس سنوات. في ذلك الوقت، قمت بجمع كبار المهندسين والمعماريين لديك لتبادل الأفكار بشأن النهج المتبع. لا يزال هذا يحدث، ولكن في كثير من الأحيان اليوم، ينتهي بك الأمر إلى مناقشة مخرجات خمسة أو ستة نماذج مستقلة أنتجت حلولاً بالفعل. أنت تناقش نتائج النماذج، وليس الأفكار التجريدية.
النتيجة الأكبر هي أن فئات كاملة من البرامج قد تفقد أهميتها. لقد أمضيت سنوات في العمل على مكتبات مفتوحة المصدر مثل Jakarta Commons، وهي مجموعة من الأدوات المساعدة التي حلت عددًا لا يحصى من المشكلات البسيطة. ربما لم تعد هذه المشاريع ذات أهمية عندما يتمكن المطورون من كتابة وظائف بسيطة عند الطلب. حتى أدوات البناء تواجه هذا التحول. على سبيل المثال، برر فريق Maven ذات مرة نظامًا بيئيًا للتدريب والتوثيق. لكن في المستقبل، قد يكون توثيق نظام البناء الخاص بك بطريقة يمكن أن يفهمها النموذج التوليدي أكثر فائدة من تعليم الأشخاص كيفية استخدام Maven.
الخيط المشترك
النمط في كل هذا بسيط: إنشاء البرمجيات يجعل من الصعب تبرير الدفع مقابل الحلول الجاهزة. تفقد كل من المكتبات الخاصة والمفتوحة المصدر قيمتها عندما يكون إنشاء شيء مخصص أسرع. الأتمتة المباشرة تحل محل الأدوات والأطر. توجد أطر عمل لالتقاط التعليمات البرمجية القياسية التي يمكن للنماذج التوليدية الآن إنتاجها عند الطلب.
ونتيجة لذلك، قد يحمل المستقبل المزيد من التعليمات البرمجية المصممة خصيصًا وتنازلات أقل لتناسب الأنظمة الموجودة مسبقًا. باختصار، لا يؤدي إنشاء التعليمات البرمجية إلى تسريع عملية التطوير فحسب، بل إنه يغير بشكل أساسي ما يستحق البناء والشراء والصيانة.