التصميم والبحث

يناير 2003

(هذه المقالة مستمدة من كلمة رئيسية ألقيت في اجتماع NEPLS في خريف عام 2002.)

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

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

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

ما سأتحدث عنه اليوم هو ما يبدو عليه هدفك من الخلف. ماذا تفعل بشكل مختلف عندما تتعامل مع لغات البرمجة كمشكلة تصميم بدلاً من موضوع بحث؟

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

لاحظ أنني قلت "ما يحتاجونه"، وليس "ما يريدونه". لا أقصد إعطاء انطباع بأن العمل كمصمم يعني العمل كنوع من طاهٍ سريع، يصنع ما يطلبه العميل منك. هذا يختلف من مجال إلى آخر في الفنون، لكنني لا أعتقد أن هناك أي مجال يتم فيه القيام بأفضل عمل من قبل الأشخاص الذين يصنعون بالضبط ما يخبرهم به العملاء.

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

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

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

هذا التركيز على المستخدم هو نوع من البديهيات التي يمكن اشتقاق معظم ممارسات التصميم الجيد منها، وحولها تتمحور معظم قضايا التصميم.

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

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

هذه مشكلة، لأن النظر إلى المستخدم بازدراء، مهما كان خيراً، يبدو أنه يفسد المصمم حتماً. أشك في أن عدداً قليلاً جداً من المشاريع السكنية في الولايات المتحدة صممها مهندسون معماريون توقعوا العيش فيها. يمكنك رؤية نفس الشيء في لغات البرمجة. تم إنشاء C و Lisp و Smalltalk لمصمميها لاستخدامها. تم إنشاء Cobol و Ada و Java لأشخاص آخرين لاستخدامها.

إذا كنت تعتقد أنك تصمم شيئاً للأغبياء، فإن الاحتمالات هي أنك لا تصمم شيئاً جيداً، حتى للأغبياء.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

التصميم يعني صنع الأشياء للبشر. لكن ليس المستخدم فقط هو الإنسان. المصمم إنسان أيضاً.

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

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

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

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

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

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

ذات صلة: