كيف تتجنب لعنة التحسين المبكر

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

لما؟ أنا؟ فريقي ؟

هذا اتهام ضخم للغاية. دعني أوضح.

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

ما هو التحسين المبكر؟

يحاول التحسين السابق لأوانه تحسين الأداء:

1. عند ترميز الخوارزمية لأول مرة
2. قبل المعايير تؤكد أنك بحاجة إلى
3. قبل تحديد الملامح ، تحدد النقاط التي يكون من المنطقي فيها عناء التحسين
4. بمستوى أقل مما يمليه مشروعك حاليًا

الآن ، أنا متفائل يا أوبتيموس.

على الأقل ، سوف أتظاهر بأنني متفائل بينما أكتب هذا المقال. من ناحيتك ، يمكنك التظاهر بأن اسمك هو Optimus ، لذلك سيتحدث هذا معك بشكل مباشر أكثر.

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

أشعر بذلك. أحيانًا ما تكون قوة الكمالية قوية بداخلي أيضًا. تريد أن يقضي فريقك بعض الوقت الآن لتوفير الكثير من الوقت لاحقًا ، لأن الجميع مرهق بحصته في "Shitty Code كتب أشخاص آخرون (ما الذي كانوا يفكرون فيه بحق الجحيم؟). هذا هو SCOPWWHWTT باختصار ، لأنني أعرف أنك تحب الاختصارات التي لا يمكن نطقها.

أعلم أيضًا أنك لا تريد أن يكون رمز فريقك هو ذلك لأنفسهم أو لأي شخص آخر.

لذلك دعونا نرى ما يمكن فعله لتوجيه فريقك في الاتجاه الصحيح.

ما يجب تحسينه: مرحبًا بكم في هذا كونه فنًا

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

دعونا نجعلها أكثر غموضا! فقط في البداية.

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

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

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

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

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

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

1. أسهل شرح لموظفك الجديد
2. من المرجح أن يجتاز مراجعة التعليمات البرمجية من قبل مطور البرامج الأكثر خبرة لديك
3. الأكثر قابلية للصيانة
4. الأسرع في الكتابة
5. أسهل اختبار
6. الأكثر محمولة
7. إلخ.

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

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

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

ضع UX في الاعتبار

دعنا نستكشف كيف تتناسب تجربة المستخدم مع هذه الأولويات المحتملة. بعد كل شيء ، حتى الرغبة في أداء شيء ما بشكل جيد هي ، على مستوى ما ، حول تجربة المستخدم.

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

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

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

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

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

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

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

تجنب التحسين المبكر: متى وكيف يتم التحسين

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

إذن ، فيما يتعلق بالأداء ، ما هي طرق التحسين التي يجب اتباعها بالفعل؟ دعونا نحفر.

هذه ليست مبادرة شعبية ، إنها ثلاثية إيه

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

1. بنيان
2. الخوارزميات
3. المجسم

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

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

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

بنيان

في المشروع ، الهيكل هو أغلى جزء يمكن تغييره بعد وقوعه ، لذلك هذا هو المكان الذي يمكن أن يكون من المنطقي فيه تحسينه في البداية. إذا كان تطبيقك يقوم بتسليم البيانات عبر النعام ، على سبيل المثال ، فستحتاج إلى هيكلتها نحو حزم منخفضة التردد وذات حمولة عالية لتجنب تفاقم الاختناق السيئ. في هذه الحالة ، من الأفضل أن يكون لديك تطبيق كامل لـ Tetris للترفيه عن المستخدمين ، لأن أداة التحميل الدوارة لن تقطعها. (تمزح جانباً: منذ سنوات ، كنت أقوم بتثبيت أول توزيعة Linux ، Corel Linux 2.0 ، وسعدت لأن عملية التثبيت طويلة الأمد تضمنت ذلك فقط. بعد أن رأيت الشاشات الإعلانية لمثبت Windows 95 مرات عديدة لدرجة أنني حفظتها ، هذا كانت نسمة من الهواء النقي في ذلك الوقت.)

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

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

لن أسميها بهذا ، لكن الجميع يفعل ذلك

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

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

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

الخوارزميات والتجميع

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

ولكن بمجرد قيامك أنت وفريقك بتنفيذ شيء ما من حيث الأداء غير محسَّن ، هل تتركه حقًا عند عدم القيام بذلك ؟ أنت لم تتحسن أبدا؟

أنت على حق. القاعدة التالية هي ، للخبراء فقط ، لا تفعل ذلك بعد .

حان الوقت للمعيار!

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

لماذا ا؟ أليس من الواضح أن خوارزمية O (n³) الخاصة بي لا يمكن أن تكون أسوأ من أي شيء آخر؟ حسنًا ، لسببين:

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

لا تصدقني في هذه النقطة الثانية؟

كيفية الحصول على نتائج أفضل من الأجهزة التي تبلغ 1400 دولارًا أمريكيًا مقارنة بالأجهزة التي تبلغ 7000 دولار أمريكي

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

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

خاطئ - ظلم - يظلم!

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

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

حسنًا ، لقد قمت بقياس الأداء بالفعل. هل يمكنني فعلاً التحسين حتى الآن ؟؟

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

فكر قبل أن تعطل

"أنا لا أعرف عنكم أيها الناس ، لكن ..."

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

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

بالإضافة إلى ذلك ، إذا لم نفعل ذلك ، فسيقوم شخص آخر بذلك.

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

بوستسكريبت

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