آیا بررسی کد اشکالات را پیدا می کند؟

Summarize this content to 400 words in Persian Lang من اخیراً این را شنیدم: “بررسی کدها وقت تلف کردن است – آنها اشکالات را پیدا نمی کنند! ما باید به آزمایش های خود تکیه کنیم و از همه این بررسی کد mambo-jumbo بگذریم.”

و من موافقم – تست ها مهم هستند. اما آنها بسیاری از مشکلات را در بررسی کد شناسایی نمی کنند. در اینجا چند نمونه آورده شده است.

وابستگی های ناخواسته

توسعه دهندگان اغلب وابستگی هایی را اضافه می کنند که به راحتی می توانند بدون آن کار کنند. آوردن کتابخانه هایی با اندازه مگابایت فقط برای استفاده از یک تابع کوچک یا تکیه بر بسته هایی مانند true ممکن است ارزش هزینه را نداشته باشد. بررسی کدها فرصتی عالی برای شناسایی وابستگی های جدید و بحث در مورد ارزش آنهاست.

مشکلات عملکرد بالقوه

در تجربه من، اکثر تست های خودکار فقط از ورودی های تست اولیه استفاده می کنند. به عنوان مثال، آزمایش‌هایی برای کدهایی که روی آرایه‌ها کار می‌کنند، به ندرت از آرایه‌هایی با بیش از چند آیتم استفاده می‌کنند. این ورودی‌ها ممکن است برای آزمایش عملکرد اصلی کافی باشند، اما کد را تحت فشار قرار نمی‌دهند.

بررسی کدها امکان تشخیص الگوریتم‌های غیربهینه را می‌دهد که زمان اجرای آنها با اندازه ورودی یا سناریوهای مستعد انفجار ترکیبی به سرعت رشد می‌کند.

دومی چندی پیش تیم ما را گاز گرفت. هنگام بررسی تغییر کد، یکی از بازبینان به احتمال انفجار ترکیبی اشاره کرد. پس از گفتگو با نویسنده، آنها به این نتیجه رسیدند که هرگز چنین نخواهد شد. چند هفته به جلو حرکت کنید و سرویس ما گهگاه از 100% CPU استفاده می کند قبل از اینکه به دلیل تمام شدن حافظه از کار بیفتد. حدس بزنید چی؟ سناریوی فرضی اتفاق افتاد. اگر نگرانی ذکر شده در بررسی کد را به طور کامل تجزیه و تحلیل می کردیم، از مشکل به طور کامل جلوگیری می کردیم.

پیچیدگی و خوانایی کد

کامپیوترها همه کدها را با همان سهولت اجرا می کنند. برای آنها مهم نیست که چگونه به نظر می رسد. انسان ها متفاوت هستند. هرچه کد پیچیده تر باشد، درک و اصلاح صحیح آن دشوارتر است. بررسی کد بهترین زمان برای شناسایی کدهایی است که به دلیل پیچیدگی و خوانایی ضعیف به یک کابوس نگهداری تبدیل می شوند.

عدم پوشش آزمون

هدف از تست های خودکار، علامت گذاری باگ ها و رگرسیون ها است. اما چگونه از وجود این تست ها در وهله اول اطمینان حاصل کنیم؟ از طریق بررسی کد! اگر پوشش آزمایشی برای تغییر پیشنهادی کافی نیست، معمولاً کافی است در یک بررسی کد برای بهبود آن درخواست کنید.

اشکالات؟ بله، گاهی اوقات.

بررسی کد اشکالات را پیدا می کند. آنها همه آنها را پیدا نمی کنند، اما هر اشکالی که قبل از رسیدن به مخزن کشف شود یک برد است. بررسی کد یکی از اولین مراحل در فرآیند توسعه نرم افزار است که آنها را به اولین فرصت برای یافتن باگ تبدیل می کند. و هر چه زودتر یک باگ پیدا شود، رفع آن ارزان‌تر است.

نتیجه گیری

تست ها جایگزینی برای بررسی کد نیستند. با این حال، بررسی کد نیز جایگزینی برای تست ها نیست. این دو ابزار متفاوت هستند. حتی اگر ممکن است برخی از همپوشانی وجود داشته باشد، آنها اهداف متفاوتی دارند. داشتن هر دو به حفظ کد با کیفیت بالا کمک می کند.

زمان داستان

یکی از مسائل به یاد ماندنی که از طریق بررسی کد پیدا کردم، استفاده مشکوک از عبارات منظم بود. تجربه من به من آموخت که مراقب عبارات منظم باشم زیرا حتی آنهایی که ظاهری بی گناه دارند می توانند منجر به مشکلات جدی عملکرد شوند. اما وقتی تغییر پیشنهادی را دیدم، زبانم بند آمد: کد عبارات منظم در پرواز در یک حلقه تولید کرد و آنها را اجرا کرد.

در آن زمان، من نوزده سال از حرفه مهندسی نرم افزار خود (از جمله 11 سال در مایکروسافت) بودم و مشکلی ندیده بودم که حل آن مستلزم ایجاد عبارات منظم در پرواز باشد. من حتی به طور کامل متوجه نشدم که کد چه کاری انجام می دهد، اما متقاعد شدم که این کد هرگز نباید بررسی شود (با وجود گذراندن آزمایشات). پس از حفاری عمیق تر در مشکل، متوجه شدیم که یک تک for حلقه با دو شاخص می تواند آن را حل کند. اگر بررسی کد نبود، این تغییر به میلیون‌ها گوشی، از جمله، شاید حتی مال شما، وارد می‌شد، زیرا این برنامه بسیار محبوب است و صدها میلیون بار در iOS و اندروید دانلود شده است.

💙 اگر این مقاله را دوست داشتید…

من یک خبرنامه هفتگی برای مهندسین نرم افزار منتشر می کنم که می خواهند شغل خود را رشد دهند. من اشتباهاتی که مرتکب شده ام و درس هایی را که در 20 سال گذشته به عنوان یک مهندس نرم افزار آموخته ام به اشتراک می گذارم.

اینجا ثبت نام کنید تا مقالاتی مانند این را به صندوق ورودی خود تحویل بگیرید:
https://www.growingdev.net/

من اخیراً این را شنیدم: “بررسی کدها وقت تلف کردن است – آنها اشکالات را پیدا نمی کنند! ما باید به آزمایش های خود تکیه کنیم و از همه این بررسی کد mambo-jumbo بگذریم.”

و من موافقم – تست ها مهم هستند. اما آنها بسیاری از مشکلات را در بررسی کد شناسایی نمی کنند. در اینجا چند نمونه آورده شده است.

وابستگی های ناخواسته

توسعه دهندگان اغلب وابستگی هایی را اضافه می کنند که به راحتی می توانند بدون آن کار کنند. آوردن کتابخانه هایی با اندازه مگابایت فقط برای استفاده از یک تابع کوچک یا تکیه بر بسته هایی مانند true ممکن است ارزش هزینه را نداشته باشد. بررسی کدها فرصتی عالی برای شناسایی وابستگی های جدید و بحث در مورد ارزش آنهاست.

مشکلات عملکرد بالقوه

در تجربه من، اکثر تست های خودکار فقط از ورودی های تست اولیه استفاده می کنند. به عنوان مثال، آزمایش‌هایی برای کدهایی که روی آرایه‌ها کار می‌کنند، به ندرت از آرایه‌هایی با بیش از چند آیتم استفاده می‌کنند. این ورودی‌ها ممکن است برای آزمایش عملکرد اصلی کافی باشند، اما کد را تحت فشار قرار نمی‌دهند.

بررسی کدها امکان تشخیص الگوریتم‌های غیربهینه را می‌دهد که زمان اجرای آنها با اندازه ورودی یا سناریوهای مستعد انفجار ترکیبی به سرعت رشد می‌کند.

دومی چندی پیش تیم ما را گاز گرفت. هنگام بررسی تغییر کد، یکی از بازبینان به احتمال انفجار ترکیبی اشاره کرد. پس از گفتگو با نویسنده، آنها به این نتیجه رسیدند که هرگز چنین نخواهد شد. چند هفته به جلو حرکت کنید و سرویس ما گهگاه از 100% CPU استفاده می کند قبل از اینکه به دلیل تمام شدن حافظه از کار بیفتد. حدس بزنید چی؟ سناریوی فرضی اتفاق افتاد. اگر نگرانی ذکر شده در بررسی کد را به طور کامل تجزیه و تحلیل می کردیم، از مشکل به طور کامل جلوگیری می کردیم.

پیچیدگی و خوانایی کد

کامپیوترها همه کدها را با همان سهولت اجرا می کنند. برای آنها مهم نیست که چگونه به نظر می رسد. انسان ها متفاوت هستند. هرچه کد پیچیده تر باشد، درک و اصلاح صحیح آن دشوارتر است. بررسی کد بهترین زمان برای شناسایی کدهایی است که به دلیل پیچیدگی و خوانایی ضعیف به یک کابوس نگهداری تبدیل می شوند.

عدم پوشش آزمون

هدف از تست های خودکار، علامت گذاری باگ ها و رگرسیون ها است. اما چگونه از وجود این تست ها در وهله اول اطمینان حاصل کنیم؟ از طریق بررسی کد! اگر پوشش آزمایشی برای تغییر پیشنهادی کافی نیست، معمولاً کافی است در یک بررسی کد برای بهبود آن درخواست کنید.

اشکالات؟ بله، گاهی اوقات.

بررسی کد اشکالات را پیدا می کند. آنها همه آنها را پیدا نمی کنند، اما هر اشکالی که قبل از رسیدن به مخزن کشف شود یک برد است. بررسی کد یکی از اولین مراحل در فرآیند توسعه نرم افزار است که آنها را به اولین فرصت برای یافتن باگ تبدیل می کند. و هر چه زودتر یک باگ پیدا شود، رفع آن ارزان‌تر است.

نتیجه گیری

تست ها جایگزینی برای بررسی کد نیستند. با این حال، بررسی کد نیز جایگزینی برای تست ها نیست. این دو ابزار متفاوت هستند. حتی اگر ممکن است برخی از همپوشانی وجود داشته باشد، آنها اهداف متفاوتی دارند. داشتن هر دو به حفظ کد با کیفیت بالا کمک می کند.

زمان داستان

یکی از مسائل به یاد ماندنی که از طریق بررسی کد پیدا کردم، استفاده مشکوک از عبارات منظم بود. تجربه من به من آموخت که مراقب عبارات منظم باشم زیرا حتی آنهایی که ظاهری بی گناه دارند می توانند منجر به مشکلات جدی عملکرد شوند. اما وقتی تغییر پیشنهادی را دیدم، زبانم بند آمد: کد عبارات منظم در پرواز در یک حلقه تولید کرد و آنها را اجرا کرد.

در آن زمان، من نوزده سال از حرفه مهندسی نرم افزار خود (از جمله 11 سال در مایکروسافت) بودم و مشکلی ندیده بودم که حل آن مستلزم ایجاد عبارات منظم در پرواز باشد. من حتی به طور کامل متوجه نشدم که کد چه کاری انجام می دهد، اما متقاعد شدم که این کد هرگز نباید بررسی شود (با وجود گذراندن آزمایشات). پس از حفاری عمیق تر در مشکل، متوجه شدیم که یک تک for حلقه با دو شاخص می تواند آن را حل کند. اگر بررسی کد نبود، این تغییر به میلیون‌ها گوشی، از جمله، شاید حتی مال شما، وارد می‌شد، زیرا این برنامه بسیار محبوب است و صدها میلیون بار در iOS و اندروید دانلود شده است.

💙 اگر این مقاله را دوست داشتید…

من یک خبرنامه هفتگی برای مهندسین نرم افزار منتشر می کنم که می خواهند شغل خود را رشد دهند. من اشتباهاتی که مرتکب شده ام و درس هایی را که در 20 سال گذشته به عنوان یک مهندس نرم افزار آموخته ام به اشتراک می گذارم.

اینجا ثبت نام کنید تا مقالاتی مانند این را به صندوق ورودی خود تحویل بگیرید:
https://www.growingdev.net/