ایجاد یک فرآیند بهتر برای بررسی و تحلیل کد

در چند سال گذشته، هزاران بررسی کد را برای صدها توسعه‌دهنده، در پروژه‌های تجاری، پروژه‌های منبع باز، و در کلاس‌های درس انجام داده‌ایم. اگرچه استثنائاتی وجود دارد، اکثریت برنامه‌نویسانی که با آن‌ها کار کرده‌ایم تصور می‌کنند که تمرکز اصلی بر روی بالا بردن کیفیت کد است.

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

با تست محصول شروع کنید

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

بیشتر بخوانید:برنامه نویسان ایرانی کدام زبان های برنامه نویسی را دوست دارند؟ 

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

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

اما در موارد دیگر، فقدان نمونه‌های واقع‌بینانه از یک نیاز مشخص شده می‌آید. مثلا بخشی از متن “لورم‌اپسیوم” برای یک فیلد یادداشت از دستورالعمل آشپزی فقط برای mockup خوب هستند، اما بدون دانستن نوع یادداشتی که انتظار دارید تا به این دستورالعمل‌ها ضمیمه شود، غیرممکن است که بتوانید ارزیابی کنید که چگونه آن را بهتر می‌توانید پیاده‌سازی کنید یا اصلا باید پیاده‌سازی شود یا نه.

از دید مشتری نگاه کنید

ما کدهای در حال اجرا را در محیطی مثل محیط تولید، با داده‌هایی مثل داده‌های محصول (احتمالا فرضی اما واقع‌‌بینانه) بررسی می‌کنیم. ما نباید به هیچ وجه نگران تغییرات کد در حین بررسی آن باشیم، بلکه در بیشتر موارد بررسی کد به ما کمک کرده است که باگ‌ها، تصورات غلط، یا حفره‌هایی که در دانش‌مان وجود دارد را پیدا کنیم.

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

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

ریسک تغییراتی که در حال گسترش آن هستید را دریابید

فرض می‌کنیم که این فرآیند مسائل عمده‌ای را نشان نمی‌دهد که مانع ادامه بررسی ما می‌شود، ابتدا کد را نگاه می‌کنیم. آنچه در اولین مرحله دنبال می‌کنیم خطوط قرمزی است که نشان داده می‌شود، که باید برخی کدها را تغییر داد یا آن‌ها را حذف کرد.

بررسی سریع دوم که به ما کمک می‌کند این است که ببینیم آیا کد جدیدی که اضافه کرده‌ایم ممکن است روی سایر بخش‌های سیستم تاثیر بگذارد؛ مواردی مثل آپدیت فایل‌های پیکربندی، اصلاحات مربوط به آبجکت‌های سراسری، تغییراتی که ممکن است باعث ایجاد خطاهای جدید شود و غیره.

مقاله مرتبط :شغل هایی که با داشتن مهارت‌های کدینگ پیدا خواهید کرد

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

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

اگر تغییر جامع و مستقل باشد، کمی راحت‌تر هستیم، اما هنوز احساس نیاز به مرور عوامل خطر بالقوه وجود دارد. در عمل، این به معنی نگاه به هر نقطه ورود و خروج سیستم برای خطر بالقوه است (مثلا ورودی کاربر، سیستم I/O، هشدارهای ایمیل، تماس‌های وب‌سرویس و غیره) و یک معیار کلی از ضوابط وجود دارد که واقعا باید به یک چک‌لیست برای برخی روزها تبدیل شود.

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

در بررسی ما، تغییرات واقعا ایمن ممکن است بررسی روشنی از پیشنهادات تجدیدنظرشده همراه با تعدادی از سوالات واضح را دریافت کنند. تغییرات خطرناک‌تر به بررسی دقیق‌تری نیاز دارند، و سوال مهمی که قبل از انجام این کار باید از خود بپرسید این است که “آیا راهی امن‌تر برای انجام این کار وجود دارد؟”

روی محصول تمرکز کنید، حتی وقتی کد را بررسی می‌کنید

ما سوالات ضروریی را یافتیم که لازم است قبل از اینکه شما حتی در مورد مسائلی مثل کیفیت کد فکر کنید، پرسیده شود:

آیا این تغییر یک مشکل واقعی برای مشتری را حل می‌کند؟

آیا این راه‌حل، راه‌حلی قدرتمند و مناسب است؟

چگونه می‌توانیم متوجه شویم که این تغییر یک سرما‌یه‌گذاری خوب، نسبت به سایر کارهایی است که می‌توانیم انجام دهیم؟

با اعمال این تغییر چه مشکلات جدیدی ممکن است ایجاد شود و چگونه می‌توانیم آن‌ها را کاهش دهیم؟

آیا می‌توان تغییر را به راحتی برگرداند یا اگر اشتباهی رخ دهد ممکن است همه چیز به هم بریزد؟

آیا هزینه‌های اصلاح در رابطه با این تغییر وجود دارد؟ آن‌ها چه هستند؟

به سادگی با پرسیدن این سوالات می‌توانید قبل از اینکه انرژی سرمایه‌گذاری را در مواردی مانند سبک کدنویسی، الگوهای طراحی، انجام ریفکتورینگ، یا استراتژی‌هایی برای تست خودکار صرف کنید، از همان ابتدا مسائل را در روند بررسی قرار دهید. همچنین یک تمرکز بیرونی قدرتمندی را به وجود آورید که بسیار به سود افرادی است که در نهایت می‌خواهند با این نرم‌افزار کار کنند.

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

پس وقتی می‌خواهید تغییرات جدیدی را به یک سیستم نرم‌افزاری اضافه کنید، ابتدا به چه چیزی نگاه کرده و آن را بررسی می‌کنید؟ جواب این سوال آسان است: شما باید با نیاز مشتری شروع کنید، اقدام به انجام کارهایی کنید که باعث رضایتمندی مشتری می‌شود و پس از آن شیوه خود را برای اجرای کد پیاده ‌کنید.

منبع : تاپ لرن

عالی بود(1)جالب نیست!(0)