تمت مراجعة مراجعة صغيرة للكتاب البالغ من العمر عشرين عامًا
في عام 2016 ، وتم نشرها باستخدام تصحيحات صغيرة.
يسمى الاعتراف الأصلي للمؤلف "Zen of Windows 95 Programming". دع الرقم "95" لا يخيفك ، فالمخطط الرئيسي هو Zen بالضبط ، وليس أرقام الإصدارات المتغيرة بسرعة لنظام التشغيل الرئيسي في العقود الأخيرة. الكتاب عبارة عن مجموعة من التوصيات والممارسات لمطور عمودي (مكدس كامل) ، لا يسمح فقط بالبقاء على قيد الحياة في عالم البرمجة الحديثة ، ولكن أيضًا لإنتاج نتيجة الجودة المطلوبة.
في الصفحة 22 ، يعرف لو القارئ النموذجي: "متعصب الجودة". بالنسبة لأولئك الذين في الحياة راضون تمامًا عن العمل وفقًا لمنهجية "tyap-lyap-commissioning" ("x * yak-x * yak and production") ، فمن غير المرجح أن يساعد الكتاب.
هل الكتاب قديم؟ في البداية ، تم وصف تغيير سريع في المشهد في الفترة 1995-1996 ، عندما أصبح نظام التشغيل Windows 95 (بدرجة أقل NT) واسع الانتشار ، تغيرت واجهات البرمجة (APIs) أقل قليلاً من بالكامل ، في حين اتضح أن ذلك ضروري للحفاظ على وظيفة برامجها في ثلاثة إصدارات في وقت واحد أنظمة تشغيل مايكروسوفت. في ذلك الوقت ، كان لو غرينو نفسه يبلغ من العمر ثلاثين عامًا (ص 87).
شخص يشكو من التغيرات السريعة في التكنولوجيا الحديثة؟ حدث هذا منذ 25 عامًا عند التبديل من DOS إلى Windows ، وقبل 20 عامًا عند تغيير أنظمة 16 بت إلى 32 بت. مقارنةً بعام 1995 ، مثلت الهجرة الطويلة الحالية إلى أبنية 64 بت قمة درجة الدقة فيما يتعلق بمبرمجي التطبيقات المسيئين من المطبخ الداخلي للتحولات بواسطة العديد من طبقات التجريد والآلات الافتراضية.
لا يفوت المؤلف فرصة للتحدث عن جوهر البرمجة ، وكتابتها في "
حرفة استخدام مجموعة متنوعة من الأدوات في إنشاء مستويات من التجريد وتطبيقها لحل المشكلات المنطقية ". يبدو أن ما هو مطلوب آخر للحرفة ، إن لم يكن كتاب طبخ جيد؟ ومع ذلك ، يعلن Lou على الفور (ص 20) أن منهجه هو "
التحدث أكثر عما يجب عليك عدم فعله " و "
الاعتماد على حقيقة أنك ستحكم بشكل مستقل على كيفية تطبيق هذه النصيحة أو تلك ". بعد ذلك بقليل (ص 48) يقسم المبرمجين إلى "علماء رياضيات" و "مجوهرات".
هذا هو ، مثل طائرة. لكن ليس حقا. وأحيانا لا على الإطلاق. في
كتابي ، عرّفت هندسة البرمجيات بأنها "
سبيكة انتقائية من التقنيات التي يمكن استخدامها من قبل كل من هواة الإبداع الفني والإنتاج الضخم وفقًا للأنماط والسوابق " ، ومع ذلك ، لا أصر على التفسير. البرمجة واسعة للغاية بحيث يمكن للجميع ، إذا رغبت في ذلك ، أن يروا ويريدوا فيه ما يريد.
في الجزء التمهيدي ، يناقش لو بشكل عملي البرامج العامة والخاصة (أقسم بالإضافة إلى ذلك البرامج العامة إلى برامج مخصصة ومتكررة) ، حول مدى فائدة البرامج ، والمواقف تجاه المستخدمين ، ويقدم أمثلة كثيرة من فئة "قصص الرعب". ثم ، بقلب هادئ ، تنتقل (ص 63) إلى توصيات المستوى الكلي. يتضمن ذلك موضوعات مثل التعريب والإعدادات العالمية مع إمكانية توسيعها وتوثيقها وأسطورة الوثائق الذاتية وبيئة العمل وسهولة الاستخدام للواجهة واختبار وإعادة استخدام الكود والاختبارات الوظيفية وغير ذلك الكثير.
لم يتجاهل المؤلف مواضيع مهمة مثل الإهمال غير المقبول للتدريب والتعليم (ص 90) والحاجة إلى محو الأمية الاقتصادية (ص 73) "
يجب أن تكون خبيرًا اقتصاديًا ".
تعد مقارنات متطلبات موارد الكمبيوتر مثيرة للاهتمام (ص 88). في الواقع ، إذا أخذنا ، على سبيل المثال ، عينة Windows NT لعام 1996 ، ثم للعمل المريح مع التطبيقات (بيئة التطوير ، المكتب ، الإنترنت) ، كانت هناك حاجة إلى 16 ميغابايت من ذاكرة الوصول العشوائي ، بينما يحتاج نظام التشغيل نفسه إلى 8 ميغابايت. بالنسبة لنظام التشغيل Windows 7 أو 10 (مع نفس NT kernel) في عام 2016 ، يلزم وجود 4 غيغابايت من الذاكرة ، يستخدم نظام التشغيل منها 1 غيغابايت فقط. نسبة 1: 2 حتى انخفض إلى 1: 4. ومن هنا جاءت النتيجة المخيبة للآمال: المشاكل ليست في نظام التشغيل بقدر ما هي في البرامج.
في الصفحة 105 ، ينتقل المؤلف بسلاسة إلى توصيات المستوى الجزئي. ماذا لو يرى الاختلافات بين المستويات الكلية والصغرى؟ نعم ، الحقيقة هي أنه في حالة عدم وجود تصميم ، فإن المبرمج ينتقل على الفور إلى المستوى الجزئي ، ولا حتى يشك في أن المشكلات التي تتدفق فيه تنجم إلى حد كبير عن إهمال المهام الكلية.
في الطبيعة ، لا يوجد اقتصاديون يعرفون الاقتصاد الكلي أو الجزئي فقط. هذه ليست سوى المشعوذين. لكن بين أولئك الذين يطلقون على أنفسهم مبرمجين ، فإن مثل هذا الدجال في ترتيب الأشياء!
في الفصل على المستوى الجزئي ، يقدم المؤلف أيضًا الكثير من النصائح المفيدة. أعجبتني هذه الرسالة (الصفحة 109): "
لا تحقق أبدًا من وجود خطأ لا تعرف كيفية معالجته ." قد يبدو أن النصيحة من سلسلة من "الضارة" من G. أوستر ، ولكن هذا هو الانطباع الخاطئ. لقد صادفت أجزاء من التعليمات البرمجية مثل
try... catch أو
try... except عدة مرات ، حيث كانت الكتلة
catch/except فارغة. لأن الخطأ ظهر أحيانًا ، ولم يكن المبرمج على مستواه الصغير يعرف كيفية التعامل معه. لا يبدو هذا الرمز قبيحًا فحسب ، بل إنه أيضًا خطير للغاية ، لأنه يؤدي إلى عواقب لا يمكن التنبؤ بها على مستويات أخرى من التجريد.
يتم تخصيص النص التالي لمجموعة متنوعة من الموضوعات التي يتم مواجهتها باستمرار على طول مسار المطورين الرأسيين. سأدرج فقط عدد قليل.
- كيفية تجنب "السلبيات الخاطئة" عندما يكون البرنامج بجنون العظمة في منع المستخدم من القيام بأي إجراءات (مثل LooksLike () بدلاً من Is ()).
- فصل رمز واجهة المستخدم عن المنطق. دون إلقاء تعويذات MVC / MVP ، يسرد المؤلف جميع مزايا هذا النهج ، دون أن يغفل عن السلبيات التي تتكون أساسًا من أعمال إضافية خطيرة.
- أي تغييرات في مكتبات الإطار معلقة على مبرمج تحميل دعمهم عند تغيير الإصدارات. تتحول مشكلة adhoc لحلها بسرعة إلى صداع عند تحديث الإطار.
- حول فوائد ملفات التكوين الثنائية وحماية سلامة البرنامج وموارده.
- قواعد بسيطة لاستخدام DLL. ينطبق أيضًا على التجميعات .NET الحديثة غير الموجودة في ذاكرة التخزين المؤقت العمومية.
- ... وأكثر من ذلك بكثير
في الصفحة 147 ، يستشهد Lou بخصيتين متطرفتين للمبرمجين ، Gizmonauts و Neoluddites. الحقيقة ، كالعادة ، في مكان ما بين. لا يمكنك اختيار التقنيات والأدوات لمجرد أنها جديدة. ولكن من المستحيل الوقوف ضد قرون في البيئات والأساليب القديمة إذا كان هناك فائدة من التحديث.
هناك بعض النقاط في الكتاب التي تبدو مضحكة من 2019 ، على سبيل المثال (ص 154) ، توصيات لتخزين نسخ ورقية من مصادر برامجهم. المخطوطات ، بالطبع ، لا تحترق ، ولكن ...
على الرغم من أن المؤلف هو مطور محترف لـ C ++ ، في الصفحات 167-180 ، يقدم Lou الكثير من الأسباب لاستخدام Delphi "
في جميع المشاريع الجديدة ". في الواقع ، لم يكن ظهور دلفي في عام 1995 أقل ثورية من إصدار Windows 32 بت الجديد.
عند التراجع عن الكتاب ، من المضحك في عام 2019 سماع أقوال تفيد بأن دلفي منتج قديم. وهذا جافا أو C # ، مثل - البيئات الحديثة. اسمحوا لي أن أذكركم بأن Java لم تظهر إلا بعد عام واحد ، ثم C # - بعد أربع سنوات. بالنسبة للمبرمج الذي بدأ عملياته في مكان ما حول عام 2010 ، يجب أن تبدو هذه الأسماء الثلاثة مثل Kobol أو Fortran.
وفقًا لـ Lou منذ عام 1996 (ص 146) ، فإن الوضع المعتاد هو أن المبرمج في عجلة من أمره يرتكب خطأ ، وليس لديه وقت لدراسة البدائل ، واختيار طريق غير طبيعي بدافع الجهل. للمطورين ذوي الخبرة في هذه الحالة ، القرار الصحيح هو الاستماع إلى مشاعرك.
هذه هي برمجة Zen في أي بيئة. الذي أتمنى لك أيضا.