Công thức để mã nguồn thực sự là của cải

Khi có nhiều đất hơn, bạn là người giàu có hơn.

Khi có nhiều gia súc hơn, bạn là người giàu có hơn.

Khi có nhiều mã nguồn hơn, bạn có là người giàu có hơn?

Có nhiều người cho rằng:Kẻ thù số một của phần mềm là sự thay đổi.

Sẽ rất khó khăn để thay đổi công năng của toà nhà khi đã được xây, điều này tương tự như là một chiếc ô tố, chiếc thuyền, một cuốn sách giấy. Tuy nhiên với phần mềm thì điều này là dễ dàng. Như vậy nếu hiểu theo ý tích cực thì khả năng thay đổi chính là ưu điểm của phần mềm. Chúng ta sống nhờ sự thay đổi của phần mềm.

Khi hệ thống lớn lên về thời gian và kích thước mã nguồn thì việc thay đổi có xu hướng khó dần. Tôi đã từng gặp những hệ thống lớn và cả những hệ thống không lớn, nhưng việc một người mới tham gia vào gặp rất nhiều khó khăn trong thời gian dài. Và thậm chí là những người tạo ra những hệ thống đó cũng không có khả năng bảo trì khi gặp lỗi, thay đổi hoặc mở rộng và họ phải dành rất nhiều thời gian để cải tạo và thậm chí là xây lại. Điều đó có nghĩa mã nguồn này cản trở chúng ta đem lại giá trị cho khách hàng.

Chúng ta sẽ khảo sát những định nghĩa khác nhau về mã kế thừa (legacy code):

• Mã nguồn ở bất kỳ một hệ thống nào đang chạy ở môi trường sản xuất đều là kế thừa.
• Mã nguồn mà bạn viết hôm qua là kế thừa
• Mã nguồn kế thừa không chỉ là mã cũ hoặc do người khác viết cũng không phải là đang chạy ở môi trường sản xuất. Mã nguồn kế thừa là mã chống lại sự thay đổi một cách liên tục và rõ ràng — Anthony Lauder
• Mã nguồn kế thừa là mã không có kiểm thử đơn vị (unit test)

Ta thấy tính chất căn bản nhất của mã nguồn này là khó thay đổi hoặc cái giá của sự thay đổi là cao.

Có rất nhiều những phương thức sản xuất phần mềm khác nhau, tuy nhiên thì hầu hết chúng đều nói tới một điểm là bắt đầu làm một hệ thống từ đầu. Tuy nhiên rằng có rất nhiều dự án đang là các hệ thống kế thừa. Vậy có cách cải tạo nào?

Từ 2002, một gạo cội Micheal Feather đã đưa ra cho chúng ta một cách làm mà tới ngày này vẫn còn nguyên giá trị:

1. Xác định điểm thay đổi
2. Tìm một nút
3. Yểm trợ cho nút
   1. Bỏ phụ thuộc bên ngoài
   2. Bỏ phụ thuộc bên trong
   3. Viết kiểm thử
4. Thay đổi
5. Tái cấu trúc mã nguồn được yểm trợ

Để biết thêm chi tiết chúng ta có thể tham khảo cuốn “Working Effectively with Legacy Code”.


Ở Việt Nam, trong Scrum Gathering Vietnam 2015 chúng ta sẽ có hội học gặp gỡ và chia sẻ với chính Micheal Feather.

Phương pháp mà Micheal Feather mang đến cho chúng ta là công thức biến mã nguồn là của cải chứ không phải là vật cản để chúng ta đem lại giá trị cho khách hàng.

Tác giả: Phạm Anh Đới