البرمجة من الأسفل إلى الأعلى

1993

_(هذه المقالة مأخوذة من مقدمة كتاب On Lisp .)

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

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

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

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

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

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

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

3. يجعل التصميم من الأسفل إلى الأعلى البرامج أسهل في القراءة. يطلب مثال على هذا النوع من التجريد من القارئ فهم عامل تشغيل للأغراض العامة؛ ويطلب مثال على التجريد الوظيفي من القارئ فهم برنامج فرعي للأغراض الخاصة. [1]

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

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

صحيح أن أسلوب التطوير هذا مناسب بشكل أفضل للبرامج التي يمكن كتابتها بواسطة مجموعات صغيرة. ومع ذلك، في الوقت نفسه، فإنه يوسع حدود ما يمكن أن تفعله مجموعة صغيرة. في كتاب The Mythical Man-Month ، اقترح فريدريك بروكس أن إنتاجية مجموعة من المبرمجين لا تنمو خطيًا مع حجمها. مع زيادة حجم المجموعة، تنخفض إنتاجية المبرمجين الأفراد. تشير تجربة برمجة Lisp إلى طريقة أكثر بهجة لصياغة هذا القانون: مع انخفاض حجم المجموعة، تزداد إنتاجية المبرمجين الأفراد. تفوز المجموعة الصغيرة، نسبيًا، ببساطة لأنها أصغر. عندما تستفيد مجموعة صغيرة أيضًا من التقنيات التي تجعلها Lisp ممكنة، يمكنها الفوز بشكل كامل.

جديد: قم بتنزيل On Lisp مجانًا.

---

[1] "لكن لا يمكن لأحد قراءة البرنامج دون فهم جميع الأدوات المساعدة الجديدة الخاصة بك." لمعرفة سبب كون مثل هذه البيانات خاطئة عادةً، انظر القسم 4.8.