03 ديسمبر 2025·7 دقيقة
كيرنيغان عن وضوح البرمجة: الذوق قبل الكود الذكي
نصيحة براين كيرنيغان عن "الذوق الجيد" تبيّن كيف أن الكود المقروء يوفر الوقت، يقلل الأخطاء، ويساعد الفرق الحقيقية على التسريع أكثر من الحيل الذكية.
نصيحة براين كيرنيغان عن "الذوق الجيد" تبيّن كيف أن الكود المقروء يوفر الوقت، يقلل الأخطاء، ويساعد الفرق الحقيقية على التسريع أكثر من الحيل الذكية.
يظهر اسم براين كيرنيغان في أماكن يستخدمها كثير من المطورين دون تفكير: أدوات يونكس الكلاسيكية، منظومة C، وعقود من الكتابة التي علمت الناس كيف يشرحون البرامج بوضوح. سواء تذكر The C Programming Language (مع دينيس ريتشي)، The Unix Programming Environment، أو مقالاته ومحاضراته، الخيط المشترك هو الإصرار على أفكار بسيطة معبرًا عنها بوضوح.
أفضل نصائح كيرنيغان لا تعتمد على تركيب C أو اتفاقات يونكس. إنها تدور حول كيف يقرأ البشر: نمسح للعثور على البنية، نعتمد على التسمية، نستنتج النية، ونشعر بالحيرة عندما يخفي الكود المعنى وراء الحيل. لهذا السبب يبقى "الذوق" في قابلية القراءة مهمًا عند كتابة TypeScript أو Python أو Go أو Java أو Rust.
اللغات تتغير. الأدوات تتحسن. الفرق لا تزال تطلق ميزات تحت ضغوط زمنية، وغالبية الكود تُصان بواسطة شخص غير المؤلف الأصلي (غالبًا أنت في المستقبل). الوضوح هو المضاعف الذي يجعل كل ذلك قابلاً للتحمّل.
هذه ليست تحية لـ "البرمجة البطولية" أو دعوة لحفظ قواعد قديمة. إنها دليل عملي للعادات التي تجعل الكود اليومي أسهل للعمل بها:
تأثير كيرنيغان مهم لأنه يشير لهدف بسيط وملائم للفريق: اكتب كودًا يتواصل. عندما يقرأ الكود كمُسْتَخْرَج واضح، تقضي وقتًا أقل في فك رموزه ووقتًا أكثر في تحسينه.
"الذوق الجيد" في الكود المقروء ليس عن الذوق الشخصي، أو الأنماط المعقدة، أو ضغط الحل إلى أقل عدد من الأسطر. إنه عادة اختيار أبسط خيار واضح يوضح النية بشكل موثوق.
حل ذو طعم جيد يجيب على سؤال أساسي للقارئ التالي: ماذا يحاول هذا الكود أن يفعل، ولماذا يفعل ذلك بهذه الطريقة؟ إذا تطلب هذا الجواب تمارين ذهنية، افتراضات مخفية، أو فك شفرات حيل ذكية، فالكود يكلف الفريق وقتًا.
معظم الكود يُقرأ أكثر كثيرًا مما يُكتب. "الذوق الجيد" يعامل القراءة كنشاط أساسي:
لهذا السبب القابلية للقراءة ليست مجرد جماليات (المسافات البادئة، عرض السطر، أو ما إذا كنت تحب snake_case). هذه أمور مفيدة، لكن "الذوق الجيد" يتعلق أساسًا بتيسير الاستدلال: أسماء واضحة، تدفق تحكم بديهي، وبنية متوقعة.
خطأ شائع هو الأمثلية للقصر بدل الوضوح. أحيانًا يكون أوضح كود أطول قليلًا لأنه يوضّح الخطوات صراحة.
مقارنة بين نهجين:
النسخة الثانية قد تضيف أسطرًا، لكنها تقلل الحمل المعرفي اللازم للتحقق من الصحة. كما تجعل العيوب أسهل للعزل والتغييرات أكثر أمانًا.
الذوق الجيد هو معرفة متى تتوقف عن "تحسين" حل بالحيل وبدلًا من ذلك تجعل النية واضحة. إذا استطاع زميل فهم الكود دون أن يطلب منك جولة، فقد اخترت جيدًا.
الكود الذكي غالبًا ما يبدو فوزًا للحظة: أسطر أقل، حيلة أنيقة، عامل دهشة في الـ diff. في فريق حقيقي، يتحول هذا الذكاء إلى فاتورة متكررة—تُدفع بوقت التعريف، وقت المراجعة، والتردد في كل مرة يجب فيها لمس الكود مرة أخرى.
التعريف بالعملاء يتباطأ. الزملاء الجدد لا يحتاجون فقط لتعريف المنتج؛ بل يجب أن يتعلموا لهجتك الخاصة من الاختصارات. إذا كان فهم دالة يتطلب فك حيل أو اتفاقيات ضمنية، سيتجنب الناس تعديلها—أو يعدلونها بخوف.
المراجعات تصبح أطول وأقل موثوقية. يقضي المراجعون طاقة في إثبات صحة الحيلة بدل تقييم إذا كان السلوك يطابق النية. والأسوأ، الكود الذكي أصعب للمحاكاة الذهنية، لذا يفوت المراجعون حواف قد يكتشفونها في نسخة بسيطة.
يتضاعف الذكاء خلال:
بعض المتكررين:
17, 0.618, -1) التي تشفر قواعد لا أحد يذكرها.&& / || مع افتراضات التقييم).نقطة كيرنيغان عن "الذوق" تظهر هنا: الوضوح ليس كتابة مزيد من الكود؛ إنه جعل النية بديهية. إذا وفرت «النسخة الذكية» 20 ثانية اليوم لكنها تكلف 20 دقيقة لكل قارئ لاحق، فهي غير ذكية—إنها باهظة.
ذوق كيرنيغان يظهر غالبًا في قرارات صغيرة متكررة. لست بحاجة لإعادة كتابة كبرى لجعل الكود أسهل في التعامل—انتصارات الوضوح الصغيرة تتراكم في كل مرة يفحص فيها أحد الملفات أو يبحث عن سلوك أو يصلح خطأ تحت ضغط.
الاسم الجيد يقلل الحاجة للتعليقات ويجعل الأخطاء أصعب في الاختباء.
اسعَ لأسماء تكشف النية وتطابق كيف يتحدث فريقك:
invoiceTotalCents على sum.إذا أجبرك الاسم على فك شفرته، فهو يعمل عكس هدفه.
معظم القراءة هي مسح بصري. المسافات والتركيب المتسقان يساعدان العين على العثور على المهم: حدود الدوال، الشروط، و"المسار السعيد".
بعض العادات العملية:
عندما يصبح المنطق معقّدًا، عادةً ما يتحسن الوضوح بجعل القرارات صريحة.
قارن هذين الأسلوبين:
// Harder to scan
if (user && user.active && !user.isBanned && (role === 'admin' || role === 'owner')) {
allow();
}
// Clearer
if (!user) return deny('missing user');
if (!user.active) return deny('inactive');
if (user.isBanned) return deny('banned');
if (role !== 'admin' && role !== 'owner') return deny('insufficient role');
allow();
النسخة الثانية أطول، لكنها تقرأ كقائمة تحقق—وأسهل للتمديد دون كسر.
هذه قرارات "صغيرة"، لكنها حرفة يومية للكود القابل للصيانة: أسماء صادقة، تنسيق يوجّه القارئ، وتدفُّق تحكم لا يجعلك تقوم بتمارين ذهنية.
أسلوب كيرنيغان في الوضوح يظهر بوضوح حين تُقسّم العمل إلى دوال ووحدات. يجب أن يكون القارئ قادرًا على مسح البنية، تخمين وظيفة كل جزء، وأن يكون محقًا تقريبًا قبل قراءة التفاصيل.
استهدف دوال تقوم بشيء واحد على مستوى "تكبير" واحد. عندما تخلط الدالة بين التحقق، قواعد العمل، التنسيق، والإدخال/الإخراج، يجب على القارئ الاحتفاظ بعدة خيوط في ذهنه.
اختبار سريع: إذا وجدت نفسك تكتب تعليقًا مثل "// الآن افعل X" داخل دالة، فغالبًا ما يكون X مرشحًا جيدًا لدالة منفصلة ذات اسم واضح.
قوائم المعاملات الطويلة ضريبة تعقيد مخفية: كل موقع استدعاء يتحول إلى ملف إعدادات صغير.
إذا كانت عدة معاملات تسافر دائمًا معًا، جمعها بعناية. كائنات الخيارات (أو هياكل بيانات صغيرة) يمكن أن تجعل مواقع الاستدعاء ذاتية التوضيح—طالما حافظت على تجميع متماسك وتجنبت رمي كل شيء في حقيبة "متفرقات".
أيضًا، فضّل تمرير مفاهيم النطاق بدل البدائيات. UserId أفضل من string، وDateRange أفضل من (start, end) عندما لتلك القيم قواعد.
الوحدات هي وعود: "كل ما تحتاجه لهذا المفهوم هنا، والباقي في مكان آخر." اجعل الوحدات صغيرة بما يكفي لتحمل غرضها في رأسك، وصمّم حدودًا تقلل الآثار الجانبية.
عادات عملية تساعد:
عندما تحتاج إلى حالة مشتركة، سمّها بصدق ووثق الثوابت المطلوبة. الوضوح ليس تجنب التعقيد—إنه وضعه حيث يتوقعه القارئ. للمزيد عن الحفاظ على هذه الحدود أثناء التغييرات، انظر /blog/refactoring-as-a-habit.
ذوق كيرنيغان يظهر في كيفية التعليق: الهدف ليس تدوين كل سطر، بل تقليل الالتباس المستقبلي. أفضل تعليق هو الذي يمنع افتراضًا خاطئًا—خصوصًا عندما يكون الكود صحيحًا لكنه مفاجئ.
التعليق الذي يكرر الكود ("زد i") يضيف فوضى ويعلّم القراء تجاهل التعليقات. التعليقات المفيدة تشرح النية، المقايضات، أو القيود التي لا تظهر من الصياغة.
# Bad: says what the code already says
retry_count += 1
# Good: explains why the retry is bounded
retry_count += 1 # Avoids throttling bans on repeated failures
إذا شعرت برغبة في كتابة تعليقات "ما"، فغالبًا ما يكون إشارة إلى أن الكود يجب أن يكون أوضح (أسماء أفضل، دالة أصغر، أو تدفُّق تبسيطي). دع الكود يحمل الحقائق؛ ودع التعليقات تحمل المنطق.
لا شيء يقوّض الثقة أسرع من تعليق قديم. إذا كان التعليق اختياريًا، فسوف ينحرف مع الزمن؛ وإذا كان خاطئًا، يصبح مصدر أخطاء نشطًا.
عادة عملية: اعتبر تحديث التعليق جزءًا من التغيير، وليس "من الجيد فعلها". أثناء المراجعات، من العادل أن تسأل: هل هذا التعليق لا يزال يطابق السلوك؟ إن لم يكن فحدّثه أو احذفه. "لا تعليق" أفضل من "تعليق خاطئ".
التعليقات المضمنة مناسبة للمفاجآت المحلية. الإرشاد الأوسع ينتمي إلى docstrings، READMEs، أو ملاحظات المطور—خصوصًا لـ:
docstring جيدة تخبر شخصًا كيف يستخدم الدالة بشكل صحيح وما الأخطاء المتوقعة، بدون سرد التنفيذ. ملاحظة قصيرة في /docs أو /README تستطيع حكي قصة "لماذا فعلناها بهذه الطريقة" حتى تبقى بعد عمليات إعادة التشكيل.
الربح الهادئ: تعليقات أقل، لكن كل واحدة تستحق مكانها.
معظم الكود يبدو "جيدًا" على المسار السعيد. الاختبار الحقيقي للذوق هو ما يحدث عندما تكون المدخلات مفقودة، الخدمات تتأخر، أو المستخدم يفعل شيئًا غير متوقع. تحت الضغط، الكود الذكي يخفي الحقيقة. الكود الواضح يجعل الفشل واضحًا—وقابلًا للتعافي.
رسائل الخطأ جزء من منتجك ومسار تصحيح الأخطاء. اكتبها وكأن الشخص التالي يقرأها متعبًا وفي نوبة استدعاء.
ضمّن:
إذا كان لديك تسجيل (logging)، أضف سياقًا منظمًا (مثل requestId, userId, أو invoiceId) حتى يصبح الرسالة قابلة للتنفيذ دون الحفر في بيانات غير ذات صلة.
هناك إغراء لـ "التعامل مع كل شيء" بسطر واحد ذكي أو catch-all عام. الذوق الجيد هو اختيار حالات الحافة القليلة الهامة وإبرازها.
مثال: فرع صريح لـ "إدخال فارغ" أو "غير موجود" غالبًا ما يقرأ أفضل من سلسلة تحويلات تنتج null ضمنيًا في منتصف الطريق. عندما تكون الحالة الخاصة مهمة، سمّها وضعها في المقدمة.
خلط أشكال الإرجاع (أحيانًا كائن، أحيانًا سلسلة، أحيانًا false) يجبر القراء على الاحتفاظ بشجرة قرارات ذهنية. فضّل أنماط تحافظ على الاتساق:
معالجة الفشل الواضح تقلل المفاجآت—والمفاجآت موطن الأخطاء وصفحات منتصف الليل.
الوضوح ليس فقط عما قصدته عند كتابة الكود. إنه عما يتوقع أن يراه الشخص التالي عند فتح ملف في الساعة 4:55 مساءً. الاتساق يحول "قراءة الكود" لتعرف الأنماط—مفاجآت أقل، سوء فهم أقل، ونقاشات متكررة أقل.
دليل فريق جيد قصير ومحدد وبراغماتي. لا يحاول تشفير كل تفضيل؛ بل يحسم الأسئلة المتكررة: قواعد التسمية، بنية الملفات، أنماط التعامل مع الأخطاء، وماذا يعني "مكتمل" للاختبارات.
القيمة الحقيقية اجتماعية: يمنع تكرار النقاش نفسه مع كل طلب سحب. عندما يُكتب شيء ما، تتحول المراجعات من "أفضّل X" إلى "اتفقنا على X (وهنا السبب)". احتفظ به حيًا وسهل الوصول—كثير من الفرق تلصقه في المستودع (مثلاً، /docs/style-guide.md) ليكون قريبًا من الكود.
استخدم الفورماتر واللينتر لأي شيء قابل للقياس وممل:
هذا يحرر البشر للتركيز على المعنى: التسمية، شكل الواجهة، حالات الحافة، وما إذا كان الكود يطابق النية.
القواعد اليدوية لا تزال مهمة عندما تصف خيارات التصميم—مثال: "فضل الإرجاع المبكر لتقليل التعشيش" أو "نقطة دخول عامة واحدة لكل وحدة". الأدوات لا تستطيع الحكم الكامل على ذلك.
أحيانًا التعقيد مبرر: حدود أداء ضيّقة، قيود مضمنة، تعقيدات تزامن، أو سلوك منصة محدد. الاتفاق يجب أن يكون: الاستثناءات مسموح بها، لكن يجب أن تكون صريحة.
معيار بسيط يساعد: وثِّق المقايضة بتعليق قصير، أضف مقياسًا صغيرًا أو قياسًا عندما يُستشهد بالأداء، وعزل الكود المعقّد خلف واجهة واضحة حتى يظل معظم الكود مقروءًا.
مراجعة جيدة يجب أن تشعر كأنها درس قصير ومركز في "الذوق الجيد" بدلًا من تفتيش. نقطة كيرنيغان ليست أن الكود الذكي شرّ—بل أن الذكاء مكلف عندما يعيش الآخرون معه. المراجعات هي المكان الذي يمكن فيه للفريق جعل تلك المقايضة مرئية واختيار الوضوح عمدًا.
ابدأ بالسؤال: "هل يستطيع زميل فهم هذا من المرور الأول؟" هذا غالبًا يعني النظر إلى التسمية، البنية، الاختبارات، والسلوك قبل الغوص في تحسينات صغيرة.
إذا كان الكود صحيحًا لكنه صعب القراءة، عامل القابلية للقراءة كخَطأ حقيقي. اقترح إعادة تسمية متغيرات لتعكس النية، تقسيم دوال طويلة، تبسيط تدفُّق التحكم، أو إضافة اختبار صغير يوضّح السلوك المتوقع. مراجعة تلتقط "يعمل، لكن لا أفهم لماذا" تمنع أسابيع من الارتباك المستقبلي.
ترتيب عملي مفيد:
تتجه المراجعات نحو الخطأ عندما يُؤطر التعليق كأنك تضع نقاطًا. بدل "لماذا فعلت هذا؟" جرّب:
الأسئلة تدعو للتعاون وغالبًا ما تكشف قيودًا لم تكن تعرفها. الاقتراحات تنقل اتجاهًا بدون إيحاء بالبَغْي.
إذا أردت قابلية قراءة متسقة، لا تعتمد على مزاج المراجع. أضف بعض "فحوص الوضوح" إلى قالب المراجعة وتعريف الإنهاء. اجعلها قصيرة ومحددة:
مع الوقت، تتحول المراجعات من رقابة إلى تعليم الحكم—وهو نوع الانضباط اليومي الذي دعا له كيرنيغان.
أدوات LLM يمكنها إنتاج كود يعمل بسرعة، لكن "يعمل" ليس المقياس الذي أشار إليه كيرنيغان—المقياس هو التواصل. إذا كان فريقك يستخدم سير عمل يولّد كودًا من المحادثة، فالأفضل أن تعامل القابلية كمعيار قبول من الدرجة الأولى.
على منصات مثل Koder.ai، حيث يمكنك توليد واجهات React، باكندات Go، وتطبيقات Flutter من محادثة (ثم تصدير الشيفرة)، نفس عادات الذوق تنطبق:
السرعة ذات قيمة عندما يكون الناتج سهلًا للمراجعة البشرية والصيانة والتوسيع.
الوضوح ليس شيئًا "تصل إليه" مرة واحدة. يبقى الكود مقروءًا فقط إذا ظللت تدفعه نحو الكلام البسيط مع تغير المتطلبات. حساسية كيرنيغان تنطبق هنا: فضّل التحسينات البطيئة والقابلة للفهم على عمليات إعادة كتابة بطولية أو أسطر ذكية تبهر اليوم وتربك الشهر القادم.
أأمن إعادة تشكيل مملة: تغييرات صغيرة تحافظ على السلوك نفسه. إذا كانت لديك اختبارات، شغِّلها بعد كل خطوة. إن لم تكن لديك، أضف بعض الفحوص المركّزة حول المنطقة التي تلمسها—فكر بها كحواجز مؤقتة لتتمكن من تحسين البنية بلا خوف.
إيقاع عملي:
الالتزامات الصغيرة تجعل المراجعة أسهل: يمكن للزملاء الحكم على النية بدل البحث عن آثار جانبية.
لا تحتاج لطرد كل بنية "ذكية" دفعة واحدة. كلما لمست كودًا في ميزة أو إصلاح، بدّل الاختصارات بحلول مباشرة:
هكذا يفوز الوضوح في الفرق الحقيقية: بقعة محسنة في كل مرة تُلمس فيها المنطقة.
ليس كل التنظيف عاجلًا. قاعدة مفيدة: أعد التشكيل الآن إذا كان الكود يتغير بنشاط، يُفهم بصعوبة، أو من المرجح أن يسبب أخطاء. جدول التنظيف لاحقًا عندما يكون مستقرًا ومعزولًا.
اجعل دين إعادة التشكيل مرئيًا: اترك TODO قصيرة مع سياق، أو افتح تذكرة تصف الألم ("صعب إضافة طرق دفع جديدة؛ الدالة تقوم بخمس وظائف"). هكذا تقرر بشكل واعٍ—بدل أن يصبح الكود المشوش ضريبة دائمة.
إذا أردت أن يظهر "الذوق الجيد" باستمرار، اجعل ممارسته سهلة. هذه قائمة فحص خفيفة يمكنك إعادة استخدامها في التخطيط، الترميز، والمراجعة—قصيرة لتتذكر، ومحددة لتطبيقها.
قبل: process(data) يقوم بالتحقق، التحليل، الحفظ، والتسجيل في مكان واحد.
بعد: قسم إلى validateInput, parseOrder, saveOrder, logResult. تصبح الدالة الرئيسية مخططًا مقروءًا.
قبل: if not valid then return false مكرر خمس مرات.
بعد: قسم قيادة تحقق مركزية (أو دالة تحقق واحدة) تعيد قائمة مشاكل واضحة.
قبل: x, tmp, flag2, doThing().
بعد: retryCount, draftInvoice, isEligibleForRefund, sendReminderEmail().
قبل: حلقة بها ثلاث حالات خاصة مخفية في الوسط.
بعد: تعامل مع الحالات الخاصة أولًا (أو استخرج مساعدات)، ثم نفّذ الحلقة الواضحة.
اختر تحسينًا واحدًا لتتبناه هذا الأسبوع: "لا اختصارات جديدة"، "المسار السعيد أولًا"، "استخرج مساعدة واحدة لكل PR"، أو "كل رسالة خطأ تتضمن خطوات لاحقة". تتبعه سبعة أيام، ثم احتفظ بما جعل القراءة أسهل بالفعل.
تأثير كيرنيغان أقل ارتباطًا بلغة C وبيئة يونكس، وأكثر ارتباطًا بمبدأ ثابت: الكود وسيلة اتصال.
اللغات والأطر تتغير، لكن الفرق لا تزال بحاجة لكود سهل المسح والقراءة والمراجعة وتصحيح الأخطاء—وخاصة بعد مرور أشهر أو تحت ضغط الوقت.
«الذوق الجيد» يعني اختيار أبسط خيار واضح يوضح النية باستمرار.
اختبار مفيد: هل يستطيع زميلك الإجابة عن "ماذا يفعل هذا الكود ولماذا فُعل بهذه الطريقة؟" دون فك شفرات أو الاعتماد على افتراضات مخفية؟
لأن معظم الكود يُقرأ أكثر مما يُكتب.
التحسين للقراء يقلل وقت التعريف بالمشروع، يقلل احتكاك المراجعات، ويخفض خطر التعديلات الخاطئة—خصوصًا عندما يكون الصيانة على عاتق "أنت المستقبلي" مع سياق أقل.
الـ«ضريبة» تظهر كالتالي:
إذا وفّر الحل الذكي ثوانٍ الآن لكنه يكلف دقائق في كل تعديل لاحق، فهو خسارة صافية.
المشتبه بهم المعتادون:
هذه الأنماط تخفي حالات وسيطة وتجعل مراجعة الحواف أسهل أن تُفلت.
عندما يقلل العبء المعرفي.
جعل الخطوات صريحة بأسماء متوسطة (مثل validate → normalize → compute) يسهل التحقق من الصحة، يبسط تصحيح الأخطاء، ويجعل التغييرات المستقبلية أكثر أمانًا—حتى لو أضافت بعض الأسطر.
حاول:
invoiceTotalCents أفضل من sum)إذا احتجت لفك اسمٍ ما، فهو لا يقوم بعمله؛ الاسم يجب أن يقلل الحاجة للتعليقات.
فضل التفرعات البسيطة، وحافظ على "المسار السعيد" مرئيًا.
تكتيكات مفيدة:
علّق لماذا، لا ماذا.
التعليقات الجيدة تشرح النوايا، المقايضات، أو القواعد غير الواضحة. تجنّب شرح ما يوضحه الكود بالفعل، واعتبر تحديث التعليقات جزءًا من أي تغيير—التعليقات القديمة أسوأ من عدم وجودها.
استخدم الأدوات للقواعد الميكانيكية (التنسيق، الاستيرادات، أخطاء بسيطة)، واحتفظ بالمراجعات البشرية لمعنى الكود.
دليل أسلوب خفيف الطول يوقف تكرار الجدل. وعند استثناءات الأداء أو القيود، وثق المقايضة وعزل التعقيد وراء واجهة نظيفة.