يوم جيد ، كنت أقوم بالبرمجة لمدة 8 سنوات ، والبرمجة بجميع مظاهرها: تطوير جانب الخادم بلغات برمجة مختلفة ، تطوير جانب العميل ، برمجة الشبكات ، إدارة لينكس ، وتحسين الأداء. وعندما تكون مشغولاً بنشاط تجاري منذ وقت طويل ، وتحبه بصدق وتسعى لتطوير الذات ، فلا بد من ظهور علاقات سببية مختلفة في المجال المقابل ، تبدأ في رؤية تلك العلاقات التي لم تكن تعرفها من قبل أو ببساطة اعتبرتها غير ذات أهمية ، هذا ما يسميه الناس الخبرة.
وهي عن إحدى هذه العلاقات السببية التي أود مشاركتها معك في هذه المقالة. فكرت أن أكتب أن هذه واحدة من أهم علاقات السبب والنتيجة حتى تكون أقل جذرية قليلاً ، ولكن لا تزال كذلك ، فإن علاقة السبب والنتيجة هي أهم علاقة السبب والنتيجة في البرمجة بهامش ضخم. يتم تشغيله مثل مؤشر الترابط من خلال جميع مجالات البرمجة تمامًا: كتابة التعليمات البرمجية ، وتصميم واجهة ، ونشر تطبيق ، وتنظيم فريق ، والحفاظ على تعقب الأخطاء ، وما إلى ذلك. وأنا أسمي هذه العلاقة السببية المقدسة
الحد من المتغيرات .
أعني بمصطلح المتغير ليس فقط المتغيرات العادية (التي يتم الإعلان عنها عبر الكلمات الرئيسية
var ،
let ،
function ) ، ولكن أيضًا المتغيرات بمعنى أكثر تجريدًا للكلمة: المجلدات التي تم إنشاؤها في شجرة المشروع ، المكتبات المتصلة ، عدد مكالمات ajax إلى الخادم ، الرقم مكونات في الواجهة ، عدد البروتوكولات التي يجب أن يتبعها المبرمج عند تنفيذ التعليمات البرمجية (على سبيل المثال ، مراجعة التعليمات البرمجية ، كل ميزة في وجبة فطور منفصلة) وهكذا.
في الواقع ، إن عملية البرمجة بأكملها عبارة عن تعداد للأصناف في اتجاه كيفية تنفيذ هذه الوظيفة أو تلك الوظيفية باستخدام أقل عدد ممكن من المتغيرات (على الأقل أنظر إلى البرمجة من هذا المنظور). الكود الذي يطبق الميزة مع عدد أقل من التبعيات / الملفات / أسطر الكود أفضل من الكود الذي يطبق نفس الوظيفة مع عدد كبير من المتغيرات. إذا كانت فئة الأداة المساعدة تحتوي على وظيفة واحدة فقط - تحتاج إلى التخلص من فئة الأداة المساعدة هذه ، إذا كانت الوظيفة تتكون من سطر واحد فقط - فأنت بحاجة إلى التخلص من هذه الوظيفة إذا كان هناك 10 أسطر فقط من التعليمات البرمجية في المكون - فأنت بحاجة إلى حذف هذا المكون إذا كان هناك ملف واحد فقط في المجلد - أنت بحاجة للتخلص من هذا المجلد ، وهلم جرا. وعندما تتم إضافة عدة آلاف من هذه التغييرات التي تبدو غير ذات أهمية معًا ، تكون النتيجة رمزًا جميلًا وموجزًا وبسيطًا للغاية يسهل قراءته. الشيطان يكمن في التفاصيل كما يقولون.
فيما يلي قائمة بالتأثيرات الإيجابية التي تظهر عند بدء البرمجة بناءً على مبدأ تقليل المتغيرات:
- أخطاء أقل. نظرًا لكتابة رمز أقل ، يتم تقليل عدد الأماكن التي يمكنك ارتكاب خطأ فيها بالمقابل.
- من السهل تقديم أشخاص جدد إلى المشروع. يتناسب تعقيد المشروع بشكل مباشر مع عدد المتغيرات في هذا المشروع ، وكلما كانت المتغيرات أقل ، كان من السهل إدخال أشخاص جدد.
- أسهل لإضافة وظائف جديدة. نظرًا لأنه من الضروري دراسة كمية أقل من التعليمات البرمجية ، يصبح من السهل "تحميل" الوظيفة في الرأس ، ونتيجة لذلك ، قم بإضافة وظائف جديدة أو تعديل التعليمات البرمجية الموجودة.
- القدرة على التنبؤ. تصبح عملية البرمجة أكثر قابلية للتنبؤ بها ، يصبح من الأسهل بالنسبة لك التنبؤ بالوقت الذي يستغرقه تطوير ميزة أو أخرى بسبب حقيقة أن عدد "الكمامات" يتم تقليله. عادة ، المقابس هي التي تسبب أكبر عدد من المشاكل ، وتؤدي إلى تأخير المواعيد النهائية.
ولكن في كثير من الأحيان يحدث الموقف المعاكس ، يبدأ المبرمجون في تأكيد أنفسهم من خلال إدخال متغيرات جديدة. نقدم 20 مكتبة مختلفة ، وأطر CSS ،
وننشئ عددًا كبيرًا من الملخصات متعددة المستويات مثل
UserFactoryManager (خاصة مبرمجي جافا يخطئون لسبب ما) ،
وننشئ العديد من الأدلة ،
ونقدم منهجيات تطوير أكثر تقدمًا ، ونضيف المزيد من البروتوكولات قبل تنفيذ الملفات ، وهكذا دواليك. ويمكن فهم الدافع وراء هذه القرارات ، لأنها تخلق وهمًا من الاحتراف ، ويقولون انظر إلى مقدار معرفتي ، وما هي التجريدات المعقدة التي يمكنني التعامل معها. ولكن غالبًا ما يتسبب هذا في ضرر فادح للمشروع.
لا تفهموني بشكل خاطئ ، فأنا لست ضد استخدام منهجيات وأطر وتقنيات أكثر تقدمًا ، بل أقول إنها غالبًا ما يتم تقديمها ببساطة بسبب الضجيج ، وليس لأن هذه التكنولوجيا تحل أي مشكلة ملحة في المشروع.
يمكن أن يسمى حل مشكلة كميات كبيرة جدًا من المتغيرات
بإفراط . ولكن يجب أن تعترف أنه إذا وصفت هذا الموقف كما لو أن المشكلة يتم حلها بواسطة العديد من المتغيرات ، فهذا وصف أكثر دقة لهذه الظاهرة.
في كثير من الأحيان ، يتم تبرير إدخال المتغيرات الجديدة من خلال قابلية التوسع ، حيث يقولون إذا قمت بإنشاء
UserManagerFactory هنا ، فيمكننا أخذ وظيفة وإضافتها في أي وقت إذا لزم الأمر. ولكن في الواقع ، لا تكون قابلية التوسع عندما يتم إدخال العديد من المتغيرات ، ولكن عندما يكون هناك عدد قليل من المتغيرات. فكر في المكان الذي سيكون من الأسهل بالنسبة لك فيه كتابة وظائف جديدة: في محرك متصفح Chrome أو في مشروع جديد تمامًا تكتبه من البداية؟
لا يؤدي إدخال متغيرات جديدة إلى قابلية التوسع في الهندسة المعمارية. ما يحسن قابلية تطوير المشروع حقًا هو عندما تقوم بإزالة المتغيرات غير الضرورية وتبسيط التعليمات البرمجية الموجودة.
هناك عدد كبير من المتغيرات غير الضرورية - وهذا هو بالضبط السبب الذي يجعلني أكره لغة برمجة Scala مع الكراهية الشديدة ، والسبب الذي يجعلني أحب جافا سكريبت. سكالا ليست سوى جوهر نظام معقد للغاية ومربك للغاية ، والعديد من المفاهيم التي تكرر بعضها البعض ، والتحويلات الضمنية ، وعدد كبير من الطرق للقيام بنفس الشيء. عندما أستخدم لغة البرمجة هذه ، لا أفكر في
ما يجب القيام به ، ولكن حول
كيفية القيام بذلك. غالبًا ما أجد نفسي الآن ، وهدفي هو فقط إغلاق المحول البرمجي. من ناحية أخرى ، جافا سكريبت هي عكس Scala تمامًا ، فهي مرتبة من حيث الحجم أضيق الحدود ، باستخدامها أقضي الكثير من الجهد العقلي للتعبير عن مفهوم أو آخر. بالطبع ، هذه البساطة لها أيضًا عيوبها ، على سبيل المثال ، في Scala ، يقوم المترجم بالإبلاغ عن خطأ في مرحلة التجميع ، بينما في JavaScript يمكنك فقط التعرف على خطأ في وقت التشغيل ومن المستحيل بشكل أساسي أن تقوم JavaScript بكتابة IDE الوظيفي نفسه مثل تلك المكتوبة بقوة اللغات ، لكن هؤلاء هم الضحايا الذين أنا على استعداد للتوفيق معهم.
يجب تطبيق مبدأ تقليل المتغيرات عند تصميم واجهات ، على سبيل المثال ، دعنا نقارن واجهات الويب لشبكتين
اجتماعيتين متنافستين للتعارف بين
Tinder و
Badoo . في الواقع ، هناك صفحة واحدة فقط في واجهة الويب لـ Tinder ، ويتم عرض ملف تعريف المستخدم والدردشات النشطة والبحث عن معارف جدد في صفحة واحدة ولا توجد حاجة للتبديل إلى صفحات أخرى ، في هذه الواجهة يتم تلبية جميع احتياجات المستخدم من خلال الحد الأدنى من المكونات. بينما في Badoo ، يتم تنفيذ وظيفة التبديل إلى ملف تعريف المستخدم وواجهة الرسالة وصفحة البحث عن أزواج كصفحات منفصلة ، يحتاج المستخدم إلى القيام بمزيد من الإجراءات لتلبية الاحتياجات ، وبالتالي فإن هذه الواجهة أقل كفاءة. بالطبع ، هذا مجرد مثال صغير جدًا ، ولكن عندما يكون هناك العشرات والمئات من هذه الأمثلة ، فإنهم جميعًا يحددون ما إذا كانت الواجهة قد تم التفكير فيها أم لا.
عند تصميم الواجهة ، من الضروري إنشاء الحد الأدنى من المكونات من أجل تلبية احتياجات المستخدم.لنفس السبب ، لا أحب على الإطلاق النهج التي تفصل بين المنطق والبيانات والعرض التقديمي ، لأنه في هذه الحالة ينشأ موقف لكتابة قطعة واحدة من الوظائف تحتاج إلى إنشاء ثلاثة ملفات ، ثم يبدأ عدد المكونات في النمو ، وعندما يصبح المشروع كبيرًا بالفعل ، ثم يبدأ عدد الملفات بالتدحرج على جميع الحدود المعقولة. على سبيل المثال ، عند كتابة واجهات الويب ، عادةً ما يتم وصف الأنماط في ملفات منفصلة ، في حين أن العقد التي يتم إرفاق هذه الأنماط بها موجودة في ملف آخر. غريب كما قد يبدو ، الدافع الرئيسي لمثل هذا الفصل هو التوسع ، لذلك إذا قمت بفصل العقد نفسها وأنماطها ، فسيصبح من الأسهل التنقل في المشروع ، وسيكون من الممكن تطوير هذين الجزأين من الوظيفة بشكل مستقل. ولكن دعنا نرى المتغيرات التي تمت إضافتها باستخدام هذا النهج: الملفات الجديدة ذات الأنماط لكل مكون ، المحددات (تصف العقدة التي ترتبط الأنماط بها) ، قواعد المتتالية (إذا كان العديد من المحددات يعالجون نفس العقدة). بينما إذا قمت بكتابة الأنماط مباشرة في العقد التي يجب أن ترتبط بها هذه الأنماط (على سبيل المثال ، من خلال سمة النمط) ، فلن تكون هناك حاجة إلى جميع هذه المتغيرات الإضافية ، مما يبسط الرمز كثيرًا. في الآونة الأخيرة ، أصبح هذا النهج شائعًا بشكل متزايد ، وهناك العديد من المكتبات التي تسمح لك بكتابة الأنماط مباشرة في سمة النمط.
يجب إدخال المتغيرات الجديدة في المشروع بشكل تدريجي. على سبيل المثال ، في البداية ، عند كتابة مشروع ، لدي جميع الملفات في الدليل الجذر ، دون أي أدلة فرعية على الإطلاق ، لمجرد أنها أسهل ، وفقط عندما ينمو عدد الملفات إلى 40-60 ملفًا ، يتم تجميع بعض الملفات في الدلائل. في البداية ، ليست هناك حاجة إلى منهجية تطوير ، فقط رمي جميع المبرمجين في كومة ، وأعطهم مهامًا ، ثم سيكتشفونها بأنفسهم ، إذا تم تقديم منهجية التطوير مبكرًا جدًا ، فسوف تشعر وكأنها نوع من المفهوم البديل. عندما يتم إدخال المتغيرات قبل الحاجة إليها ، يسمى هذا التحسين المبكر.
بنفس الطريقة ، من الضروري تقليل المتغيرات عند كتابة الوثائق / المقالات ، عندما أكتب الوثائق ، أفكر دائمًا في ما هو بالضبط الحد الأدنى لعدد الجمل التي أحتاجها لنقل أفكاري. أقوم بتحليل كل جملة حرفيًا ، وإذا بدا لي أن هذه الجملة ليست ضرورية ، فلا تتحمل أي حمل دلالة إضافية ، ثم يتم حذفها ، ونتيجة لذلك يتم الحصول على صفحة مضغوطة للغاية مع الوثائق ، والتي تحتوي على الحد الأقصى من المعلومات الضرورية في الحد الأدنى من النص.
في الواقع ، بشكل عام ، أي متغير لديه افتراض الذنب ، لا حاجة لمتغير حتى يثبت العكس.
يمكنك أن تعترض علي ، كما يقولون لي ، اكتشفت أمريكا ، وهي معروفة منذ فترة طويلة ويتم وصفها بمبادئ مثل:
Okama razor ،
SOLID . لكنني أفضل أن أسمي هذا المفهوم "تقليل المتغيرات" ، وذلك ببساطة لأن هذا التفسير مقتضب للغاية في الرأس ، وبالتالي ، فإنه من الأسهل بكثير التمسك به عمليًا. كم منكم يمكن أن يتباهى بتذكر كل نقطة من مبدأ SOLID؟
يكتب المبتدئون رمزًا بسيطًا لأنهم لا يعرفون كيفية كتابة رمز معقد ، ويكتب المبرمجون العاديون رمزًا معقدًا ، ببساطة لأنهم يستطيعون ، يكتب المحترفون رمزًا بسيطًا لأنهم لا يريدون كتابة رمز معقد.
يجب أن نتذكر أن أي متطرف سيئ: إذا كان متعصبًا لتقليل المتغيرات إلى المستوى الذري ، فإن هذا النهج ، بالإضافة إلى إدخال الكثير من المتغيرات يعد متطرفًا. وأي تطرف ، كما تعلمون ، سيئ ، فالحقيقة دائمًا ما تكون في مكان بينهما.