#روایت_تجربه (Storytelling)
چند وقت پیش، یکی از مهندس‌های ارشد در یک کنفرانس جمله‌ای گفت که توجهم را جلب کرد.
گفت:
«هر وقت وارد یک کدبیس جدید می‌شوم، قبل از اینکه اولین خط کد را تغییر دهم، سعی می‌کنم بفهمم تیم از تغییر دادن کدام قسمت می‌ترسد.»
ابتدا فکر کردم منظورش کیفیت کد است.
اما ادامه داد:
«در همه پروژه‌ها یک یا چند فایل وجود دارد که وقتی اسمشان می‌آید، همه می‌گویند:
لطفاً تا جای ممکن به آن دست نزن...»
نه چون آن فایل مهم‌ترین بخش سیستم است.
بلکه چون هیچ‌کس مطمئن نیست بعد از تغییرش چه اتفاقی می‌افتد.
او می‌گفت:
«همان فایل، معمولاً بیشترین بدهی فنی پروژه را دارد؛ نه لزوماً بزرگ‌ترین فایل.»
این حرف برایم جالب بود.
چون ما معمولاً بدهی فنی را با تعداد خطوط کد، پیچیدگی یا قدمت پروژه اندازه می‌گیریم.
اما شاید معیار بهتری وجود داشته باشد.
ترس تیم از تغییر.
اگر تیم از تغییر دادن بخشی از سیستم واهمه داشته باشد،
احتمالاً آن بخش، مدت‌هاست که از کنترل خارج شده است.
از آن روز، هر وقت درباره سلامت یک کدبیس صحبت می‌شود، کمتر به تعداد کلاس‌ها یا متدها فکر می‌کنم.
بیشتر به این فکر می‌کنم که:
«اگر فردا یک تغییر کوچک در این قسمت لازم باشد، آیا تیم با اطمینان آن را انجام می‌دهد؟»
چون در مهندسی نرم‌افزار،
گاهی خطرناک‌ترین بخش سیستم،
بخشی نیست که بیشترین باگ را دارد.
بخشی است که همه از تغییر دادنش می‌ترسند.