همواره بدانید چه چیزی را قرار است کامیت کنید

به نوعی می‌توان برنامه نویسان را به ۲ گروه مختلف تقسیم‌بندی کرد: گروهی که وقتی از ایشان می‌پرسید که مشغول به چه کاری هستند، به وضوح می‌توانند بگویند که مثلاً «در حال کار کردن روی کلاس مرتبط با یوزر هستم» و گروهی که پاسخی همچون «در تلاش برای بهبود روند سرویس یوزرها ام» که به نظر می‌رسد برنامه نویسی که پاسخ اول را داده است، دقیقاً می‌داند در حال انجام دادن چه کاری است اما در این در حالی است که برنامه نویس دوم بیشتر یک دید کلی نسبت به پروژه دارا است!

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

نکته به طور کلی، در سیستم‌های کنترل نسخه همچون Git، منظور از اصطلاح «Commit» ذخیره سازی تغییرات صورت گرفته روی سورس کد به صورت لوکال و روی سیستم خود برنامه نویس است و در صورتی که این تغییرات مورد تأیید باشند، در نهایت می‌تواند آن‌ها را اصطلاحاً Push کند تا سایر برنامه نویسان تیم هم بتوانند تغییرات صورت گرفته را در اختیار داشته باشند. برنامه نویسی که پاسخی مشابه پاسخ اول را در اختیار ما می‌دهد، دقیقاً می‌داند که قرار است چه کاری انجام دهد و اصطلاحاً «فوکوس» روی پروژه دارد؛ کارهایی که می بایست روی پروژه انجام شوند را تقسیم‌بندی کرده، هر بخش را در بازه ی زمانی مشخصی انجام داده و در نهایت می‌داند که کدنویسی اش منجر به بهبود کدام بخش از پروژه شده است. اما برنامه نویسانی که پاسخی مشابه پاسخ دوم ارائه می‌دهند نمی‌توانند دقیقاً بگویند که مشغول به چه کاری هستند چرا که در آن واحد می‌خواهند یک بهبود کلی روی سیستم اعمال کنند که چنین بهبودی ممکن است نیاز به ریفکتورینگ بخش قابل توجهی از سورس کد داشته باشد.

برنامه نویسان گروه اول همواره این شانس را دارند که اگر بخواهند به گذشته بازگردند، این کار را به سادگی با چند بار Ctrl +Z انجام دهند اما این قضیه در مورد برنامه نویسان گروه دوم اصلاً صدق نمی‌کند! پس به خاطر داشته باشیم که در انجام پروژه های نرم افزاری، همواره تسک ها را به بخش های کوچک و قابل کنترلی تقسیم بندی کرده، برای هر کدام از آن ها یک Deadline (ددلاین یا ضرب الاجل) در نظر بگیریم و در آن واحد فقط و فقط روی یکی از آن ها کار کرده و به محض تکمیل یک تسک، با خیال راحت سراغ تسک بعدی برویم.