Cách đây khoảng 10 năm, tôi thực sự chật vật khi học và đọc về SOLID hay Design Pattern. Thời đó tôi nghĩ không nhiều lập trình viên hiểu về SOLID hay Design Pattern, mạng xã hội cũng không phát triển như bây giờ nên kiến thức cũng ít được chia sẻ rộng rãi. Mà những người giỏi, theo tôi nghĩ thì không phải dạng lắm mồm hay khả năng xã hội cao nên những kiến thức lý thú ấy chắc thuộc về mật tông nào đó trong giới lập trình. Có thể so sánh SOLID, DP như tình dục với thiếu niên, ai cũng nói đến, ai cũng nhận làm, nhưng chả ma nào biết nó là gì. Mà 10 năm trước, ngành công nghiệp phần mềm của Việt Nam cũng chỉ mới bước đi được hơn mười năm chứ mấy. Bây giờ thời thế thay đổi nhiều. Tài liệu thì vô vàn. Mạng xã hội thì dễ tiếp cận và các lập trình viên cũng cởi mở chia sẻ hơn. Ngành phần mềm hơn 20 năm cũng có thể coi là trưởng thành. Duy có một điều, những người giỏi có vẻ vẫn ít nói. Dạo quanh các kênh youtube hay blog, nội dung về SOLID quả thực sáo rỗng, chưa kể một số bạn còn giải thích sai lè (thật không dám nói là các bạn nói linh ta linh tinh ˆˆ!). Một số kênh nội dung tốt thì trừu tượng, không hợp với các bạn như tôi 10 năm trước. Tôi không thể phủ nhận SOLID khó để giải thích. Có vẻ mỗi nguyên tắc là mười mươi như 1+1=2, nhưng chúng ta lại mãi không hiểu và mãi không áp dụng được vào công việc. Loạt bài viết này là chia sẻ của tôi về SOLID và nó mang tính kinh nghiệm hơn là kiến thức. Mục tiêu mong là có thể giúp các bạn nhận ra được góc cạnh nào đấy của SOLID. Vì là loạt bài chia sẻ kinh nghiệm nên nó không toàn diện, bản thân tôi thấy cũng chưa hiểu cặn kẽ SOLID và mỗi ngày lại nhận ra một cái gì đấy hay ho. Nói thế không có nghĩa SOLID cao siêu mầu nhiệm gì, chỉ là đôi khi nhận được một vài lợi ích từ việc cố gắng chạy theo SOLID thì ngộ ra, hoặc ăn trái đắng vì áp dụng cứng nhắc, cũng ngộ ra (chí ít cũng là được một bài học).

SOLID là các nguyên tắc, nhưng không phải là các nguyên tắc cao nhất

Chúng ta không làm phần mềm để thỏa mãn SOLID. Chắc chắn là vậy. Mỗi phần mềm đều để giải quyết một vấn đề thực tế, một đầu bài. Code tốt code xấu mà không giải quyết được vấn đề thì đều như nhau. Đồ bỏ. Nguyên tắc ấy là cái ghế, vì không phải bàn. Ngồi lên cái ghế đã phải là SOLID chưa? Xin thưa là chưa. Tôi có viết bài Hành trình của thiết kế phần mềm để trình bày những nguyên tắc ấy, bao gồm:

1. Khả năng bảo trì mã nguồn.
2. Khẳ năng tái sử dụng.
3. Khả năng mở rộng chức năng (extensibility).
4. Khả năng kiểm thử.
5. Khả năng mở rộng quy mô (scalibility).
6. An toàn và bảo mật.

6 nguyên tắc trên, trong bài này, tôi xin tóm gọn trong một: THAY ĐỔI. Chúng ta mong cầu viết ra những dòng code bền vững, nhưng để bền vững, code đấy phải biết THAY ĐỔI. Sao lại vậy? Vì "bền vững" và "thay đổi" nhắm tới hai thứ khác nhau.

• Những dòng code bền vững không phải là những dòng code không cần thay đổi, mà là những dòng code bảo vệ được những giá trị nó nhắm tới - là nguyên tắc số một, là cái ghế trên kia. Nó phải vẫn giải quyết ngon lành vấn đề sống còn của nó qua thời gian, qua sóng gió cuộc đời.
• Và để bảo vệ giá trị của nó, nó phải luôn sẵn sàng thay đổi chính nó.

Hãy nhìn các đế chế trên thế giới hiện nay, Apple, Microsoft, Google ... Đó là những đế chế bền vững và chúng là những chuyên gia số một trong việc thay đổi. Cả thế giới nói về Innovation. Để có Innovation thì trước nhất tất nhiên là Change. Và những nguyên tắc "rắn" SOLID được đưa ra lại là để giúp chúng ta sẵn sàng cho Thay đổi.

Đừng nhớ SOLID, hãy nhớ THAY ĐỔI

Cách đây 10 năm, tôi cố gắng đọc và học SOLID, thực sự thừa nhận tôi không hiểu. Cách đây 6 năm tôi mới bắt đầu cho rằng mình ngộ ra SOLID, lại không phải vì tôi nghĩ đến nó, mà là khi tôi nghĩ rất nhiều về sự Thay đổi. Không phải tôi không nghĩ về sự thay đổi trước đây, mà chưa bao giờ tôi nghĩ về sự thay đổi nhiều như thế, nghĩ về sự thay đổi không ngừng của sản phẩm. Hàng loạt câu hỏi nổ ra trong đầu:

• Chức năng này sẽ mở rộng. Sau này mở rộng thì thêm mới vào bằng cách nào?
• Cách tính này sẽ thay đổi. Sau này thay đổi cách tính thì sẽ như thế nào?
• Một API có lúc trả nhiều dữ liệu, có lúc ít. Lúc nhiều sẽ nên trả về thế nào, lúc ít sẽ nên trả về thế nào?
• Sản phẩm không chỉ đứng một mình. Nó cần tích hợp với các hệ thống khác. Làm sao để tích hợp các hệ thống khác nhau mà vẫn có thể đứng một mình?
• ...

Thật kì lạ rằng sản phẩm mà chúng ta dường như hiểu rõ, lại có rất nhiều câu hỏi vô cùng, vô định. Có những thứ nằm trong kế hoạch và chúng ta biết giai đoạn trước làm gì, cần chuẩn bị gì cho giai đoạn sau. Bên cạnh đó là những thứ không biết trước từ thực tiễn, những thứ có thể phá vỡ kế hoạch:

• Bug to. Hẳn rồi.
• Đôi khi là một chức năng ngớ ngẩn cần loại bỏ.
• Một yêu cầu cấp bách của khách hàng lớn hay tiềm năng.
• Copy chức năng đáng tiền của đối thủ.
• Bị hack.

Lan man như thế, kết lại tôi muốn các bạn hiểu rằng Thay đổi là tự nhiên, là cách thế giới vận hành, chứ không phải là cố định mãi mãi. Tôi khuyên các bạn hãy nghĩ tới sự thay đổi trong tương lai của chức năng, sản phầm, hãy luôn tự mình đặt câu hỏi, và kiểm nghiệm xem code của bạn có thể đáp ứng được hay không. Code xong cất đi là cách dễ nhất để kết thúc sự nghiệp của bạn. Ở góc nhìn này, SOLID hay Design Pattern là công cụ của bạn. Một cách trào phúng thì phần trên ta đi tìm bố cho SOLID, phần này ta nói chuyện với bố nó, ta sai khiến nó.

Bài sau chúng ta sẽ dạo qua các nguyên tắc và thấy SOLID chính là Thay đổi