Phát triển phần mềm là một việc phức tạp hơn các thuật ngữ định nghĩa về nó. Trong ngành này, kinh nghiệm đóng một vai trò quan trọng trong sự thành công của bất quá trình sự phát triển phần mềm nào. Kinh nghiệm đã dạy cho chúng ta rất nhiều điều mà chúng ta truyền lại các bài học này cho người khác.
Các định luật này không hẳn dành cho lập trình viên. Các lãnh đạo cấp cao trong lĩnh vực công nghệ phần mềm cần nằm vững trong đầu để quản lý dự án đi đúng hướng, giảm rủi ro, hạn chế sai sót, tiết chế lãng phí tối đa có thể...
Có một số luật dựa trên kinh nghiệm có thể giúp chúng ta học hỏi từ những sai lầm của những người đi trước và tránh chúng trong tương lai. Một số trong số chúng liên quan đến sự phát triển thuần túy, một số khác liên quan đến quản lý hệ thống. Tất cả chúng đều hữu ích cho sự phát triển của bạn với tư cách là một kỹ sư phần mềm.
1. Định luật Wirth
Ứng dụng phần mềm có tốc độ lão hóa nhanh hơn so với tốc độ phát triển của phần cứng (“Software gets slower faster than hardware gets faster”).
Xem thêm: https://en.wikipedia.org/wiki/Wirth%27s_law
Định luật này được đặt theo tên của Niklaus Wirth, một nhà khoa học máy tính và cha đẻ của ngôn ngữ lập trình Pascal. Ông đã thảo luận về quy luật này trong bài báo năm 1995 có tựa đề "Lời kêu gọi về một giải pháp tinh gọn cho phần mềm" (A Plea for Lean Software).
Ý của định luật này là : lập trình ngày càng dùng nhiều tài nguyên đến nỗi các framework phải luôn tiến hóa để phục vụ cho nhu cầu gia tăng chóng mặt. Tuy nhiên tốc độ giữa phần mềm và phần cứng không song hành. Tốc độ phần cứng dù có tăng lên đi nữa thì tốc độ phần mềm cũng chẳng hề thay đổi gì. Bằng chứng rõ nhất ngày nay là dù bạn có mua máy tính đắt tiền, cấu hình cao đi nữa thì chỉ 1-2 năm sau là các trình duyệt trên máy của bạn vẫn không đáp ứng đủ nhu cầu lướt Web vì các ứng dụng Web ngày càng "nặng" và quá tải.
Trong một tựa đề sách khác, tác giả cũng viết rằng: “Hy vọng rằng sự tiến bộ trong phần cứng sẽ chữa khỏi mọi bệnh tật của phần mềm. Một chuyên gia cố vấn CNTT cũng có thể nhận thấy rằng phần mềm hoàn toàn vượt xa phần cứng về kích thước và độ chậm chạp".
2. Nguyên tắc Demeter
Còn có tên gọi khác là nguyên tắc “càng biết ít càng tốt”.
Demeter là tên gọi của Nữ thần nông nghiệp, cũng là nữ thần phân phát trong thần thoại Hi Lạp. Tên bà được dùng để đánh dấu sự ra đời của nguyên tắc này, đây có thể xem là một triết lý nền tảng của việc lập trình được sinh ra từ một aspect-oriented programming (AOP) project cùng tên.
Quan điểm cơ bản của nguyên tắc này chính là : tối giản sự hiểu biết của một object về cấu trúc, thuộc tính của các object khác ngoài nó (bao gồm các thành phần con). Nói một cách đơn giản là không tiếp xúc trực tiếp với các thành phần này.
3. Định luật Brook
Đây là một định luật, nghịch lý dựa trên kinh nghiệm thực tế: “Đưa thêm người vào dự án đang chậm, sẽ chỉ khiến nó càng chậm hơn.”.
Ví dụ: Tập hợp 9 bà bầu lại cũng không thể khiến đứa trẻ ra đời sau 1 tháng. Một căn nhà cần 5 thợ xây trong 1 năm để hoàn thành, nhưng không thể hoàn thành trong 1 tháng với 5x12 = 60 thợ xây.
Tính chất cơ bản của định luật này là:
- Cần thời gian để quen với dự án (giai đoạn ramp-up).
- Công sức dành cho việc communication sẽ tăng (theo cấp độ tổ hợp chập của 2 nếu mọi thành viên đều tương tác với nhau).
- Thay ngựa giữa dòng sẽ khiến cho thời gian hoàn thành bị ảnh hưởng, bất chấp nhân sự mới có tài năng thế nào đi nữa.
4. Định luật Murphy
Luật này được đặt ra bởi Edward Murphy - một kỹ sư hàng không vũ trụ - để đáp lại một vụ thử tên lửa thất bại vào đầu những năm 50. Luật được phát biểu như sau:
Nếu có gì có thể sai, nó sẽ sai.
Luật này dạy chúng ta tạo ra một thiết kế phòng thủ cho các phần quan trọng của ứng dụng vì cuối cùng sẽ có điều gì đó sai ở một số điểm nào đó.
Khi chúng ta giới thiệu phần mềm cho người dùng cuối, họ sẽ tìm ra những cách sáng tạo để nhập một thứ gì đó mà chúng ta không lên kế hoạch để phá vỡ hệ thống. Vì vậy, chúng ta cần làm cho phần mềm của mình đủ mạnh để phát hiện và xử lý các hành vi không mong muốn.
Luật này được nhấn mạnh trong kỹ thuật lập trình phòng thủ. Đây là một dạng thiết kế phòng thủ nhằm đảm bảo chức năng vẫn hoạt động tốt của một phần mềm trong những trường hợp không lường trước được.
5. Định luật Conway
Vào những năm 60, một kỹ sư tên là Melvin Conway nhận thấy rằng cách tổ chức đã được cấu trúc trước đó ảnh hưởng tới thiết kế của hệ thống đang được phát triển. Ông ấy mô tả ý tưởng như sau:
Các tổ chức thiết kế hệ thống bị ràng buộc phải tạo ra các thiết kế là bản sao của cấu trúc truyền thông của các tổ chức đó.
Luật này rất đúng trong thế giới phát triển phần mềm và thậm chí còn được phản ánh ở cấp độ viết mã. Cách các nhóm được tổ chức để cung cấp các thành phần phần mềm sẽ ảnh hưởng trực tiếp đến thiết kế của từng thành phần.
Ví dụ: một nhóm các nhà phát triển được tập hợp sẽ có xu hướng tạo ra một ứng dụng nguyên khối với các thành phần được ghép nối với nhau. Mặt khác, nếu được chia thành nhiều nhóm phân tán sẽ có xu hướng tạo ra nhiều dịch vụ riêng biệt với sự phân tách rõ ràng hơn cho mỗi nhóm. Cả 2 thiết kế đều không tốt hay xấu, nhưng cả hai đều bị ảnh hưởng bởi cách (các) nhóm giao tiếp với nhau. Các dự án nguồn mở, với nhiều cá nhân trên toàn cầu, thường là những ví dụ tuyệt vời về tính mô-đun và các thư viện có thể tái sử dụng.
6. Định luật Kernighan
Luật Kernighan được lấy theo tên Brian Kernighan và bắt nguồn từ một trích dẫn trong cuốn sách Các yếu tố của phong cách lập trình của Kernighan và Plauger.
Gỡ lỗi khó gấp đôi so với viết mã ngay từ đầu. Do đó, nếu bạn viết mã một cách khéo léo nhất có thể, theo định nghĩa, bạn sẽ không đủ thông minh để gỡ lỗi nó.
Nó hàm ý rằng làm cho mã đơn giản được ưu tiên hơn mã phức tạp vì việc gỡ lỗi khi bất kỳ vấn đề nào phát sinh với mã phức tạp có thể tốn kém hoặc thậm chí không khả thi.
Điều này đề cập đến vấn đề mà đa số các nhà phát triển phần mềm gặp phải trong công việc hàng ngày. Nó nhấn mạnh tầm quan trọng của mã đơn giản và con người có thể đọc được về lâu dài.
7. Định luật Knuth
Luật này của Donald Knuth nhắc nhở chúng ta rằng đừng bao giờ cố gắng tối ưu hóa mã của một ứng dụng quá sớm hoặc cho đến khi nó thực sự cần thiết.
Tối ưu hóa sớm là gốc rễ của mọi vấn đề (hoặc ít nhất là hầu hết) trong lập trình.
Thật vậy, một mã nguồn được tạo ra với sự đơn giản và dễ đọc sẽ đáp ứng được 99% nhu cầu về hiệu suất và sẽ cải thiện đáng kể khả năng bảo trì của ứng dụng đó.
Trong Java hoặc C#, các String là cố định. Chúng ta được dạy sử dụng các cấu trúc khác để xây dựng các String động, như StringBuilder. Nhưng trên thực tế, cho đến khi bạn đã đo lường hiệu năng của ứng dụng, bạn thực sự không biết bao nhiêu lần một String sẽ được tạo và tác động đến hiệu suất là gì. Đây là một ví dụ cổ điển về tối ưu hóa quá sớm.
Theo quy tắc ngón tay cái, chúng ta nên đo lường đầu tiên trước khi bắt đầu tối ưu hóa bất cứ thứ gì.
8. Định luật Linus
Luật này được đặt tên để vinh danh Linus Torvalds trong cuốn sách của Eric S. Raymond “Nhà thờ và Chợ phiên”. Nó nói rằng càng nhiều người nhìn thấy một vấn đề, thì khả năng một người nào đó đã nhìn thấy và giải quyết vấn đề đó hoặc một cái gì đó tương tự càng cao.
Với đủ nhãn cầu, tất cả các lỗi đều nông cạn.
Mặc dù ban đầu nó được sử dụng để mô tả giá trị của các mô hình mã nguồn mở cho các dự án. Nó cũng có thể được mở rộng cho các quy trình - nhiều đánh giá mã hơn, phân tích tĩnh hơn và các quy trình kiểm thử đa nguyên tắc sẽ làm cho các vấn đề hiển thị và dễ xác định hơn.
9. Nguyên tắc YAGNI
Viết tắt của “You ain’t gonna need it” – Cái (chức năng, phần) ấy rồi sẽ không cần thiết.
Đó là một nguyên tắc quan trọng nhắc nhở người lập trình rằng chiều theo phương pháp Extreme Programming (lập trình cực đoan) thì “Chưa phải lúc cần thiết thì chưa được phép làm.”.
Trong thực tế, khi ký hợp đồng dự án phần mềm, nhóm dự án gặp áp lực phải làm CR (Change Request) không nằm trong hợp đồng cũng như không thuộc phạm vi đầu bài (requirement specification). Các CR nếu chưa qua phân tích thực tế, chưa kiểm định tính khả thi (feasibility validation)... sẽ có nguy cơ chỉ là tính năng không có giá trị sử dụng. Trong khi thời gian và nỗ trực xây dựng là rất lớn. Đây là một sự lãng phí rất lớn trong ứng dụng CNTT.
10. Nguyên tắc DRY
Viết tắt của “Don’t repeat yourself”. Ý nghĩa: “Đừng lặp lại những gì giống nhau”.
Khi nguyên tắc này được áp dụng tốt, dù ta có thay đổi một phần thì những phần không liên quan cũng sẽ không bị thay đổi theo. Hơn nữa, những phần có liên quan sẽ được thay đổi cùng một lượt, giúp ích rất nhiều cho cả khâu estimate và khâu thực hiện.
Nguyên tắc này không chỉ hữu ích trong lập trình, mà còn là kim chỉ nam trong hoạt động quản lý và quản trị, nhằm giảm bớt sự lãng phí, tái sử dụng các thành phần giống nhau, nhờ đó phát triển nền kinh tế xanh, nền kinh tế tuần hoàn.
Cuối cùng
Việc tuân theo mọi luật sẽ không giúp chúng ta trở thành nhà phát triển phần mềm tốt nhất, nhưng điều đó giúp chúng ta hiểu rõ hơn về chúng. Nhiều người trong chúng ta trực tiếp hoặc gián tiếp bắt gặp những quy luật này trong cuộc sống, công việc hàng ngày.
Là một nhà phát triển phần mềm, thật tốt khi nhận thức được những luật này vì chúng có những bài học giúp chúng ta phát triển trong sự nghiệp của mình.
Hiểu được những luật này có thể là chìa khóa thành công.
