یک تیم فنی را با چندین برنامه‌نویس در نظر بگیرید که می‌توانند در بررسی کدها به یکدیگر کمک کنند. در نگاه اول، تقسیم کردن کد ریویوها بین آنها ایده خوبی به نظر می‌رسد تا ضرباهنگ تیم در تولید کدهای برنامه‌نویسی در برنچ‌های محلی روی سیستم افراد حفظ شود و کدهای تولید شده با کمترین میزان تاخیر در برنچ اصلی develop قرار گیرد. اما (همیشه یک «اما» وجود دارد!) سطوح مختلف دانش، تجربه و توجه افراد چی؟ ما با افرادی کار می‌کنیم که با هم متفاوت هستند، دانش آنها متفاوت است و حتی خلق و خوی آنها در یک روز عادی هفته متفاوت است! چگونه می توانیم تضمین کنیم که این رویکرد کدهای پایداری تولید می‌کند؟
نظرتان در مورده ایده استفاده از یک Gateway چیست؟ راهنمای اسکرام تاکید می‌کند که فقط یک PO برای تیم اسکرام وجود دارد نه کمیته‌ای از آنها. یک جرقه‌ای از این ایده به ذهن ما می‌رسد: فقط یک نفر را مسئول ریویوی کدها کنیم! این جرقه خوشبختانه بلافاصله با این سئوال به پایان می‌رسد: چه کسی مسئول این Gateway فنی است؟ تیم لیدرها؟ دولوپرهای سینیور؟ فرد مناسبی که بتوانیم در این مورد به او اعتماد کنیم کیست؟ و چرا باید برای یافتن این قهرمانان تلاش کنیم؟! آیا آنها خارج از فیلم‌ها یا سریال‌های تلویزیونی اصلا وجود دارند؟ هیچکس نمی‌خواهد این مسئولیت را در دنیای واقعی گردن بگیرد! به من اعتماد کنید! ما قطعاً به یک چیزی نیاز داریم که به آنها کمک کند تا آنرا به صورت سیستماتیک و یا حتی اکتشافی مدیریت کنند. من معتقدم این یک توافق در سطح تیم به نام "توافق تیم" یا Team Agreement است و در قلب آن، اصول کد ریویو باید تعبیه شود!
بیایید این بار چیزمیزهای چابک را رها کنیم و روی اصول کد ریویو تمرکز داشته باشیم (قطعاً آنها از روش‌های چابک می‌آیند، اما این بار من روی قسمت فنی قضیه متمرکزم). برای نمونه بیایید نگاهی سریع به اصول SOLID در برنامه‌نویسی بیندازیم. اصول SOLID شامل پنج اصل طراحی کلاس‌ها به صورت شی‌گرا هستند. آنها مجموعه‌ای از قوانین و بهترین پرکتیس‌ها هستند که باید هنگام طراحی ساختار کلاس‌ها رعایت شوند. آنها از کجا می‌آیند؟ همانطور که در بالا هم اشاره کردم از سمت پیشگامان توسعه چابک مانند عمو باب!
بیایید این اصول را یکس یکی بررسی کنیم. آنها عبارتند از:
1- فقط یک مسئولیت: یک کلاس باید یک کار را انجام دهد و بنابراین باید تنها یک دلیل برای تغییر داشته باشد. 2- باز ـ بسته بودن: کلاس ها باید برای تمدید باز و برای اصلاح بسته باشند.
3- جایگزینی Liskov: کلاس‌های فرعی باید بتوانند با کلاس‌های پایه خود جایگزین شوند.
4- تفکیک اینترفیس‌ها: تعداد بیشتری از اینترفیس‌های خاص کلاینت بهتر از تنها یک اینترفیس عمومی هستند. مشتریان نباید مجبور شوند تا عملکردی را که به آن نیاز ندارند پیاده‌سازی کنند.
5- وابستگی معکوس: کلاس‌های ما باید به جای کلاس‌ها و توابع مشخص به اینترفیس‌ها و یا کلاس‌های انتزاعی وابسته باشند.
آیا می‌خواهید در مورد آنها بیشتر بدانید؟ پس، این مقاله را بخوانید:
شما دیگر برنامه‌نویسی شی‌گرا را دنبال نمی‌کنید؟ اوکی؛ پس مواردی را پیدا کنید که در کد زدن به سبک شما کار می‌کنند (این خیلی آسان است، چون ما در عصر ChatGPT زندگی می‌کنیم!) و آنرا در Team Agreement خود با دولوپرها قرار دهید. شما فقط باید راهی پیدا کنید تا Cohesion بیشتر و Coupling کمتری در کدهای خود داشته باشید. اکنون، اوضاع بهتر به نظر می‌رسد. همه می‌توانند کد ریویو کنند و دیگر هیچ پاشنه آشیلی برای شکست (منظورم ابرقهرمانان است!) وجود ندارد! بیایید ستون ریویو را از برد کانبان تیم خود حذف کنیم! در مورد چک کردن لاجیک‌ها؟ من معتقدم که آنها چندان مهم نیستند! بیایید با یونیت تست‌ها به خدمت‌شان برسیم.
موفق باشید! چابکی یافتن کاری است که باید انجام شود!
نسخه انگلیسی نوشتار:
