درآمدی بر راه‌کارهای اصولی اِعمال تغییرات در سورس‌کد

اغلب فکر می‌کنیم بعد از به پایان رساندن فرایند توسعهٔ نرم‌افزار، برای بررسی کدهای آن باید خط‌به‌خط به کدها نگاه کنیم، کیفیت کدها را بسنجیم و کارهایی از این دست اما در عین‌ حال در اکثر مواقع از سؤالاتی کلی که در مورد پروسهٔ ریفکتور کردن نرم‌افزار باید از خود بپرسیم، غافل می‌شویم! در همین راستا، در ادامه به بررسی در مورد بهینه‌ترین روش به‌ منظور اِعمال تغییرات و یا برطرف کردن باگی می‌‌پردازیم که در نرم‌افزار به‌ وجود آمده است.

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

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

وقتی که قرار است باگی را رفع کنیم و یا فیچر جدیدی را تست کنیم، دیتایی که با آن کار می‌کنیم می‌بایست تا حد ممکن شبیه به همان چیزی باشد که کاربران پس از تعامل با اپلیکیشن ما وارد دیتابیس می‌کنند. مثلاً اِسترینگی همچون lorem ipsum در طراحی قالب‌ و پر کردن فیلدهای یک فرم خوب به‌ نظر می‌رسد، اما وقتی حتی در فیلدی که قرار است عدد دریافت کند چنین متنی را وارد می‌کنیم، در وَلیدیشن فرم‌ها نیز دچار گمراهی خواهیم شد و به همین دلیل است که اصرار می‌ورزیم برای تست نرم‌افزار، از دیتای تا حد ممکن شبیه به دیتای واقعی استفاده شود.

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

ریسک‌های اِعمال تغییرات را مد نظر قرار دهید
تغییرات گاهی از هم مستقل نبوده و به‌ یکدیگر وابسته‌اند. به عبارت دیگر، این تغییرات می‌توانند روی دیگر قسمت‌های سیستم هم اثر بگذارند که در چنین شرایطی چنانچه متوجه شدید که تغییرات مد نظرتان به طور کامل از هم مستقل نیستند، تصمیم‌گیری برای ادامۀ کار کمی دشوار می‌شود. در موارد ساده، این امکان وجود دارد تا یک تغییر کوچک روی قسمت‌هایی که روی یکدیگر تأثیر می‌گذارند انجام دهیم تا مطمئن شویم که هنوز مطابق انتظار کار می‌کنند و سپس به‌ دنبال تست‌های خودکار برویم اما در موارد پیچیده‌تر، باید مطمئن شویم که فکری به‌ حال پیامدهای احتمالی این تغییرات کرده‌ایم و برنامه‌ای برایشان در نظر گرفته شده است.

تمرکز روی خروجی نرم‌افزار را از دست ندهید
قبل از اینکه در مورد کیفیت کدها فکر کنید، لازم است سؤالاتی از خود بپرسید که از جملهٔ مهم‌ترین آن‌ها می‌توان به موارد زیر اشاره کرد:

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

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