بهینهسازی زودهنگام، ریشه تمام مشکلات

یکی از سختترین بخشهای توسعه نرمافزار، این است که بدانیم در هر زمانی روی چه کاری باید وقت گذاشت. همه ما عاشق کد زدن و ساخت چیزهای جدید هستیم. اما با توجه به اینکه توسعهدهندهها اصولا گران و کمیاب هستند، استفاده درست از زمانشان، به یکی از بزرگترین چالشهای این کار تبدیل میشود.
قطعا آخرین چیزی که میخواهیم این است که کدی را به مشتری تحویل دهیم که دوست نداشته باشد و یا کار نکند. اینکه در حین ساخت نرمافزار چقدر از زمان خود را باید به بهینهسازی و تنظیم عملکرد نرمافزار اختصاص دهیم، همیشه به عنوان یک مصالحه و بدهبستون مهم مطرح می شود. اگر هیچ بهینهسازیای انجام ندهیم، انتشار محصول جدیدمان میتواند یک فاجعه کامل باشد. مثلا راهاندازی وبسایت healthcare.gov یکی از معروفترین شکستهای اخیر در این زمینه است. همچنین قطعا دوست نداریم زمان بسیار زیادی را برای بهینهسازی چیزهای کماهمیت تلف کنیم. بسیاری از تیمهای توسعه خیلی زود درگیر کارهای بهینهسازی و مقیاسپذیری پروژه میشوند در حالی که هنوز از عملکرد مناسب و صحیح محصول جدیدشان مطمئن نیستند.
بهینهسازی زودهنگام چیست؟
بهینهسازی زودهنگام (Premature optimization)، به معنای صرف وقت بیش از حد روی چیزیست که ممکن است اصلا نیاز نشود. شاید جمله معروف «بهینهسازی زودهنگام ریشه تمام مشکلات است» را شنیده باشید. این جمله از دانشمند بزرگ رایانه، دانلد کنوث است. وی در کتاب معروفش «هنر برنامهنویسی رایانه» مینویسد:
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”
نقل قول اصلی مربوط به کتابی است که درباره همین موضوع در دهه ۶۰ میلادی منتشر شده است. بیشک دنیای کامپیوتر و فرایند توسعه نرمافزار از آن زمان تا کنون دستخوش تغییرات عظیمی شده است اما این عبارت در دنیای امروز هم همچنان معنادار و پراستفاده است. در بخشهای بعدی، به بررسی همین موضوع میپردازیم.
بهینهسازی زودهنگام در دنیای امروز به چه معناست؟
بسیاری از تیمهای توسعه، امروزه به صورت پیوسته (و با دوره تناوب کم) در حال تحویل کد هستند. اکثرا این تیمها هم از متدولوژیهای چابک (agile) برای توسعه نرمافزار استفاده میکنند و میدانند که اگر یک باگ در نرمافزار پیدا شود، میتوانند به سرعت و سهولت خطا را برطرف کرده و کد جدید را بر روی وبسرور مستقر کنند.
با تغییرات صورتگرفته در صنعت توسعه نرمافزار، همچنان تمایل به بهینهسازی زودهنگام وجود دارد، به همین خاطر همچنان باید برنامهنویسان را نسبت به آن هشدار داد. بهینهسازی زودهنگام چیزیست که توسعهدهندگان باید همیشه آن را گوشه ذهن داشته باشند و چیزیست که باید همیشه در کارهای روزانهشان از آن دوری کنند. چرا که این مساله امروز هم به اندازه روزهای مینفریم و کارتهای پانچ خطرناک است.
مثال بارز این موضوع، استارتآپهایی هستند که زمان زیادی را صرف مقیاسپذیر کردن نرمافزار خود برای پاسخگویی به درخواستهای میلیونها کاربر میکنند. قطعا خوب است که به این مساله فکر شود اما لازم نیست در همان ابتدا حتما کاری انجام داد. پیش از اینکه لازم باشد درباره سرویسدهی به تعداد زیاد کاربران فکر کنید، باید مطمئن شوید اصلا ۱۰۰ کاربر پیدا میشوند که محصول شما را دوست داشته باشند و از آن استفاده کنند یا نه؟ پس ابتدا باید به بازخورد کاربران توجه کرد تا مقیاسکردن محصول برای کاربرانی که وجود ندارند.
چرا باید بازخورد کاربران را در اولویت قرار دهید؟
بهترین روش برای توضیح این موضوع، میتواند یک داستان ساده باشد. من هماکنون در حال کار بر روی یک پروژه جانبی هستم که مربوط به بازاریابی محتوا و اندازهگیری عملکرد آن است. برای این پروژه نیاز است از گوگل آنالیتیکس اطلاعات جمعآوری شود و یکسری اطلاعات از صفحات یک وبسایت استخراج (crawl) شود و در نهایت در قالب یک داشبورد به کاربر نمایش داده شود.
احتمالا نیاز است که حجم زیادی اطلاعات جمعآوری شود، فرایند جمعآوری اطلاعات هم خودش فرایند زمانبری است. اگر من بخواهم این محصول را به تعداد زیادی کاربر بفروشم احتمالا بابت هر دو مورد، مشکل مقیاسکردن خواهم داشت.
اما با این وجود، تمرکز من نه روی عملکرد و مقیاسکردن، بلکه روی تست کردن و ساخت نمونههای آزمایشی از قابلیتهای مختلف است. در واقع بیشترین توجه من روی گرفتن بازخورد از کاربران و بهتر کردن قابلیتها و امکانات محصول نهایی است. من تلاش میکنم که زمانم را روی چیزهایی که ممکن است هیچگاه نیاز نشوند نگذارم.
چیزهایی که ممکن بود زمانم را روی آنها هدر دهم
به جای اینکه من زمان بگذارم تا خود محصول را بهتر کنم، ممکن بود روی یکی از موارد زیر زمان بگذارم:
- ارزیابی چندین گزینه مختلف ذخیرهسازی داده برای ذخیرهسازی و انجام جستوجو (query) بر روی همه دادههای موجود بر روی گوگل آنالیتیکس که میتواند در حد «big data» شود!
- چگونگی زمانبندی کردن عملیات خزش به شکل هفتگی و پخش کار بر روی تعداد زیادی worker.
- بررسی اینکه آیا برای داشتن دسترسپذیری بالا، لازم است کد خود را روی چندین سرویس ابری مستقر (deploy) کنم یا نه.
- فهمیدن چگونگی طراحی معماری محصول به منظور میزبانی در چندین مرکز داده بینالمللی برای زمانی که قرار است محصولم در سراسر جهان سرویس بدهد.
- اطمینان حاصل کردن از اینکه که در سراسر کدم پوشش تست ۱۰۰ درصد وجود دارد.
- نوشتن انواع تستهای خودکار
فعلا، هیچ کدام از این چیزها اهمیت ندارد
اگر کاربری نباشد که به او خدمات دهم، استفاده صحیح از داکر یا کوبرنتیز، تستهای خودکار یا استقرار پیوسته قطعا هدردادن انرژی هستند! اما میدانید چه چیزی اهمیت دارد؟
فهمیدن اینکه آیا کاربران قابلیتها یا خود محصول را دوست دارند یا نه؟
من میتوانم در آینده به مواردی که در بالا لیست کردهام بپردازم، اما الان زمانش نیست و از بهینهسازی زودهنگام پرهیز میکنم.
چرا بازخورد محصول اولویت اول است؟
کار کردن بر روی مجموعه امکانات محصول و بازخورد گرفتن از کاربر، مهمتر (و حتی سختتر) از کار کردن بر روی بهینهسازی عملکرد یا رفع مشکلات مقیاسپذیریست. همچنین شناسایی مجموعه ویژگیها و نیازمندیها، میتواند تصمیمات بهینهسازی را دستخوش تغییر کند.
در پروژه جانبی خودم که بالاتر از آن یاد کردم، اگر تصمیم بگیرم که مشتریام، استارتآپها خواهند بود یا برندهای بزرگ، میزان دیتایی که لازم است جمعآوری شود و مجموعه امکانات مورد نیاز، به شکل باورنکردنیای تغییر خواهد کرد. پس حرفم این است که مفهوم بهینهسازی زودهنگام به موارد دیگری علاوه بر «بهینهسازیهای صرفا عملکردی» هم مرتبط است. به مواردی همچون جایی که زمان و انرژیمان را متمرکز میکنیم.
همیشه باید همه تلاشمان را معطوف به مساله درستی بکنیم و برای حل همان تلاش کنیم. مثلا نباید برای ساختن چیزهایی زمان بگذاریم که هرگز قرار نیست استفاده شوند. ابتدا روی نوشتن کدی کار کنید که میدانید مردم قرار است از آن استفاده کنند. همیشه برای بهتر کردن آن زمان خواهید داشت.
جمعبندی
اگر اطمینان داشته باشیم که مشغول ساختن چیز صحیحی هستیم، باید زمان بیشتری صرف معماری مناسب، عملکرد خوب، مقیاسپذیری بالا و … بگذاریم. پیدا کردن این تعادل همواره چالشبرانگیز است. مثل بسیاری از چیزها در زندگی، جواب این سوال هم همیشه «بستگی دارد» است.
البته که کارایی و مقیاسپذیری نرمافزار شما مهم هستند. فقط لازم است مطمئن شوید که در حال پیادهسازی مجموعه درستی از قابلیتها هستید. به کمک بازخورد گرفتن سریع و گاهبهگاه از کاربر، از بهینهسازی زودهنگام جلوگیری کنید.
منبع: وبسایت stackify
.
.
.
.
با ما همراه باشید
آدرس کانال تلگرام: JavaCupIR@
آدرس اکانت توییتر: JavaCupIR@
آدرس صفحه اینستاگرام: javacup.ir
صفحه ویرگول: javcup
آدرس گروه لینکدین: Iranian Java Developers
سلام
وقت بخیر
اسم این دانشمند بزرگ آقای Donald Knuth – به فارسی : ” دانلد نوث هست” نه دونالد کنوت.
وقتی مطلبی به این مهمی و سنگینی را متوجه نشدید نباید ترجمه کنید و نشر دهید، بسیار بحث بزرگی را باز کردید که متاسفانه حیف شد و مطلب کاملا از بین رفت —- وبسایت استکیفای وحی منزل نیست.
ضمنا زمانی میتوانید از این داشنمند بزرگ مطلبی بنویسید که حداقل یک بار کتاب ایشون را خوانده باشید.
پایدار باشید
سلام
وقت شما هم بخیر
خیلی ممنون که وقت گذاشتید و نظر دادید.
در مورد تلفظ صحیح اسم آقای Donald Knuth حق با شماست که اشتباه شده بود و اصلاحش کردیم. تلفظ صحیح اسم ایشون طبق گفته خودشون «دانلد کنوث» است و در واقع حرف K تلفظ میشه. . اینجا و اینجا رو ببینید.
در مورد ترجمه صحیح مطلب هم دغدغه شما رو درک میکنیم. ما لپ مطلب رو فهمیدیم و ترجمه اولیه هم کاملا مفهوم رو رسونده بود. با این حال یک دور دیگه سعی کردیم مرور و بهترش کنیم و امیدواریم از نظر شما هم قابل قبول شده باشه.
در مورد بخش آخر نظرتون هم راستش باهاتون موافق نیستیم و به نظرمون برای بحث و گفتوگو در مورد یک مبحث، نیازی نیست که حتما یک کتاب کامل از شخصی که اولین بار آن موضوع رو مطرح کرده خوانده باشیم. جستوجوی عمیقتر و شنیدن نظرات افراد مختلف، برای درک کامل یک مبحث خاص، گاهی مفیدتره.
امیدواریم شما هم نظرتون رو در مورد بهینهسازی زودهنگام با ما به اشتراک بگذارید.
خیلی ممنون که به فکر بهبود جاواکاپ هستین و ما خوشحالیم که مطالب ما رو میخونین و اگر اشکالی ببینید بهمون گوشزد میکنید.
با تشکر