Lần refactor đó bắt đầu từ một khoảnh khắc nhỏ đến mức gần như không đáng kể. Một người mở file để đổi một validation rule, rồi phải chạm vào controller, service, formatter, shared helper, và một test fixture mà không ai còn nhớ ai owns. Thay đổi vẫn làm được, nhưng đường đi trong codebase giống như bước qua một cái bàn nơi mọi sợi cáp đã âm thầm quấn vào nhau.
Một phần lõi rối hiếm khi tự giới thiệu mình là architecture problem. Nó hiện ra thành ma sát nhỏ mỗi ngày. Một feature lâu hơn dự kiến vì rule quan trọng bị lặp ở ba nơi. Một bug fix làm cả phòng im lặng vì không ai chắc side effect nào sẽ thức dậy. Một teammate mới hỏi câu đơn giản, và câu trả lời biến thành chuyến tham quan qua lịch sử, ngoại lệ, và áp lực deadline cũ.
Refactor để phần lõi rõ ràng hơn không giống việc chạy theo perfect design. Perfect design thường đòi một lần rewrite lớn và một căn phòng yên tĩnh mà product work thật không mấy khi cho ta. Một phần lõi rõ hơn hỏi câu khiêm tốn hơn: phần nào của hệ thống nên dễ tìm, dễ gọi tên, và khó bị bypass một cách vô tình?
Bước đầu thường là quan sát, không phải di chuyển. Trước khi move code, nên trace xem business rule đi vào đâu, đổi hình dạng ở đâu, được lưu ở đâu, và cuối cùng user thấy kết quả ở đâu. Trace đó biến cảm giác khó chịu mơ hồ thành một bản đồ. Không có bản đồ, refactor dễ thành tranh luận về gu. Có bản đồ, team có thể chỉ vào coupling cụ thể và chọn phần nào đáng được bảo vệ.
Một phần lõi hữu ích có ít cớ bên trong nó hơn. Nó không cần biết mọi màn hình, mọi transport detail, hay mọi integration tạm thời. Nó giữ rule bằng ngôn ngữ team hiểu được. Phần rìa có thể translate request, render response, và quản lý infrastructure. Phần trung tâm nên làm behavior quan trọng readable ngay cả với người tham gia sau khi áp lực ban đầu đã qua.
Những refactor nhỏ thường an toàn hơn những lần anh hùng. Đổi tên một concept để khớp với ngôn ngữ mọi người dùng trong planning. Đưa một rule vào sau một boundary. Thêm một test mô tả behavior trước khi đổi hình dạng quanh nó. Xóa một helper giả vờ là shared nhưng thật ra mang assumption của một feature đi khắp nơi. Mỗi bước nên làm bước tiếp theo dễ hiểu hơn.
Trade-off là clarity tốn thời gian trước khi trả lại thời gian. Một team đang áp lực có thể hỏi vì sao một feature nhỏ cần thêm sự cẩn thận này. Câu trả lời trung thực không phải dòng nào cũng cần ceremony. Câu trả lời là có những khu vực trở thành trạm thu phí của future work. Nếu phần lõi khó hiểu, mọi feature sẽ trả phí đó thêm lần nữa.
Refactor tốt cũng giữ lại sự tôn trọng. Khi thấy code rối, ta dễ phán xét người đã viết nó. Nhưng đa số phần lõi rối được tạo bởi những người đang cố ship với thông tin chưa đủ. Mục tiêu không phải chứng minh quá khứ cẩu thả. Mục tiêu là làm thay đổi tiếp theo ít phụ thuộc hơn vào trí nhớ, may mắn, và một người duy nhất còn biết đường đi ẩn.
Một phần lõi rõ hơn không làm codebase nhẹ như không. Nó làm những phần quan trọng trung thực hơn. Khi một teammate mở hệ thống và thấy rule trung tâm nằm ở đâu, họ nhận được nhiều hơn vài file sạch. Họ nhận được một cách bình tĩnh hơn để tiếp tục công việc. Nếu bạn từng thấy một refactor làm mood của team đổi khác, mình rất muốn nghe điều gì đã rõ ra đầu tiên.