الاحتفاظ ببرنامج في الذهن
أغسطس 2007
يمكن للمبرمج الجيد الذي يعمل بشكل مكثف على شيفرته الخاصة أن يحتفظ بها في ذهنه بالطريقة التي يحتفظ بها عالم الرياضيات بمشكلة يعمل عليها. لا يجيب علماء الرياضيات على الأسئلة عن طريق حلها على الورق بالطريقة التي يُدرّس بها طلاب المدارس. إنهم يفعلون المزيد في رؤوسهم: إنهم يحاولون فهم مساحة المشكلة بشكل كافٍ بحيث يمكنهم التجول فيها كما يمكنك التجول في ذاكرة المنزل الذي نشأت فيه. في أفضل حالاتها، البرمجة هي نفسها. تحتفظ بالبرنامج بأكمله في رأسك، ويمكنك معالجته حسب الرغبة.
هذا ذو قيمة خاصة في بداية المشروع، لأنه في البداية أهم شيء هو أن تكون قادرًا على تغيير ما تفعله. ليس فقط لحل المشكلة بطريقة مختلفة، ولكن لتغيير المشكلة التي تحلها.
شيفرتك هي فهمك للمشكلة التي تستكشفها. لذلك فقط عندما تكون شيفرتك في رأسك تفهم المشكلة حقًا.
ليس من السهل تحميل برنامج في رأسك. إذا تركت مشروعًا لبضعة أشهر، فقد يستغرق الأمر أيامًا لفهمه حقًا مرة أخرى عندما تعود إليه. حتى عندما تعمل بنشاط على برنامج، قد يستغرق الأمر نصف ساعة لتحميله في رأسك عندما تبدأ العمل كل يوم. وهذا في أفضل الأحوال. المبرمجون العاديون الذين يعملون في ظروف مكتبية نموذجية لا يدخلون أبدًا في هذا الوضع. أو بعبارة أكثر دراماتيكية، المبرمجون العاديون الذين يعملون في ظروف مكتبية نموذجية لا يفهمون حقًا المشاكل التي يحلونها.
حتى أفضل المبرمجين لا يحملون دائمًا البرنامج بأكمله الذي يعملون عليه في رؤوسهم. ولكن هناك أشياء يمكنك القيام بها للمساعدة:
- تجنب المشتتات. المشتتات سيئة للعديد من أنواع العمل، ولكنها سيئة بشكل خاص للبرمجة، لأن المبرمجين يميلون إلى العمل على الحد الأقصى للتفاصيل التي يمكنهم التعامل معها.
يعتمد خطر التشتيت ليس على مدته، بل على مدى فوضويته لعقلك. يمكن للمبرمج أن يغادر المكتب ويذهب للحصول على شطيرة دون أن يفقد الشيفرة في رأسه. لكن النوع الخاطئ من المقاطعة يمكن أن يمسح عقلك في 30 ثانية.
من الغريب أن المشتتات المجدولة قد تكون أسوأ من غير المجدولة. إذا كنت تعلم أن لديك اجتماعًا في غضون ساعة، فلن تبدأ حتى في العمل على شيء صعب.
- العمل في فترات طويلة. نظرًا لوجود تكلفة ثابتة في كل مرة تبدأ فيها العمل على برنامج، فمن الأكثر كفاءة العمل في عدد قليل من الجلسات الطويلة بدلاً من العديد من الجلسات القصيرة. سيكون هناك بالطبع نقطة تصل فيها إلى الغباء لأنك متعب. هذا يختلف من شخص لآخر. سمعت عن أشخاص يبرمجون لمدة 36 ساعة متواصلة، لكن أقصى ما تمكنت من إدارته هو حوالي 18 ساعة، وأنا أعمل بشكل أفضل في أجزاء لا تزيد عن 12 ساعة.
الأمثل ليس الحد الذي يمكنك تحمله جسديًا. هناك ميزة بالإضافة إلى تكلفة تقسيم المشروع. في بعض الأحيان عندما تعود إلى مشكلة بعد فترة راحة، تجد أن عقلك الباطن قد ترك إجابة تنتظرك.
- استخدام لغات موجزة. لغات البرمجة الأكثر قوة تجعل البرامج أقصر. ويبدو أن المبرمجين يفكرون في البرامج على الأقل جزئيًا باللغة التي يستخدمونها لكتابتها. كلما كانت اللغة أكثر إيجازًا، كان البرنامج أقصر، وكان من الأسهل تحميله والاحتفاظ به في رؤوسهم.
يمكنك تضخيم تأثير لغة قوية باستخدام أسلوب يسمى البرمجة من الأسفل إلى الأعلى، حيث تكتب البرامج في طبقات متعددة، تعمل الطبقات السفلية كلغات برمجة لتلك التي فوقها. إذا قمت بذلك بشكل صحيح، فأنت تحتاج فقط إلى الاحتفاظ بالطبقة العليا في رأسك.
-
استمر في إعادة كتابة برنامجك. غالبًا ما تؤدي إعادة كتابة البرنامج إلى تصميم أنظف. ولكن سيكون لها مزايا حتى لو لم تفعل ذلك: عليك أن تفهم البرنامج بالكامل لإعادة كتابته، لذلك لا توجد طريقة أفضل لتحميله في رأسك.
-
اكتب شيفرة قابلة لإعادة القراءة. كل المبرمجين يعرفون أنه من الجيد كتابة شيفرة قابلة للقراءة. لكنك أنت نفسك أهم قارئ. خاصة في البداية؛ النموذج الأولي هو محادثة مع نفسك. وعند الكتابة لنفسك لديك أولويات مختلفة. إذا كنت تكتب للآخرين، فقد لا ترغب في جعل الشيفرة كثيفة جدًا. قد تكون بعض أجزاء البرنامج أسهل في القراءة إذا قمت بتوزيع الأشياء، مثل كتاب مدرسي تمهيدي. بينما إذا كنت تكتب شيفرة لجعلها سهلة التحميل في رأسك، فقد يكون من الأفضل السعي للإيجاز.
-
العمل في مجموعات صغيرة. عندما تعالج برنامجًا في رأسك، يميل رؤيتك إلى التوقف عند حافة الشيفرة التي تمتلكها. الأجزاء الأخرى لا تفهمها جيدًا، والأهم من ذلك، لا يمكنك اتخاذ حريات معها. لذا كلما قل عدد المبرمجين، زادت قدرة المشروع على التحول. إذا كان هناك مبرمج واحد فقط، كما هو الحال غالبًا في البداية، يمكنك إجراء عمليات إعادة تصميم شاملة.
-
لا تجعل عدة أشخاص يحررون نفس قطعة الشيفرة. أنت لا تفهم أبدًا شيفرة الآخرين بقدر ما تفهم شيفرتك الخاصة. بغض النظر عن مدى قراءتك لها بعناية، فقد قرأتها فقط، ولم تكتبها. لذا إذا كانت قطعة شيفرة مكتوبة من قبل مؤلفين متعددين، فلا أحد منهم يفهمها بقدر ما يفهمه مؤلف واحد.
وبالطبع لا يمكنك إعادة تصميم شيء يعمل عليه الآخرون بأمان. ليس الأمر فقط أنك ستحتاج إلى طلب الإذن. أنت لا تسمح لنفسك حتى بالتفكير في مثل هذه الأشياء. إعادة تصميم الشيفرة مع عدة مؤلفين يشبه تغيير القوانين؛ إعادة تصميم الشيفرة التي تتحكم فيها وحدك يشبه رؤية التفسير الآخر لصورة غامضة.
إذا كنت تريد وضع عدة أشخاص للعمل على مشروع، فقم بتقسيمه إلى مكونات وامنح كل واحد لشخص واحد.
- ابدأ صغيرًا. يصبح البرنامج أسهل في الاحتفاظ به في رأسك كلما أصبحت مألوفًا به. يمكنك البدء في التعامل مع الأجزاء كصناديق سوداء بمجرد أن تشعر بالثقة في أنك استكشفتها بالكامل. ولكن عندما تبدأ لأول مرة في العمل على مشروع، فأنت مجبر على رؤية كل شيء. إذا بدأت بمشكلة كبيرة جدًا، فقد لا تتمكن أبدًا من استيعابها بالكامل. لذا إذا كنت بحاجة إلى كتابة برنامج كبير ومعقد، فإن أفضل طريقة للبدء قد لا تكون كتابة مواصفات له، بل كتابة نموذج أولي يحل جزءًا من المشكلة. مهما كانت مزايا التخطيط، غالبًا ما تفوقها مزايا القدرة على الاحتفاظ ببرنامج في رأسك.
من المدهش كم مرة ينجح المبرمجون في تحقيق جميع النقاط الثماني عن طريق الصدفة. شخص ما لديه فكرة لمشروع جديد، ولكن نظرًا لأنه غير مصرح به رسميًا، يتعين عليه القيام به في أوقات فراغه - والتي تبين أنها أكثر إنتاجية لأنه لا توجد مشتتات. مدفوعًا بحماسه للمشروع الجديد، يعمل عليه لساعات عديدة متواصلة. نظرًا لأنه مجرد تجربة في البداية، بدلاً من لغة "إنتاج"، فإنه يستخدم مجرد لغة "برمجة نصية" - وهي في الواقع أقوى بكثير. يقوم بإعادة كتابة البرنامج بالكامل عدة مرات؛ لن يكون ذلك مبررًا لمشروع رسمي، ولكنه عمل حب ويريد أن يكون مثاليًا. وبما أنه لا أحد سيراه باستثنائه، فإنه يتجاهل أي تعليقات باستثناء تلك التي تشبه الملاحظات الذاتية. يعمل في مجموعة صغيرة بحكم الضرورة، لأنه إما لم يخبر أي شخص آخر بالفكرة بعد، أو تبدو واعدة جدًا لدرجة أنه لا يُسمح لأي شخص آخر بالعمل عليها. حتى لو كانت هناك مجموعة، فلا يمكن أن يكون لديهم عدة أشخاص يحررون نفس الشيفرة، لأنها تتغير بسرعة كبيرة لدرجة أن ذلك مستحيل. ويبدأ المشروع صغيرًا لأن الفكرة صغيرة في البداية؛ لديه فقط اختراق رائع يريد تجربته.
والأكثر إثارة للدهشة هو عدد المشاريع المصرح بها رسميًا التي تدير القيام بكل الأشياء الثمانية بشكل خاطئ. في الواقع، إذا نظرت إلى الطريقة التي تُكتب بها البرامج في معظم المؤسسات، فإنه يبدو تقريبًا كما لو كانوا يحاولون عمدًا القيام بالأشياء بشكل خاطئ. بمعنى ما، هم كذلك. أحد الصفات المميزة للمؤسسات منذ وجودها هو معاملة الأفراد كأجزاء قابلة للتبديل. هذا يعمل بشكل جيد للمهام الأكثر قابلية للموازاة، مثل خوض الحروب. بالنسبة لمعظم التاريخ، يمكن الاعتماد على جيش مدرب جيدًا من الجنود المحترفين للتغلب على جيش من المحاربين الأفراد، بغض النظر عن مدى شجاعتهم. لكن وجود الأفكار ليس قابلاً للموازاة بدرجة كبيرة. وهذا ما هي عليه البرامج: الأفكار.
ليس الأمر مجرد أن المؤسسات تكره فكرة الاعتماد على العبقرية الفردية، بل هو حقيقة بديهية. إنه جزء من تعريف المؤسسة ألا تفعل ذلك. من مفهومنا الحالي للمؤسسة، على الأقل.
ربما يمكننا تعريف نوع جديد من المؤسسات يجمع جهود الأفراد دون الحاجة إلى أن يكونوا قابلين للتبديل. يمكن القول بأن السوق هو شكل من أشكال التنظيم، على الرغم من أنه قد يكون من الأدق وصف السوق بأنه حالة متدهورة - كما تحصل عليه افتراضيًا عندما يكون التنظيم غير ممكن.
ربما أفضل ما يمكننا القيام به هو نوع من الاختراق، مثل جعل الأجزاء البرمجية للمؤسسة تعمل بشكل مختلف عن الباقي. ربما الحل الأمثل للشركات الكبيرة هو عدم محاولة تطوير الأفكار داخليًا، بل ببساطة شرائها. ولكن بغض النظر عن الحل الذي سيتبين أنه كذلك، فإن الخطوة الأولى هي إدراك أن هناك مشكلة. هناك تناقض في عبارة "شركة برمجيات" نفسها. الكلمتان تسحبان في اتجاهين متعاكسين. أي مبرمج جيد في مؤسسة كبيرة سيكون على خلاف معها، لأن المؤسسات مصممة لمنع ما يسعى إليه المبرمجون.
ينجح المبرمجون الجيدون في إنجاز الكثير على أي حال. ولكن غالبًا ما يتطلب الأمر عمليًا عملاً تمردًا ضد المؤسسات التي توظفهم. ربما سيساعد إذا فهم المزيد من الناس أن الطريقة التي يتصرف بها المبرمجون مدفوعة بمتطلبات العمل الذي يقومون به. ليس لأنهم غير مسؤولين أنهم يعملون في فترات طويلة ينقطعون فيها عن جميع الالتزامات الأخرى، ويغوصون مباشرة في البرمجة بدلاً من كتابة المواصفات أولاً، ويعيدون كتابة الشيفرة التي تعمل بالفعل. ليس لأنهم غير ودودين أنهم يفضلون العمل بمفردهم، أو يزمجرون على الأشخاص الذين يفتحون الباب لإلقاء التحية. هذه المجموعة التي تبدو عشوائية من العادات المزعجة لها تفسير واحد: قوة الاحتفاظ ببرنامج في رأس المرء.
سواء كان فهم هذا يساعد المؤسسات الكبيرة أم لا، فإنه بالتأكيد يمكن أن يساعد منافسيها. أضعف نقطة في الشركات الكبيرة هي أنها لا تسمح للمبرمجين الأفراد بالقيام بعمل رائع. لذا إذا كنت شركة ناشئة صغيرة، فهذا هو المكان لمهاجمتهم. تولى نوع المشاكل التي يجب حلها في دماغ واحد كبير.
شكر لـ Sam Altman، David Greenspan، Aaron Iba، Jessica Livingston، Robert Morris، Peter Norvig، Lisa Randall، Emmett Shear، Sergei Tsarev، و Stephen Wolfram لقراءة مسودات هذا.