کدِ بیات

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

حالا آمدیم که درباره «کدِ بیات» حرف بزنیم. کد ِبیات چیست؟ کدی که از زمان «بهترین تاریخ مصرف‌»ش گذشته باشد. یعنی بیش‌تر از ۲۴ ساعت از زمان نوشته شدنش توسط برنامه‌نویس گذشته باشد و هنوز در برنچ اصلی Master ادغام نشده باشد!

کد بیات بخشی از چرخه است. یک گام بعدش «مستر بیات» است. Master بیات چیست؟ برنچ اصلی که ۲۴ ساعت از آخرین تغییرش گذشته باشد و هنوز آرتیفکت بیلدشده‌ش در جایی پابلیش نشده باشد!

و در آخر «نسخه‌ بیات» را داریم. نسخه‌ای که ۲۴ ساعت از ساخت آرتیفیکت و احتمالا دیپلوی شدنش گذشته است ولی به مشتریان و کاربران «دلیور» نشده باشد.

همه‌ این‌ها در همان چرخه توسعه محصول Lean هستند. ‌می‌خواهیم بدانیم به قول خارجی‌ها From Idea to Cash چقدر طول می‌کشد؟ چقدر تند تند می‌توانیم چرخه Build-Measure-Learn را طی کنیم؟

خب از قصه دور نشویم. «کد بیات» چیست و چرا؟ در پست پیش درباره قصه‌ی «مدل برنچینگ گیت‌هاب طور» صحبت کرده بودیم. این که چقدر «نسخه دادن»‌ را خون‌بار می‌کند.

گفتیم که بعضاً ناگزیریم که همین مدل را پیش برویم. اما اگر یک «تیم» کوچک و چابک هستیم راه‌های به‌تری برای رستگاری وجود دارد.

یک پترن خوب و توصیه‌شده این است: «Trunk Based Development». یا به طور خلاصه T‌BD.

حرف حساب تی‌بی‌دی چیست؟ «فساد کد بیات بدترین فساد ممکن است. هزینه‌ش برای تیم خیلی بیش‌تر از هر چیز دیگر است. هر کدام از اعضای تیم که کدی برای خودش نوشت باید در سریع‌ترین زمان ممکن آن‌ها را در برنچ اصلی ادغام کند. یعنی ترجیحن زیر دو ساعت این کار را بکند. و تلاشش را بکند که هیچ Long Lived Branchی با عمر بیش‌تر از یک روز نداشته باشد.

در تیم‌های کوچک دو سه نفره حتی می‌شود هیچ برنچی نداشت و همه چیز را به سادگی در همان برنچ اصلی نوشت. در تیم‌های بزرگ‌تر حالا اشکالی ندارد Short Lived Branch با عمر چند ساعت داشته باشیم»

این کار طبعاً هزینه‌هایی دارد. اما مدعا این است که در نهایت هزینه‌ش برای تیم کم‌تر است. و سود خوبی نصیب تیم می‌کند. مهم‌ترین مزایا چیستند؟

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

اگر دعوایی بین کدهای اعضای تیم وجود دارد خیلی سریع آشکار می‌شود. این شاید مهم‌ترین مزیت این کار باشد! Fail Fast, Fail Often. لازم نیست دو هفته کد بنویسیم و بعد بفهمیم یکی همان حین معماری آن کلاسی که ازش استفاده می‌کردیم را عوض کرده است!

امنیت روانی کاذب و اشتباه اعضای تیم را ازشان می‌گیرد. نمی‌توانند به غار تنهایی‌شان بروند و بگویند وظیفه‌ی ما نوشتن همین تسک خاص است. و مسئولیت درست کردن نسخه و انتشارش با بقیه و مدیر تیم و مدیر محصول و این‌هاست. این رفتار کودک-والد را کنار می‌گذارند و مسئولیت مشترک محصول را به عهده می‌گیرند و بالغ-بالغ رفتار می‌کنند.

خب مخاطب این نوشته‌ها لزومن فقط برنامه‌نویسان نیستند. اتفاقاً من برای مدیران تیم و مدیران محصول می‌نویسم.

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

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