eshpilen
جمعه 18 آذر 1390, 13:59 عصر
فکر کردم این میتونه موضوع مفیدی باشه.
نظر به اینکه بنظر میرسه عدهء زیادی از افراد وسواس زیادی روی بهینه سازیهای جزیی دارن و گذشته از اتلاف وقت و انرژی خودشون، مخدوش شدن پارامترهای دیگر رو دست کم میگیرن، در اینجا نمونه هایی از بهینه سازیهایی رو که ممکن هستن اما نباید انجام بشن مطرح میکنم.
البته هرکس آزاده نظر خودش رو بیان و مخالفت کنه.
خب اولین مورد مثلا یه چیز ساده ای مثل اینه:
$lockdown_period=12*60*60; //in seconds
اینجا ما یک تنظیم در فایل پیکربندی برنامه داریم.
خب ما مقدارش رو میخواستیم 12 ساعت باشه و چون برحسب ثانیه بوده نوشتیم 12*60*60.
ما میتونیم اینجا یه بهینه سازی انجام بدیم و بجای 12*60*60 بنویسیم 43200.
این باعث میشه تا در هر بار اجرا PHP مجبور به انجام چند محاسبهء ضرب و مخلفاتش نباشه.
اما من فکر میکنم این پردازش و زمان اضافه اونقدر ناچیزه و از طرف دیگه نوشتن اعداد به اون صورت خوانایی بیشتری به کد میده که نباید این کار رو بکنیم.
نوشتن بصورت خوانا هم برای برنامه نویس موقع توسعه و تست و باگیابی کمک میکنه و هم بعدها برای کاربر برنامه از بروز یکسری اشتباهات جلوگیری میکنه.
یه مورد دیگه:
some_page.php:
include 'some_operation.php';
...
some_operation.php:
include 'some_operation_configs.php';
if(!some_config_var) return;
...
در این نمونهء فرضی که البته نمونهء واقعیش در پروژهء خودم هست، ما در یک صفحه یک صفحه/کد دیگری رو اینکلود کردیم و اون کد خودش یک فایل دیگر که حاوی تنظیمات برای عملیاتی که میخواد انجام بده هست رو اینکلود میکنه و اگر مقدار یکی از تنظیمات false بود، اجرا ادامه پیدا نمیکنه و اجرای برنامه بدون هیچ نتیجه ای از کد اینکلود شده به صفحهء اولیه باز میگردد.
در این روش درکل ما دو عملیات اینکلود داشتیم. چه کد مورد نظر اجرا بشه و چه عملیاتی اجرا نشه.
خب حالا ما میتونستیم کد رو اینطور بنویسیم:
some_page.php:
include 'some_operation_configs.php';
if(some_config_var) include 'some_operation.php';
...
some_operation.php:
...
یعنی تنظیمات رو در فایل اصلی اینکلود کنیم و بر اساس متغییر مربوطه تشخیص بدیم آیا عملیات باید اجرا بشه یا نه و اگر جواب مثبت بود فایل کد مربوط به عملیات رو اینکلود کنیم.
در این حالت اگر تنظیمات بگن که عملیات میتونه انجام بشه ما در کل دو عملیات اینکلود خواهیم داشت؛ یکی برای اینکلود کردن تنظیمات و دیگری برای اینکلود کردن کد عملیات مورد نظر. مثل مورد قبل.
اما اگر تنظیمات بگن که عملیات نباید انجام بشه، ما دیگه فایل محتوی کد عملیات رو اینکلود نمیکنیم و بنابراین تعداد اینکلودهای ما در این حالت یکی کمتر از روش قبلی خواهد بود.
خب ما میتونیم فرض کنیم که روش دوم بهینه تره. ولی آیا این کار تاثیر عملی مشهودی در اجرای برنامه خواهد داشت و آیا عوارضی نداره؟
کدام خواناتر هست؟
کدام از نظر توسعه و نگهداری برنامه بهتره؟
بنظرم اینکه موارد مربوط به یک عملیات همه درداخل یک فایل مجتمع شده باشن بهتره.
فرضا اگر نظیر این روش در 10 فایل وجود داشته باشه، وقتی تغییری در ساختار فایل تنظیمات بوجود میاد، مجبوریم تک تک اون 10 فایل رو پیدا کرده و اونها رو با تغییرات و ساختار جدید فایل تنظیمات تطبیق بدیم، اما وقتی دسترسی به تنظیمات فقط در فایل مربوط به فایل کد اون عملیات خاص وجود داشته باشه، اون فایل رو میشه براحتی پیدا و خیلی سریعتر و راحتتر و با احتمال خیلی کمتری برای خطاهای انسانی اصلاح کرد.
بازهم میشه مثالهای بیشتری آورد. و شما هم اگر موردی داشتید در تاپیک درج کنید.
منظورم از این بحث این بود که بهینه سازی هزاران نوع دارد، ولی بسیاری از بهینه سازیها درواقعیت به هیچ وجه تاثیر مشهود یا قابل توجهی نخواهند داشت یا پارامترهای دیگری رو مخدوش خواهند کرد که ارزش اون افزایش پرفورمنس رو نداره.
اینکه خیلی ها به بهینه سازی به شکل وسواسی توجه دارن و هرچقدر هم در اون مهارت داشته باشن، یک نقطهء قوت نیست. این نشان دهندهء یک دیده محدود و عدم تفکر منطقی واقعگرایانه و عدم توانایی در برقراری تعادل میان تمام پارامترهای مختلف برنامه و نیازها و شرایط واقعی هست.
قبلا هم گفتم این بیشتر شبیه یک بیماری هست.
واقعا بهینه سازی در این حد وسواسی و در خیلی موارد قبل از اینکه نیاز عملی بهش دیده بشه، هیچ ارزشی نداره.
اینهمه مبحث و اینهمه نقص و موارد بهبود ممکن برای برنامه هست ولی یک عده همش چسبیدن به بهینه سازی. چرا؟
اصلا بهینه سازی چیزی نیست که اینقدر بحث و ارزش داشته باشه. خصوصا امروزه که قدرت و منابع رایانه ها خیلی خیلی بیشتر از قدیم هست و زبانها و امکانات سطح بالای زیادی بوجود آمدن برای همین که سطح برنامه نویسی رو بالا ببرن و برنامه نویس بیشتر روی منطق و الگوریتم و امنیت برنامه تمرکز بکنه.
وقتی یک نفر برنامه و کدی نوشته باید اول به منطق و خوانایی و امنیت اون نگاه کنیم و اگر درسته تاییدش کنیم. و اگر فردا آمد گفت با پرفورمنس مشکل دارم اونوقت باید بهینه سازیهایی رو بهش پیشنهاد کرد. یا اگر خودمون در اون مورد تجربهء عملی داریم که با شرایط طرف هم احتمالا چنان تجربه ای باارتباط خواهد بود. یا درمورد بهینه سازیهایی که میتونن واقعا بزرگ باشن.
اما الان قضیه خیلی وسواسی و حتی معکوس هست.
تا یه نفر برنامه ای مینویسه و کدی میذاره همه میان از جزء به جزء سینتاکسش ایراد میگیرن و کلی بهینه سازی در حد میکروثانیه ارائه میکنن که به احتمال 99% در عمل هیچوقت هیچکس متوجه تاثیر اونا نخواهد شد، اما خوانایی و دقت و کمال الگوریتم و استحکام امنیت برنامه فدا میشه یا اینطور بگیم که اصلا کمتر کسی دانش و مهارتی به همون نسبت در این حیطه داره و متوجه خیلی از مسائل در این زمینه نمیشن.
اینکه ما از بهینه نبودن سینتاکس ایراد بگیریم واقعا کار سختی نیست و هنری هم محسوب نمیشه. میبینید که این کار رو بیشتر افراد بعد از کمی مطالعه و تجربه میتونن انجام بدن. درمورد بهینه سازی اگر به واقعیت و تاثیر و ارزش عملی اونها توجهی نداشته باشیم و به هزینهء اونها بر پارامترهای دیگر توجهی نکنیم، میشه کلی نوشت و صدها مورد رو مطرح کرد، میشه از میان چند روش و چند تابع قابل استفاده برای یک عملیات همه رو آنالیز و تست کرد و سر میکروثانیه ها و میلی ثانیه ها چک و چونه زد، ولی واقعا در این کار چه توجیه و هنری هست؟ اینقدر مباحث اساسی و مهمتر و موثرتر در زمینه های مختلف هست و اینقدر چیزهای جالب که صرف وقت و انرژی روی چنین کارهایی جز یک بازی کودکانه چیز دیگری بنظر نمیرسه.
و آدم اگر یک روزی به مشکل پرفورمنسی برخورد بکنه که واقعا با چنین مواردی در ارتباط باشه و بشه با چنین تغییرات جزیی حلش کرد، فکر نمیکنم کشف و حل اون چندان دشوار باشه و نیاز به سواد زیاد و آگاهی قبلی در این مورد داشته باشه. هر برنامه نویس حرفه ای میتونه جای مشکل پرفورمنس رو پیدا بکنه، و معمولا bottleneck های متعدد بسیار بزرگتری در جاهای دیگری وجود دارن که مشکل از اونها ناشی و با حل اونها برطرف میشه.
نظر به اینکه بنظر میرسه عدهء زیادی از افراد وسواس زیادی روی بهینه سازیهای جزیی دارن و گذشته از اتلاف وقت و انرژی خودشون، مخدوش شدن پارامترهای دیگر رو دست کم میگیرن، در اینجا نمونه هایی از بهینه سازیهایی رو که ممکن هستن اما نباید انجام بشن مطرح میکنم.
البته هرکس آزاده نظر خودش رو بیان و مخالفت کنه.
خب اولین مورد مثلا یه چیز ساده ای مثل اینه:
$lockdown_period=12*60*60; //in seconds
اینجا ما یک تنظیم در فایل پیکربندی برنامه داریم.
خب ما مقدارش رو میخواستیم 12 ساعت باشه و چون برحسب ثانیه بوده نوشتیم 12*60*60.
ما میتونیم اینجا یه بهینه سازی انجام بدیم و بجای 12*60*60 بنویسیم 43200.
این باعث میشه تا در هر بار اجرا PHP مجبور به انجام چند محاسبهء ضرب و مخلفاتش نباشه.
اما من فکر میکنم این پردازش و زمان اضافه اونقدر ناچیزه و از طرف دیگه نوشتن اعداد به اون صورت خوانایی بیشتری به کد میده که نباید این کار رو بکنیم.
نوشتن بصورت خوانا هم برای برنامه نویس موقع توسعه و تست و باگیابی کمک میکنه و هم بعدها برای کاربر برنامه از بروز یکسری اشتباهات جلوگیری میکنه.
یه مورد دیگه:
some_page.php:
include 'some_operation.php';
...
some_operation.php:
include 'some_operation_configs.php';
if(!some_config_var) return;
...
در این نمونهء فرضی که البته نمونهء واقعیش در پروژهء خودم هست، ما در یک صفحه یک صفحه/کد دیگری رو اینکلود کردیم و اون کد خودش یک فایل دیگر که حاوی تنظیمات برای عملیاتی که میخواد انجام بده هست رو اینکلود میکنه و اگر مقدار یکی از تنظیمات false بود، اجرا ادامه پیدا نمیکنه و اجرای برنامه بدون هیچ نتیجه ای از کد اینکلود شده به صفحهء اولیه باز میگردد.
در این روش درکل ما دو عملیات اینکلود داشتیم. چه کد مورد نظر اجرا بشه و چه عملیاتی اجرا نشه.
خب حالا ما میتونستیم کد رو اینطور بنویسیم:
some_page.php:
include 'some_operation_configs.php';
if(some_config_var) include 'some_operation.php';
...
some_operation.php:
...
یعنی تنظیمات رو در فایل اصلی اینکلود کنیم و بر اساس متغییر مربوطه تشخیص بدیم آیا عملیات باید اجرا بشه یا نه و اگر جواب مثبت بود فایل کد مربوط به عملیات رو اینکلود کنیم.
در این حالت اگر تنظیمات بگن که عملیات میتونه انجام بشه ما در کل دو عملیات اینکلود خواهیم داشت؛ یکی برای اینکلود کردن تنظیمات و دیگری برای اینکلود کردن کد عملیات مورد نظر. مثل مورد قبل.
اما اگر تنظیمات بگن که عملیات نباید انجام بشه، ما دیگه فایل محتوی کد عملیات رو اینکلود نمیکنیم و بنابراین تعداد اینکلودهای ما در این حالت یکی کمتر از روش قبلی خواهد بود.
خب ما میتونیم فرض کنیم که روش دوم بهینه تره. ولی آیا این کار تاثیر عملی مشهودی در اجرای برنامه خواهد داشت و آیا عوارضی نداره؟
کدام خواناتر هست؟
کدام از نظر توسعه و نگهداری برنامه بهتره؟
بنظرم اینکه موارد مربوط به یک عملیات همه درداخل یک فایل مجتمع شده باشن بهتره.
فرضا اگر نظیر این روش در 10 فایل وجود داشته باشه، وقتی تغییری در ساختار فایل تنظیمات بوجود میاد، مجبوریم تک تک اون 10 فایل رو پیدا کرده و اونها رو با تغییرات و ساختار جدید فایل تنظیمات تطبیق بدیم، اما وقتی دسترسی به تنظیمات فقط در فایل مربوط به فایل کد اون عملیات خاص وجود داشته باشه، اون فایل رو میشه براحتی پیدا و خیلی سریعتر و راحتتر و با احتمال خیلی کمتری برای خطاهای انسانی اصلاح کرد.
بازهم میشه مثالهای بیشتری آورد. و شما هم اگر موردی داشتید در تاپیک درج کنید.
منظورم از این بحث این بود که بهینه سازی هزاران نوع دارد، ولی بسیاری از بهینه سازیها درواقعیت به هیچ وجه تاثیر مشهود یا قابل توجهی نخواهند داشت یا پارامترهای دیگری رو مخدوش خواهند کرد که ارزش اون افزایش پرفورمنس رو نداره.
اینکه خیلی ها به بهینه سازی به شکل وسواسی توجه دارن و هرچقدر هم در اون مهارت داشته باشن، یک نقطهء قوت نیست. این نشان دهندهء یک دیده محدود و عدم تفکر منطقی واقعگرایانه و عدم توانایی در برقراری تعادل میان تمام پارامترهای مختلف برنامه و نیازها و شرایط واقعی هست.
قبلا هم گفتم این بیشتر شبیه یک بیماری هست.
واقعا بهینه سازی در این حد وسواسی و در خیلی موارد قبل از اینکه نیاز عملی بهش دیده بشه، هیچ ارزشی نداره.
اینهمه مبحث و اینهمه نقص و موارد بهبود ممکن برای برنامه هست ولی یک عده همش چسبیدن به بهینه سازی. چرا؟
اصلا بهینه سازی چیزی نیست که اینقدر بحث و ارزش داشته باشه. خصوصا امروزه که قدرت و منابع رایانه ها خیلی خیلی بیشتر از قدیم هست و زبانها و امکانات سطح بالای زیادی بوجود آمدن برای همین که سطح برنامه نویسی رو بالا ببرن و برنامه نویس بیشتر روی منطق و الگوریتم و امنیت برنامه تمرکز بکنه.
وقتی یک نفر برنامه و کدی نوشته باید اول به منطق و خوانایی و امنیت اون نگاه کنیم و اگر درسته تاییدش کنیم. و اگر فردا آمد گفت با پرفورمنس مشکل دارم اونوقت باید بهینه سازیهایی رو بهش پیشنهاد کرد. یا اگر خودمون در اون مورد تجربهء عملی داریم که با شرایط طرف هم احتمالا چنان تجربه ای باارتباط خواهد بود. یا درمورد بهینه سازیهایی که میتونن واقعا بزرگ باشن.
اما الان قضیه خیلی وسواسی و حتی معکوس هست.
تا یه نفر برنامه ای مینویسه و کدی میذاره همه میان از جزء به جزء سینتاکسش ایراد میگیرن و کلی بهینه سازی در حد میکروثانیه ارائه میکنن که به احتمال 99% در عمل هیچوقت هیچکس متوجه تاثیر اونا نخواهد شد، اما خوانایی و دقت و کمال الگوریتم و استحکام امنیت برنامه فدا میشه یا اینطور بگیم که اصلا کمتر کسی دانش و مهارتی به همون نسبت در این حیطه داره و متوجه خیلی از مسائل در این زمینه نمیشن.
اینکه ما از بهینه نبودن سینتاکس ایراد بگیریم واقعا کار سختی نیست و هنری هم محسوب نمیشه. میبینید که این کار رو بیشتر افراد بعد از کمی مطالعه و تجربه میتونن انجام بدن. درمورد بهینه سازی اگر به واقعیت و تاثیر و ارزش عملی اونها توجهی نداشته باشیم و به هزینهء اونها بر پارامترهای دیگر توجهی نکنیم، میشه کلی نوشت و صدها مورد رو مطرح کرد، میشه از میان چند روش و چند تابع قابل استفاده برای یک عملیات همه رو آنالیز و تست کرد و سر میکروثانیه ها و میلی ثانیه ها چک و چونه زد، ولی واقعا در این کار چه توجیه و هنری هست؟ اینقدر مباحث اساسی و مهمتر و موثرتر در زمینه های مختلف هست و اینقدر چیزهای جالب که صرف وقت و انرژی روی چنین کارهایی جز یک بازی کودکانه چیز دیگری بنظر نمیرسه.
و آدم اگر یک روزی به مشکل پرفورمنسی برخورد بکنه که واقعا با چنین مواردی در ارتباط باشه و بشه با چنین تغییرات جزیی حلش کرد، فکر نمیکنم کشف و حل اون چندان دشوار باشه و نیاز به سواد زیاد و آگاهی قبلی در این مورد داشته باشه. هر برنامه نویس حرفه ای میتونه جای مشکل پرفورمنس رو پیدا بکنه، و معمولا bottleneck های متعدد بسیار بزرگتری در جاهای دیگری وجود دارن که مشکل از اونها ناشی و با حل اونها برطرف میشه.