لماذا تنتصر التقنيات «المملة»: قوة حزمة تقنية مُثبتة

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

لماذا؟ لأنها مُختبَرة وموثوقة – ليس من الناحية النظرية فحسب، بل في العالم الحقيقي. مرحبًا بكم في قوة مجموعة التقنيات المُثبتة.

حزمة التقنيات المجربة: ما هي؟

مجموعة التقنيات المجربة ليست مجرد قديمة. إنها موثوقة ومفهومة جيداً وتحل المشكلات دون إنشاء مشكلات جديدة. فكر في Java, Git، أوMarkdown. هذه ليست تحفًا قديمة – في الواقع، فهي تستمر في التطور مع الحفاظ على وظائفها الأساسية.

الأدوات الجديدة واللامعة مغرية. ولكن عندما يتحتم عليك فجأة تحويل تركيزك من التسليم إلى إخماد الحرائق، تصبح التكلفة واضحة: تتباطأ المشاريع، ويُصاب الفرق بالإرهاق، وما بدأ كـ 'مبتكريتحول إلى مشكلة.

قصة عن المطارق (ولماذا تهم في مجال التقنية)

لنبدأ بقصة من مجال مختلف تمامًا لتهيئة السياق.

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

الابتكار مقابل الكفاءة

قد تجادل، ”لكن النجار كان ببساطة أكثر اعتاداً على المطرقة القديمة!" وفي حين أنه صحيح أن الخبرة تلعب دوراً، فهل تغيّر النتيجة؟ المسمار المثني يبقى مسماراً مثنياً. لو استُخدمت هذه المطرقة في تجديد منزل حقيقي، لتبع ذلك شكاوى بالتأكيد.

الدرس المستفاد هو أنه بغض النظر عن مدى ابتكار التصميم، إذا لم تنجز الأداة المهمة بكفاءة، فإنها لا تستحق الضجة.

الأمر كله يتعلق بإنجاز المهمة في تطوير البرمجيات

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

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

في جميع المجالات (سواء كانت النجارة أو تطوير البرمجيات)، يُقدَّر الخبراء لخبرتهم المثبتة وليس لملاحقتهم للاتجاهات. إذا أمضيت عشر سنوات كمطور Java، فإن دوري هو تقديم حلول Java، وليس إحداث الارتباك من خلال التجريب بـ Scala أو Rust لمجرد الحداثة. إذا أدخلت تعقيدًا غير ضروري باستخدام لغة برمجة مختلفة، فهل ينبغي أن أتفاجأ عندما يجد زملائي صعوبة في فهم الكود الخاص بي، أو عندما تتكاثر الأخطاء؟

المغزى من القصة: الابتكار أمر جيد ومحمود، لكن فقط إذا كان يجعل الأمور أكثر كفاءة فعليًا.

أمثلة من الواقع العملي

عندما يتعلق الأمر بـ 'مملالتقنيات التي أستخدمها يوميًا – إلى جانب Java، التي ذكرتها بالفعل – تبرز أداتان (أو بالأحرى مفهومان). وهما التعبير النمطي و Markdown، وفيما يلي سأوضح لك كيف يمكنها تبسيط عملك.

التعبيرات النمطية (regex)

أول مرة صادفت التعبير النمطي بفضلVim، والتي بدأت باستخدامها قبل أربع سنوات (قبل وقت قصير من دخول Emacs إلى مجموعة أدواتي). ومع ذلك، فإن regex ليس مجرد حيلة في Vim. فالمفهوم أقدم بنحو 40 عامًا وقد رسّخ نفسه بقوة في العديد من محررات النصوص ولغات البرمجة. في هذه الأيام، أصبح regex جزءًا أساسيًا من عملي في IntelliJ، ومحررات نصوص متنوعة، وأدوات Unix، وحتى كأداة لمنطق التطبيقات.

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

ومع ذلك، تظل التعبيرات النمطية أداة أساسية لحل مشكلة واحدة محددة: التعامل مع مهام التحرير المتكررة والمملة.

على سبيل المثال، فكر في فئة مثل Numbers تحتاج إلى إعادة هيكلة. المثال أدناه مبسط، لكن تخيل مئات الأسطر، جميعها تتبع نمطًا مشابهًا، في انتظار التعديل.

بدلاً من تعديل كل سطر يدويًا، تستخدم التعبيرات النمطية. نمط واحد يحدد ما يحتاج إلى التغيير، بينما يحدد الآخر كيف لتغييره.

في لحظة، يتم تحويل كل سطر مطابق:

بالنظر إلى النتيجة، تدرك أنه لا يزال هناك مجال للتحسين. تبسيط التعبير النمطي البديل الأمر بشكل أكبر:

الآن، تبقى لديك هذه النسخة الأكثر نظافة:

جولة أخيرة من الصقل اليدوي، وها هي النتيجة:

وهنا يكمن جمال الأمر: سواء كنت تحدّث سطرًا واحدًا أو ألف سطر، فإن كتابة التعبير النمطي تستغرق الوقت نفسه (قصة حقيقية).

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

Markdown

في عام 2004، قدّم John Gruber Markdown، لغة ترميز خفيفة مصممة للبساطة. في أقل من عام، وصلت إلى نسختها النهائية المستقرة (v1.0.1)، والمثير للدهشة أن تلك النسخة ظلت دون تغيير منذ ذلك الحين.

يعود ذلك إلى أن Markdown بُني على فكرة بسيطة وعبقرية: فهو يستخدم بضعة علامات بسيطة لتنسيق النص، مثل العناوين والخطوط العريضة والمائلة والقوائم والتعدادات وبعض أساسيات التنسيق الأخرى. وفي ذلك الوقت، كان هذا كل ما يحتاجه معظم المطورين.

على الرغم من أنه يمكنك تحقيق الشيء نفسه (وأكثر بكثير) من خلال كتابة HTML مباشرة، يُرجى مقارنة هذين المثالين أدناه.

HTML

Markdown

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

بالطبع، لم يعودوا يستخدمون Markdown بالطريقة نفسها تماماً كما في عام 2004. بدلاً من ذلك، يعملون بإحدى صيغه الحديثة المتعددة – وهي تنويعات توسّع الفكرة الأصلية مع الحفاظ على بساطتها الجوهرية. تُطوَّر هذه المشتقات من Markdown بنشاط، وتظهر محررات جديدة بانتظام لدعمها، وقد بُنيت تطبيقات كاملة على Markdown الأساسي مع إضافة امتدادات متخصصة لحالات استخدام متنوعة.

إذا كنت مطوراً، فربما لاحظت أن العديد من الأدوات واسعة الاستخدام تُنشئ ملفات Markdown افتراضياً. ذلك الامتداد .md في README.md؟ يتم إنشاؤه تلقائياً كلما بدأت مستودعاً جديداً على GitHub أو GitLab أو Bitbucket. حتى منتجات Atlassian مثل Jira وConfluence دعمت التحرير المباشر بـ Markdown لسنوات (على الأقل قبل أن يقرر صناع القرار في الشركات توجيهها في اتجاه مختلف).

عبر كل هذه التغييرات، تبقى القوة الجوهرية لـ Markdown كما هي: البساطة.

كون ملف README.md يُنشأ تلقائيًا في كل مستودع جديد ليس مصادفة؛ فهو بمثابة تذكير خفي من منصات Git بأن Markdown يتفوق ببساطة في كتابة التوثيق.

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

• IntelliJ؟ مدعوم.
• Visual Studio Code؟ مدعوم.
• Notepad.exe؟ مدعوم. (ولا تحتاج حتى إلى تمييز الصيغة لكتابة Markdown بكفاءة.)

Markdown + Git = سير العمل المثالي

هل تحتاج إلى حل للتوثيق لفريقك بأكمله؟ لديك واحد بالفعل. إذا كنت مطورًا ولو بقدر بسيط من الخبرة، فأنت تستخدمه منذ سنوات. أنظمة التحكم في الإصدارات (مثل Git) هي الإجابة.

فكر في الأمر – أصبحت سير العمل هذه طبيعة ثانية للمطورين:

أفضل ما في الأمر هو الملكية الكاملة لملفاتك. إذا قررت يومًا أنك لم تعد ترغب في استخدام GitHub، فستظل جميع ملفات Markdown الخاصة بك على جهاز الكمبيوتر. لا يوجد احتكار، ولا تعقيدات خاصة، ولا حاجة إلى برامج خاصة لقراءتها.

في النهاية، Markdown ليس مجرد ‘جيد بما فيه الكفايةللتوثيق؛ إنه المعيار الذهبي.

في مدح التكنولوجيا «المملة»

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

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

قبل الانتقال إلى التقنية التالية، اسأل نفسك الأسئلة التالية:

1. هل الحل القديم موثوق وكافٍ للمهمة؟
2. هل هو مستقل عن قرارات شركة واحدة؟
3. هل يفهمه الفريق بالفعل؟
4. هل سيكون من السهل إدماج الموظفين الجدد؟
5. هل واجهت يومًا صعوبة في إيجاد تفسيرات لغرابته؟
6. هل هناك آلاف الإجابات الخبيرة لمشكلات غامضة؟

إذا كانت الإجابة بنعم على معظم هذه الأسئلة، فتهانينا – لقد وجدت 'مملتقنية تعمل.

«الرتابة» = مزيد من الوقت لما هو مهم

تعني مجموعة التقنيات المستقرة والقابلة للتنبؤ قضاء وقت أقل في التعامل مع أدواتك ووقتًا أطول في التركيز على حل مشكلات الأعمال الحقيقية. فهي تحرر الطاقة لتحقيق الأهداف الاستراتيجية بدلًا من الانشغال بتصحيح الحالات الحدية.

الآن، قارن ذلك بهذا السيناريو:

• اختر شيئاً جديداً ومثيراً.
• تشعر بالرضا لأسبوع، وربما حتى لشهر.
• تقوم بتحديث سيرتك الذاتية بـ ’تقنية رائعة’.

لكن بعد ذلك…

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

هل كانت المقايضة تستحق العناء؟

معالجة المخاوف

هناك سؤال معلق واحد لم نتناوله بعد.

“إذا تمسّكت بما يُسمى التقنيات "المملة"، فهل أخاطر بالركود المهني؟ هل سأصبح ذلك المطوّر الذي يجد صعوبة في العثور على وظيفة خلال السنوات الخمس القادمة؟“

لنأخذ نفساً عميقاً. لديّ فكرتان بهذا الشأن.

1. أفضل التقنيات كانت بالفعل \u2018مملة\u2019 قبل أن تولد

هل سمعت يومًا عن الاقتران والتماسك؟ إنهما مبدآن أساسيان في تصميم البرمجيات – مفاهيم تعود إلى السبعينيات، قبل البرمجة كائنية التوجه والتصميم المدفوع بالمجال ومعظم ما نعتبره اليوم أفضل الممارسات الحديثة. ومع ذلك، فإنها لا تزال بنفس القدر من الأهمية حتى اليوم.

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

2. كيف يصبح "الجديد" "مملاً"

ليس كل المتطورة تصل الأداة إلى 'ممل’ لكن أساسي النادي. والواقع أن ليس كل أداة جديدة تصمد طويلًا بما يكفي لتستحق هذه المكانة. وإذا حضرت مؤتمرات تكنولوجيا المعلومات (خاصة تلك التي ترعاها الشركات الموردة) فقد ينتابك انطباع بأن التحول إلى أحدث حل أمر عاجل وضروري ومضمون النجاح. والرسالة دائمًا واحدة:

“يجب عليك التحول إلى هذه التقنية. أمس.”

“كل من يهمه الأمر يستخدمه.”

لنقلب المنظور. تخيل عشر شركات ناشئة واعدة، كل منها تقدم أداتها الثورية. بعد عام، تسع منها اختفت. كم من قصص الفشل هذه ستسمع عنها في مؤتمر العام المقبل؟ لا شيء.

ما تشهده هو تحيّز البقاء: الوهم بأن كل أداة جديدة هي نجاح لأن الناجين فقط هم من يحظون بالاحتفاء.

لذا، إذا كانت تقنية جديدة مقدراً لها فعلاً أن تصبح موثوقة… فلماذا لا ننتظر ونرى إن كانت ستصمد فعلاً؟

متى تتخذ الخطوة الجريئة (ومتى تتراجع وتستمتع بالمشاهدة)

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

انظر كيف أُدخلت لغة Rust إلى نواة Linux. فبدلًا من إعادة كتابة المكوّنات الأساسية بين ليلة وضحاها، بدأوا بخطوات صغيرة، وسمحوا باستخدام Rust في وحدات اختيارية فقط. فإن نجح الأمر، فهذا رائع. وإن لم يسِر دمج Rust كما هو مخطط له، تبقى النواة الأساسية للنظام دون تأثر.

أفكار ختامية: ليس كل قديم يستحق الاحتفاظ به

بالطبع، لا تستحق كل الأدوات القديمة البقاء في مجموعة تقنياتنا. بعض التقنيات تتلاشى لأسباب وجيهة، مثل التنسيقات الاحتكارية أو عدم اليقين القانوني أو عدم الكفاءة المحض. المفتاح هو معرفة الفرق بين 'ممل لكن رائع’ و ‘قديم لسبب ما’.

الأدوات الأكثر أهمية ليست تلك التي تُبهر مسؤولي التوظيف أو تبدو عصرية في عرض تقديمي. بل تلك التي تنجز المهمة، يوماً بعد يوم، دون فشل. لذا في المرة القادمة التي تختار فيها مجموعة تقنيات، تذكّر: الممل جميل.