حالت تاریک
فصل ۸ — راهبردهای اجرا
متروی نیویورک که در ۱۹۰۴ افتتاح شد، از کهنترین و پرکاربردترین سیستمهای حملونقل عمومی جهان است و در یک روز کاری معمولی نزدیک به شش میلیون مسافر را جابهجا میکند. کسانی که با این شبکهٔ گسترده آشنا هستند دهها بهینهسازی کوچک یاد گرفتهاند که سوار شدن را برایشان عادی کرده است. به اعلانهای تغییر سرویس دیروقت سهشنبه گوش میدهند. میدانند با چه نیر و زاویهای کارت مترو را از turnstile رد کنند. برای تازهواردان شهر، این نکات کوچک اما مؤثر را میتوان به اشتراک گذاشت تا سفرهای اول کمآشوبتر شود.
این فصل شبیه نیویورکی دوستانهای است که هنگام ورود به مترو راهنماییتان میکند. مجموعهای از نکات برای اجرای روان بازآرایی. ابتدا شیوههای خوب team-building. سپس مواردی که در طول بازآرایی باید پیگیری کنید تا در مسیر بمانید و در مراحل پایانی بدانید به چه توجه کنید. در پایان، چند راهبرد کدنویسی برای کنترل محکم بازآرایی هنگام پیادهسازی.
ساخت تیم
در فصل ۶ چند دلیل برای اهمیت تیم قوی در پروژههای نرمافزاری بزرگ — از جمله بازآراییهای جاهطلبانه — دیدیم. بیشتر روی فایدهٔ همتیمیهای قابلاعتماد در زمانهای سخت (مرحلهٔ کسلکننده یا مانع جدید) تمرکز کردیم. آنچه نگفتیم این است که تیمهایی که خوب با هم کار میکنند خلاقترند، بیشتر از یکدیگر یاد میگیرند و در نهایت بهتر و سریعتر مشکل را حل میکنند. برای این هدف، شما و همتیمیها باید مرتب در فعالیتهای team-building شرکت کنید.
گزینههای اینجا کامل نیستند، اما بهباور من مفیدترین عادتها برای تقویت رابطه با همتیمیها هستند. وقتی عادت شوند، طبیعی میشوند و بازآرایی روانتر پیش میرود.
جفتبرنامهنویسی
جفتبرنامهنویسی ابزار team-building عالی است. کار روی یک مشکل با هم فرصتی است قوتها (و ضعفها) یکدیگر را در محیطی مشارکتی و کمریسک بشناسید. اگر تیم هنوز زیاد با هم کار نکرده، در آغاز پروژه چند کار را به جفتبرنامهنویسی تشویق کنید. شروع زود مهم است: پروژهٔ تازه فرصت تنظیم عادت خوب از ابتداست؛ شناخت تواناییهای همتیمیها زودتر به پیشرفت مؤثر کمک میکند.
عملیتر، جفتبرنامهنویسی راه خوبی برای انتقال دانش است. مهندسی که تنها بخشی از سیستم را میفهمد برای پروژه و اغلب برای کل شرکت بدهی است. گاهی نمیتواند مرخصی بگیرد از ترس نیاز اضطراری. برای اینکه هیچ توسعهدهندهای جزیرهٔ دانش نباشد، جلسات جفت برای انتقال تخصص تنظیم کنید. توزیع یکنواخت دانش بار هر فرد را در بروز مشکل سبکتر میکند.
جفتبرنامهنویسی برای دیباگ یا حل مشکل دشوار یا انتزاعی هم عالی است. دو سر بهتر از یک سر: دو مهندس روی یک مسئله احتمال راهحلهای متنوعتر و رسیدن زودتر به راهحل خوب را بیشتر میکند. تبادل فعال اختلاف را رو در رو حل میکند. با هم در مسئله جلو میروید، اشتباه کمتر میکنید؛ تحقیق دانشگاه یوتا نشان میدهد کد جفتی حدود ۱۵٪ باگ کمتر دارد. همچنین حواسپرتی کمتر — هر دو وقت و انرژی گذاشتهاند و با هم فکر میکنند، وسوسهٔ ایمیل یا پیام کمتر است.
بازآرایی جفتی بهویژه مؤثر است: یکی تایپ میکند، دیگری آزادتر به تصویر بزرگ فکر میکند. در بازآرایی آسان است در کد legacy گیر کنید. جفت کمک میکند روی هدف بزرگتر تمرکز کنید و دامهای احتمالی را زودتر ببیند.
اما جفتبرنامهنویسی معایبی هم دارد. برای کشف مسئله یا یادگیری چیز جدید (فریمورک، ابزار، زبان) بعضی مهندسان — از جمله من — ترجیح میدهند تنها کار کنند. مفاهیم را بهتر یاد میگیرم اگر اول خودم در آنها گیر کنم. برای مسائل روشن و ساده، جفتنویسی همیشه پربار نیست؛ شاید کمی سریعتر و با باگ کمتر شود، اما دو مهندس روی کار ساده همیشه بهترین استفاده از منابع نیست.
جفتنویسی میتواند خستهکننده باشد. بیان فرایند فکر برای مدت طولانی انرژی بیشتری از کار آرام میخواهد. پایان جلسه شاید نیاز به استراحت و تعویض کار باشد. برای کسانی که ارتباط شفاهی قوی ندارند، جفتنویسی سخت است و مثل کار اجباری میماند. پس هنگام تشویق به جفتنویسی به تواناییها و ترجیحات همه توجه کنید.
با در نظر گرفتن معایب، چند توصیه:
جفتنویسی را تشویق کنید، اجباری نکنید
- بعضی طرفدار قوی، بعضی نه. با برجستهکردن فواید و حمایت، امیدوارانه کسانی که مردداند امتحان کنند. اجبار کسانی که راحت نیستند میتواند به نفرت از تیم و پروژه و جستجوی راه خروج منجر شود.
مهندسان با سطح تجربهٔ مشابه را جفت کنید
- مگر برای آموزش عمدی به فرد تازهکار، بهتر است مهارتها نزدیک باشند. در حل مشکل دشوار، تفاوت زیاد تجربه باعث ناامیدی میشود. ایدهها بهتر رد و بدل میشود اگر سطح فنی قابلمقایسه باشد.
جلسه را timebox کنید
- جفتنویسی خستهکننده است؛ پایان مشخص (با استراحت) بگذارید. با یک ساعت شروع کنید؛ اگر انرژی و وقت دارید، یک ساعت دیگر. فرصت تمام کردن بدهید؛ کش دادن بیش از ظرفیت کارایی را کم میکند.
حفظ انگیزهٔ همه
در فصل ۴ برنامهٔ اجرای متمرکز و متعادل ساختیم که انعطاف کافی برای جلوگیری از فرسودگی دارد. میتوانیم با قدردانی و جشن دستاوردها در طول بازآرایی طولانی، انگیزه را حفظ کنیم. بودجهٔ عظیم برای ماگ برند یا فعالیت off-site لازم نیست. راههای ساده اما مؤثر زیادی برای روحیه وجود دارد.
انگیزهٔ افراد
راه مؤثر برای تقویت انگیزهٔ همتیمی، فرصت مشارکت به شکلی است که بهترین از مهارتهای منحصربهفردش استفاده کند. خوشحالتر (و احتمالاً پربارتر) میشوند اگر روی بخشهایی کار کنند که برایشان پاداشدهندهتر است. اگر به رشد فنی یا مسئولیت بیشتر میخواهند، تا حد امکان فرصت بدهید. یادآوری کنید در فصل ۶ چگونه با دید بیشتر یا مسئولیت (و شاید promotion) او را به پروژه دعوت کردید.
اگر ممکن است، انعطاف در زمان، مکان و نحوهٔ کار بدهید. همه برای ۹ تا ۵ با ناهار ظهر مناسب نیستند. بعضی صبح زود میآیند و بعدازظهر میروند؛ بعضی نیمهروز ظهر آنلاین میشوند، بعدازظهر بچه را میبرند و بعد شام کار را تمام میکنند. با حفظ ارتباط خوب (فصل ۷)، شکرگزار و شاید پربارتر خواهند بود!
قدردانی از مشارکتهای متمایز هر فرد راه خوبی برای حفظ انگیزه است. نشان میدهد کار درست میکنند، ادامه میدهند و حس تعلق تقویت میشود. قدردانی هر شکلی میگیرد: برنامهٔ رسمی شرکت یا یادداشت دستنویس. به ترجیح هر کس توجه کنید — بعضی از تشویق عمومی در all-hands لذت میبرند، بعضی پرهیز میکنند. قدردانی در فرم اشتباه حداقل بیاثر و حداکثر فاجعه است. گاهی ایمیل thoughtful یا peer review درخشان کافی است.
مدیر میتواند در راهاندازی قدردانی از کل تیم کمک کند (و برای بودجه احتمالاً به حمایتش نیاز دارید). اما ارزش منحصربهفردی در قدردانی همتیمیها از یکدیگر هست.
مثلاً سنت سبک «برد هفته» (Win of the Week): تیم یک جام کوچک (یا شیء قابلمشاهده روی میز) میگیرد و کسی را برای کار عالی هفته قبل انتخاب میکند — از کمک در باگ سخت تا توضیح عالی patch. هفته بعد برنده برندهٔ بعدی را انتخاب میکند و جام را میدهد. تا پایان پروژه یا تا وقتی تیم بخواهد ادامه مییابد.
انگیزهٔ تیم
راه تقریباً تضمینی برای هیجان همه نسبت به کار خوب، تبدیل آن به بازی است. با gamify کردن بخشهای کسلکنندهٔ بازآرایی، شاید همتیمیها مشتاق تکمیل کار و رسیدن سریعتر به milestone شوند. مثال: Bingo ساده. مشارکتهای کوچک اما مهم در milestone فعلی را در ابزار ساخت برگهٔ Bingo بگذارید — از جفتنویسی روی مشکل سخت تا ۱۰ code review. برگهها را چاپ و توزیع کنید و جایزهٔ کوچک برای برندگان.
هنگام gamify کردن، مراقب رقابت بیش از حد باشید — انگیزهٔ خوب است اما اگر از کنترل خارج شود conflict و افت روحیه و کار تیمی میآید. عمداً جنبهٔ کار تیمی در بازی بگنجانید. در بازآرایی بزرگ جایی برای اجرای sloppy نیست؛ کیفیت کار را بیشتر از سرعت incentivize کنید. اگر فقط خط پایان مهم باشد، ممکن است گوشه ببرند.
هنگام تخمین زیرکارهای کوچک در milestoneهای بزرگ، بخشی از فرایند را gamify کنید: هر عضو بهترین حدس زمان رسیدن به معیار هدف را بدهد، با قوانین The Price is Right (نزدیکترین بدون عبور). وقتی به معیار رسیدید، برنده را در جلسهٔ بعد با drumroll اعلام کنید!
در پایان، دستاوردهای تیم را با گردهماییهایی در طول پروژه — بهویژه بعد از milestoneهای مهم — جشن بگیرید. لحظات جشن engagement پایدار و روحیهٔ خوب میسازند. اگر هیچوقت مکث برای قدردانی نباشد، بازآرایی مثل مسابقهٔ بیپایان میشود. وقت بگذارید همه را دور هم بیاورید — ناهار مشترک یا toast بعدازظهر. همه از لحظهٔ بازتاب دستاوردها سپاسگزار خواهند بود.
نگهداشتن حساب
در طول اجرای بازآرایی، پیشرفت را مرتب بررسی و حساب یافتههای مهم را نگه دارید. با اندازهگیری و بازتاب مکرر، مطمئنتر میشوید پروژه در مسیر درست است و احتمال فراموش کردن چیز مهم در مراحل پایانی کمتر میشود. نسخهٔ زندهٔ برنامهٔ اجرا (بخش «برنامهٔ اجرا» در فصل ۷) را با بهروزرسانیهای میانپروژه ادامه دهید.
اندازهگیری معیارهای میانی
در فصل ۳ راههای مختلفی برای توصیف مشکلاتی که بازآرایی میخواهد حل کند دیدیم. آن معیارها برنامهٔ اجرا را شکل دادند و پروژه به milestoneها با معیارهای خودشان شکسته شد. نباید این اهداف را در حین اجرا از دست بدهیم — خطر انحراف از مسیر. در هر پروژهٔ جاهطلبانه، در هر پیچ فرصت خطرناک scope creep هست.
با اندازهگیری هفتگی یا دو هفتهای پیشرفت به سمت هر معیار میانی، خود را مسئول جلو بردن سوزن روی اهداف مهمترین نگه میدارید. با بررسی مکرر، کمتر وسوسهٔ side questهای مماس میشوید و دامنه پروژه زیاد نمیشود. بررسیهای دورهای سرعت را هم میسنجند. اگر همه روی کار درست متمرکزند اما چند هفته تغییر مثبت در معیارها نیست، مشکلی هست — شاید باگهای سخت، یا معیارهای نامناسب برای بیان مشارکت تیم. وقتی دوباره تغییر خوب در معیارها ببینید، میدانید مشکل را حل کردهاید.
باگهای کشفشده
چه بازآرایی برای کشف و رفع باگهای سیستمیک باشد چه نباشد، در طول کار حتماً نقصهایی میبینید. برای هر باگ — چه تصمیم به رفع بگیرید چه نه — ثبت کنید: کی در پروژه کشف شد، شرایط بازتولید، و اقدامات انجامشده. معمولاً دو گزینه: رفع باگ، یا بازپیادهسازی آن (reimplement).
اگر باگ را رفع کنید و رفع بهخاطر بازآرایی آسان و تمیز باشد، مثال مستند برای نشان دادن به ذینفعان یا همتیمیها مفید است. گاهی یک یا دو باگ سخت و خوبمستند کافی است کسی که مردد بود را متقاعد کند بازآرایی ارزش دارد. اگر باگ را به بازآرایی port کنید، باید دقیقاً بدانید کجاست و چگونه بازتولید شود — برای رفع یا واگذاری به تیم مناسب.
رفع کنیم یا نه؟
عوامل زیادی در تصمیم رفع باگ در بازآرایی نقش دارند. اول، تأیید اینکه بازآرایی رفتار اصلی را دقیقاً تکرار میکند اگر همه چیز — باگها هم — عیناً کپی شود آسانتر است. با رفع باگ هنگام بازآرایی قطعاً از رفتار مرجع منحرف میشویم. نهتنها باید باگ رفعشده را در regression testing در نظر بگیریم، بلکه ممکن است باگ یا رفتار غیرمنتظرهٔ جدید هم معرفی کنیم.
در بازآرایی در مقیاس بزرگ اغلب در کد ناآشنا غوطهور میشویم. آنچه ما باگ مینامیم شاید نباشد. حتی اگر تیم مسئول feature تأیید کند نقص است، شاید زمینهٔ رفع را نداشته باشیم و آن تیم هم راحت نیست در بازآرایی شیرجه بزند. با این حال، رفع الان به کاربران زودتر شادی میدهد و راهحل بازآراییشده درستتر است. راحتی رفع فعال هنگام بروز مسئله هم هست.
توصیه: تست واحد شکستخورده برای باگ بنویسید. با تیم مسئول feature تماس بگیرید و تستها را به اشتراک بگذارید. دربارهٔ شرایط بازتولید صحبت کنید. اگر رفتار مورد انتظار است، تستها را حذف کنید و بازآرایی را ادامه دهید. اگر نقص واقعی است، تیم اولویت رفع را تعیین کند. اگر اولویت بالا، تیم اول باگ را با تستهای شما رفع کند؛ بعد از merge و pass شدن تست، رفع را در بقیهٔ کد بازآراییشده بگنجانید.
موارد پاکسازی
در «پاکسازی artifactها» (صفحهٔ ۸۷) اهمیت فاز مجزا برای پاکسازی artifactهای تولیدشده در بازآرایی را دیدیم. هر بازآرایی باید کدبیس را مرتب برای توسعهدهندگان بعدی بگذارد — انگیزهٔ اصلی بازآرایی بزرگ اغلب بهبود ارگونومی کدبیس است. قبل از اولین خط کد شاید حدس داشته باشیم چه artifactهایی تولید میشود، اما حتماً مواردی در حین کار ظاهر میشوند.
همهٔ چیزهایی که باید مرتب شوند را پیگیری کنید — چه در پایان milestone فعلی چه فقط در مراحل نهایی. فهرست را فوراً هنگام obsolete شدن بخشی از کد بهروز کنید تا در فاز پاکسازی هیچکدام جا نماند. مهندسانی که با کد بازآراییشده کار میکنند از تجربهٔ مرتب سپاسگزارند.
مثل توصیهٔ آشپز برای شستن قابلمه هنگام پخت، توصیه میکنم در طول بازآرایی مرتب پاکسازی کنید. حذف کد obsolete بلافاصله آسانتر و امنتر است — تعاملات تازه در ذهن است و اشتباه کمتر هنگام جدا کردن.
موارد خارج از دامنه
تقریباً هر مهندس در طول بازآرایی فرصتهایی برای گسترش دامنه میبیند. پروژه شانس بهتری برای رسیدن به deadline دارد اگر همه وسوسه را مقاومت کنند، اما این فرصتها را نادیده نگیرید. فهرست فرصتهای گسترش را نگه دارید. مجموعهٔ مختصر پروژههای spin-off نشان میدهد بازآرایی چقدر versatile است؛ اگر راههای متعدد برای ادامهٔ بهبود کدبیس روی مومنتوم پروژه وجود دارد، ذینفعان و همتیمیها بیشتر باور میکنند بازآرایی ارزشمند بوده. اگر تیم شما یا تیم دیگر بخواهد روی پایهٔ بازآرایی بهبود تدریجی ادامه دهد، میتواند چند پروژه از این فهرست را scope کند و فوراً شروع کند.
برنامهنویسی پربار
چند راهبرد مفید وجود دارد که بازآرایی طولانی را برای شما و تیم خوشایندتر کند. پروژههای نرمافزاری بزرگ همیشه پیچیده نیستند؛ گاهی در نوشتن چیز کاملاً جدید فقط چند مانور سخت هنگام جاسازی در کدبیس موجود است. اما وقتی حجم زیادی کد برای بازآرایی لازم است — بیشترش کپی رفتار موجود — باید با دقت طراحی و با ظرافت با پیادهسازی اولیه یکپارچه شود. فرصتهای بیشتری برای شکست فرایند دقیق وجود دارد. امیدوارم با تکنیکهای این بخش بتوانید فرایند توسعهٔ بازآرایی را با موفقیت طی کنید.
نمونهسازی اولیه
در فصل ۴ هنگام نوشتن برنامهٔ بازآرایی سطح جزئیات مناسب را هدف گرفتیم: قابلفهم برای ذینفعان غیرفنی اما بهاندازهٔ کافی مشخص برای شروع اجرا بدون ابهام. جایی که برنامه عمداً مبهم مانده، فرصت عالی برای نمونهسازی اولیه (prototyping) است.
نمونهسازی زود و مکرر — با رعایت دو اصل — در نهایت تیم را سریعتر جلو میبرد:
بدانید راهحل کامل نخواهد بود
- روی راهحلی که کلی خوب کار میکند تمرکز کنید، بدون وقت زیاد روی جزئیات. حتی ساعتها برای ایدهآل هم ممکن است تغییر نیازمندیها آن را obsolete کند (مثالهای فصل ۲). راهحل عالی مهمترین مشکلات را خوب حل میکند و انعطاف برای آینده میگذارد.
آمادهٔ دور انداختن کد باشید
- اگر یک یا دو هفته روی راهحلی کار کردید که جواب نداد، بخشهای کار را بردارید، بقیه را دور بیندازید و دوباره شروع کنید. نمونهسازی یعنی امتحان، یادگیری، شروع دوباره.
مثال: تیم میخواهد کلاس حجیم را به چند component جدا بشکند. طراحی اولیه مسئولیتهای اصلی را به سه کلاس جدید تقسیم میکند، اما مسئولیتهای جزئی مهم هنوز جایی ندارند. بهجای تعهد کامل زودهنگام، چند گزینه را prototype میکنید و ارگونومی کلاسهای جدید را در چند بخش نمونه از کدبیس امتحان میکنید. با prototypeها تیم میفهمد چه کار میکند و چه نه، و راهحلی میسازد که با بقیهٔ کدبیس خوب یکپارچه شود.
کوچک نگه داشتن تغییرات
در تغییرات گسترده روی سطح بزرگ، آسان است زیادهروی کرد. فرض کنید باید همهٔ callsiteهای pre_refactor_impl را به post_refactor_impl مهاجرت دهیم — حدود ۳۰۰ مورد در بیش از ۸۰ فایل. میتوانید find and replace ساده، یک commit، و patch برای review بگذارید. اگر مهاجرت ساده است، یک مجموعه تغییر بزرگ شاید راحتتر به نظر برسد اما معایب جدی دارد.
اول، commitهای کوچک و تدریجی نوشتن کد عالی را آسانتر میکند. با pushهای کوچک، بازخورد زود و مکرر از ابزار (مثلاً تستهای integration در CI) میگیرید. با تغییرات گسترده و کمتکرار، ممکن است در انبوه شکست تست غوطهور شوید — هر اصلاح یکی، دیگری را آشکار میکند. commitهای فشرده تأثیر را بهتر میفهمید و تستهای شکستخورده را سریعتر رفع میکنید. همین برای تأیید دستی است.
دوم، revert کردن commit کوچک از بزرگ آسانتر است. اگر مشکلی پیش آید — در توسعه یا بعد از deploy — revert کوچک فقط تغییر مشکلدار را جدا میکند.
سوم، commitهای مختصر متمرکزترند؛ پیام commit بهتر و دقیقتر مینویسید. پیدا کردن تغییرات در تاریخچه و فهم همتیمیها آسانتر — و review و تأیید خیلی سریعتر!
در پایان، تقریباً غیرممکن است همتیمی کل کد تغییریافته را بهدرستی review کند. سازمانها نباید فقط به code review برای گرفتن باگ تکیه کنند (تست جدی مهمتر است)، اما اگر پوشش تست ناکافی باشد، بار reviewer سنگین است. تغییرات بزرگ اگر به commitهای منطقی و کوتاه شکسته شوند review آسانترند.
در بازآرایی میخواهید تاریخچهٔ نسخهٔ اصلی تا حد امکان حفظ شود. از عملیاتی مثل
git mvبرای جابهجایی فایل بهجای حذف و افزودن دوباره استفاده کنید. در توضیح commit مشخص کنید بخشی از بازآرایی بزرگتر است تا مهندسان برای code owner عمیقتر در تاریخچه بگردند. برای همتیمیهای reviewer توضیح کامل بنویسید: چه انتظاری از changeset دارند و چه زمینهای لازم است.
تست، تست، تست
بازآرایی یعنی بازپیادهسازی تدریجی رفتار موجود — باید مطمئن شویم رفتار عمدی تغییر نکرده. در عمل، اثبات «هیچ چیز عوض نشده» از اثبات تغییر سختتر است؛ پس تست تدریجی و مکرر در بازآرایی حیاتی است. با اجرای مکرر unit test، integration test یا تست دستی، یا همه بیتأثیر مانده یا دقیقاً لحظهٔ انحراف را پیدا میکنید.
قبل از تغییر هر بخش کد، مطمئن شوید unit testهای مرتب و مجزا دارد. شاید تستهایی هست اما بررسی کنید caseهای بیشتری لازم نیست. اگر تستها خشن هستند (مثلاً فقط flow تابع سطح بالا بدون تست helperها)، آنها را بشکنید. تستهای granular مثل commitهای granular به محدود کردن زودهنگام مشکل کمک میکنند.
پرسیدن سؤال «احمقانه»
همه در آن جلسه بودهایم: جمعی از مهندسان ارشد، فناوری یا featureای که خوب نمیفهمیم. اول انگار همه دنبال میکنند و چند نفر بحث را هدایت میکنند. گیجایم اما میترسیم ناآماده به نظر برسیم و سؤال نمیپرسیم. دو پایان معمول: یا خاموش میمانیم و بقیهٔ جلسه را سرهم میبندیم، یا کس دیگری همان سؤالی را که ما نپرسیدیم مؤدبانه میپرسد — شکرگزاریم و سریع همسطح بقیه میشویم.
نمیتوانیم همیشه روی همتیمی کنجکاو حساب کنیم، نه اینکه در جلسه یا thread ایمیل وقت تلف کنیم و نفهمیم چه بحث میشود. پیشنهاد سوم: بلند شوید و سؤال «احمفانه» را بپرسید. با اولویت دادن به وضوح بر توهم دانایی، رفتار مهم را برای تیم مدل میکنید — هیچ سؤالی احمفانه نیست و مهمتر از همه همه روی یک صفحه باشند. بحثها پربارتر، سوءتفاهم کمتر، و سریعتر سراغ مسئلهٔ درست میروید.
در بازآرایی در مقیاس بزرگ، چون سطح تغییرات وسیع است، احتمال برخورد با بخشهای ناآشنا از کدبیس زیاد است. نترسید از متخصصان آن حوزه راهنمایی بخواهید — چه توضیح کوتاه چه walkthrough عمیق. فهم قوی از کدی که میخواهید تغییر دهید زمان توسعه را کم میکند، باگ کمتر معرفی میکند، و بینشی برای بازآرایی به شکلی که با کد سازگارتر است میدهد.
جمعبندی
بعد از push کردن commitهای نهایی و مرتبکردن همه چیز، یک کار حیاتی دیگر مانده: تلاشها را بلندمدت پایدار کنید. فصل بعد چند گام مهم برای اینکه کدبیس آهسته به حالت قبلی برنگردد بررسی میکند.