35 thói quen làm cho code khó bảo trì

Các thói quen xấu là rất khó bỏ và thậm chí là càng khó khăn hơn nếu bạn không nhận ra là những gì bạn làm đang làm giảm hiệu quả công việc. Nếu bạn đã biết nhưng lại không quan tâm đến, thì điều đó lại càng tồi tệ hơn. Với một người lập trình, tôi thấy có rất nhiều thói quen ko tốt, không chỉ xoay quanh việc code, mà cả bao gồm các kỹ năng làm việc nhóm. Sau đây là 35 thói quen xấu được tổ chức thành 4 nhóm: tổ chức code, làm việc nhóm, viết code, test và bảo trì.

I. Tổ chức code

1. Nói "Tôi sẽ sửa nó sau" và không bao giờ làm

Thói quen trì hoãn sửa code không đơn thuần là một vấn đề của độ ưu tiên. Tổ chức theo dấu các vấn đề của bạn cần một vài quy trình, nhưng bạn cũng có thể có một vài cách để theo dấu các vấn dề nhỏ hơn khi xảy đến. Thêm TODO vào trong comment là một cách nhanh nhất đảm bảo bạn không bỏ quên thứ gì

2. Khăng khăng với một giải pháp một dòng

Khi quá ám ảnh với việc viết code hiệu quả, những đoạn code linh hoạt là một bẫy phổ biến của các lập trình viên. Nó giống như giải một câu đố, bạn phải tìm cách để kết hợp các hàm và các cách biểu diễn để chuyển 20 dòng code thành 2 hay 3 dòng. Thật không may, nó sẽ không luôn mang lại một đoạn code dễ đọc, mà lại có thể tạo ra nhiều hậu quả hơn. Vì vây, điều đầu tiên là cần làm cho code dễ tiếp cận, dễ đọc hơn là phải tạo vẻ thông minh.

3. Tạo ra sự tối ưu hoá vô nghĩa

Một khía cạnh mà chúng ta thường để tốn quá nhiều effort là vấn đề tối ưu hoá. Thật tuyệt khi ta có thể giảm kích thước của trang web còn vài byte, nhưng không nên phải bắt buộc làm điều đó bằng mọi giá, và nên ưu tiên vào những yêu cầu quan trọng hơn. Tối ưu hoá nên thực hiện vào cuối một project, bởi vì thông thường, các yêu cầu sẽ thay đổi, và khi đó, bạn sẽ phải lãng phí nhiều thời gian để sửa lại.

Như Donald Knuth có câu nói:

“Premature optimization is the root of all evil.”
Tối ưu hoá sớm là khởi đầu của tất cả tội ác.

4. Thuyết phục bản thân là các vấn đề về bố cục là không quan trọng

Nếu qua nhiều năm, bạn học được một vài điều thông qua xem các đoạn code của người khác, các vấn đề bố cục (như căn lề, dấu nháy đôi, đơn, khoảng cách các space, ...) thường là điều mà các lập trình viên rất thích bỏ qua. Có thể rất khó cho các coder thiếu kinh nghiệm để thấy được lợi ích mang lại từ việc lưu ý đến các vấn đề bố cục, nhưng qua thời gian, nó sẽ trở thành bằng chứng về chất lượng của code, và sẽ dần dần biến project thành một mớ hỗn độn hoàn toàn.

Hãy nghiêm khác trong các hành động nên làm, thậm chí đó là các hành động không cần thiết. Cài đặt các công cụ kiểm tra code, bố cục code (vd rubocop, ...) để dành thời gian quan tâm hơn về những điều quan trọng khác.

5. Quét mọi thứ vào dưới tấm thảm

Đó là một khái niệm trừu tượng, khi ta bỏ qua các exception, hay sử dụng các thư viện mà không thông báo lỗi, ta đã dấu tất cả mọi thứ đi. Và khi một trong các lỗi đó trở nên nguy hiểm, vấn đề sửa chữa sẽ là một thách thức không nhỏ, khi bạn không có một chút bằng chứng chúng được bắt đầu từ đâu.

Một cách dễ dàng để cảnh báo đó là ghi log. Với các kết quả gì đó, ta có lưu lại trong file log, có thể định nghĩa một file log mới thay vì file log mặc định , để dễ dàng tìm kiếm và sửa chữa.

6. Sử dụng tên không bổ sung thông tin gì

Đặt tên là một vấn đề khó, nhưng đó là một cách dễ dàng để đảm bảo các biến và hàm đảm bảo chất lượng. Vì ngay khi các tên bổ sung thông tin cần thiết, các lập trình viên khác sẽ dễ dàng hơn để đọc code. Tên rất quan trọng, nó phải chứa thông tin tổng quan về đoạn code thực thi. Bởi vì, bạn sẽ phải mất rất nhiều thời gian và suy nghĩ để hình dung mục đích của đoạn code là gì, nhưng với một cái tên tốt, thì bạn có thể hiểu chỉ trong vài giây.

7. Bỏ qua các hành động tốt đã được chứng minh

Review code, viết test (TDD), đảm bảo chất lượng, tự động deploy - những hành động này và các hành động khác đã được chứng minh giá trị không thể đong đếm được trong các dự án, vậy tại sao các dev lại thường bỏ qua chúng.

Một tài liệu tham khảo tốt về các hành động tốt là quyển sách Making Software: What Really Works , and Why We Believe It. Hãy dành thời gian học cách thành thục chúng, và quá trình phát triển của bạn sẽ được cải thiện đáng kinh ngạc.

II. Làm việc nhóm

8. Bỏ qua các kế hoạch quá sớm

Một cách chắc chắn làm cho hệ thống của bạn khó hiểu đó là không chốt một kế hoạch. Bạn có thể luôn luôn nói, bất cứ khi nào code của bạn bị chỉ trích hay có lỗi, kế hoạch không hoàn thành. Tuy nhiên, có một nửa module sẽ dẫn đến ràng buộc code ngay khi bạn cố gắng làm cho các module dang dở hoạt động được với các module khác. Điều này cũng xảy ra khi leader của project thay đổi và người mới quyết định làm theo cách của anh ấy hơn là đảm bảo tính toàn vẹn của kiến trúc.

9. Khăng khăng làm theo một kế hoạch mà có rất ít cơ hội hoạt động

Từ bỏ kế hoạch có thể dẫn đến nhiều vấn đề, nhưng khăng khăng theo một kế hoạch cũng không là cách tốt. Đó là lý do bạn nên chia sẻ ý kiến với đồng nghiệp trong team để nhận lời khuyên khi gặp các trường hợp phức tạp. Một cái nhìn khác có thể luôn tạo ra sự khác biệt.

10. Làm việc theo cách của bạn trong mọi lúc

Bạn nên chia sẻ tiến trình và ý tưởng của bạn với team. Thỉnh thoảng, bạn nghĩ là bạn đang làm mọi thứ theo đúng hướng, nhưng không, một vài trao đổi liên tục rất đáng giá. Ngoài ra, nó cũng hỗ ích cho những người khác khi bạn làm việc cùng họ. Công việc của họ sẽ cải thiện khi bạn trao đổi ý tưởng với họ và hướng dẫn các thành viên ít kinh nghiệm trong nhóm, những người rất dễ gặp trở ngại.

11. Từ chối viết code xấu

Sẽ có một thời gian trong cuộc đời của mọi dev, khi deadline đến, và bạn bắt buộc phải viết các đoạn code tồi tệ. Bạn cố gắng cảnh báo khách hàng hay người quản lý về hậu qủa, nhưng họ khăng khăng chỉ theo deadline, vì vậy đã tới lúc phải code. Hay có thể có một lỗi khẩn cấp không thể đợi để đưa ra một giải pháp đẹp hơn. Đó là lý do tại sao một nhà lập trình phải thật linh hoạt và chấp nhận viết các đoạn code tệ hại thật nhanh như khi viết code đẹp. Và hy vọng, bạn nên xem lại các đoạn code đó và trả lại món nợ khi có thời gian.

12. Thú tội

Đây không là điều bí mật, khi kiêu căng là một đặc điểm quá phổ biến của các dev và các chuyên gia công nghệ khác. Hãy có trách nhiệm với các sai lầm của bạn là một minh chứng khiến bạn trở thành một ngôi sao giữa mọi người. Đừng sợ hãi khi bạn thừa nhận bạn là người tạo ra lỗi. Ngay khi bạn chấp nhận điều đó, bạn sẽ hoàn toàn thoải mái để tập trung vào tìm hiểu tại sao bạn lại gây ra lỗi đó, và cách phòng tránh. Nếu bạn không thừa nhận, thì việc học sẽ trở nên bất khả thi.

13. Không chia sẻ với team những gì bạn đã học

Giá trị của một dev không chỉ là các đoạn code bạn viết, mà bao gồm cả điều bạn đã học khi viết chúng. Chia sẻ kinh nghiệm, viết bình luận về chúng, cho người khác biết tại sao những thứ này phải theo cách của chúng, và giúp họ hiểu những điều mới về dự án và những điều phức tạp khác.

14. Quá chậm chạp trong việc phản hồi cho quản lý hay khách hàng

Một trong những đặc điểm giá trị nhất của một thợ lành nghề là đảm bảo mọi người biết rõ về công việc nhiều nhất có thể. Lý do cho điều đó không chỉ là quản lý của bạn sẽ có đầy đủ đánh giá, mà đó cũng là cho bạn: Bạn sẽ có ít hơn các nguy cơ tiềm tàng và giảm bớt các vấn đề không chắc chắn về thời gian và tương lai của dự án.

15. Không sử dụng Google một cách đầy đủ

Cách tốt nhất để giải quyết các vấn đề phức tạp nhanh chóng là không có giải pháp cho vấn đề đó một cách đầy đủ. Khi có nghi ngờ, hãy Google. Dĩ nhiên, bạn có thể làm phiền người đồng nghiệp bên cạnh, nhưng hiếm khi anh ấy có thể đưa ra một câu trả lời đầy đủ như Stack Overflow, đấy là còn chưa kể bạn sẽ làm gián đoạn công việc của anh ấy.

16. Quá đề cao phong cách cá nhân của bạn

Luôn luôn hoà hợp phong cách làm việc của bạn và môi trường làm việc của cả team. Mọi người trong team nên làm việc theo các điều kiện tương đương và theo các phong cách code giống nhau. Dù cho phong cách của bạn có thể hay hơn, nhưng đồng nghiệp thường không sử dụng phong cách của bạn, và nó sẽ khó khăn cho những người sau này để làm theo cách mà bạn đã tạo ra trước đó.

17. Đưa ra quan điểm cá nhân vào code

Khi comment vào code, đừng làm theo quan điểm cá nhân, có người muốn đoạn điều kiện thì phải theo ý kiến cá nhân của họ. Code nên được chuẩn hoá theo các quy định, bạn nên đưa ra giải thích tại sao viết theo cách này. Nếu thực sự cần cải thiện, thì đó là cho sự chính xác của code, chứ không phải là của bạn.

III. Viết code

18. Không biết về tối ưu hoá

Một chiến lược để tối ưu hoá tốt cần phải có kinh nghiệm để thực hiện. Bạn cần phải tìm tòi, phân tích và biết toàn bộ về hoạt động của quá trình. Cần phải học về độ phức tạp của thuật toán, đánh giá các truy vấn database, các giao thức và cách đo hiệu năng tổng thể.

19. Sử dụng sai công cụ khi làm việc

Bạn có thể biết rất nhiều, nhưng lý do tại sao bạn phải tiếp tục học là mỗi một vấn đề mới đều nằm trong một bối cảnh khác nhau và yêu cầu một công cụ khác nhau , vì vậy hãy sở hữu càng nhiều công cụ cho một vấn đề trong tay. Có thể tạo các thư viện mới, hay sử dụng ngôn ngữ mới. Đừng đưa ra lựa chọn bắt buộc trong những gì bạn biết.

20. Không quậy phá các công cụ hay IDE

Mỗi hotkey mới, phím tắt hay tham số bạn học trong khi sử dụng các công cụ mà bạn làm việc hằng ngày sẽ có một hiệu quả rất lớn với tốc độ code, hơn cả những gì bạn nghĩ. Bạn càng dành nhiều thời gian cho mỗi hành động nhỏ, thì càng ít thời gian bạn phải nghĩ tại sao phải làm điều hay và chuyển sang vấn đề khác. Hãy là bậc thầy về phím tắt

21. Bỏ qua các thông điệp lỗi

Đừng cho rằng bạn biết điều gì gây ra lỗi code của bạn mà thậm chí không cần đọc một thông điệp lỗi. Có rất nhiều thông tin về một vấn đề sẽ tốt hơn và dành thời gian để thu thập thông tin sẽ tiết kiệm được nhiều thời gian sau này hơn.

22. Say mê bộ công cụ phát triển của bạn

Thỉnh thoảng, bộ editor mà bạn thích hay trình command line lại không phải là công cụ phù hợp nhất cho công việc của bạn. Visual Studio thật tuyệt khi làm việc IDEs, Sublime thì phù hợp hơn với các ngôn ngữ động, Eclipse thì cho Java, ... Bạn có thể thích thú với vim, hay emacs, nhưng không có nghĩa đó là công cụ tốt cho mọi công việc.

23. Hard code giá trị thay vì đưa chúng vào config

Luôn luôn phải suy nghĩ là thay đổi sẽ đến và cần nghĩ cách để đối phó với sự thay đổi. Món nợ kỹ thuật sẽ tăng rất nhanh nếu bạn không chia tách những phần dễ thay đổi. Hãy sử dụng hằng số và file config một cách cần thiết.

24. Viết lại giải pháp khác mọi lúc

Đừng viết code khi bạn không cần. Có thể ai đó đã dành thời gian cho vấn đề của bạn rồi, họ đã có một giải pháp được test tốt rồi, và bạn có thể dùng lại. Nó sẽ giúp bạn tránh khỏi nhiều rắc rối.

25. Copy / pase code mù quáng

Hãy hiểu code trước khi sử dụng lại chúng. Thỉnh thoảng, bạn không chú ý mọi thứ ngay lập tức trong cái nhìn đầu tiên, bạn cũng sẽ học về một vấn đề nào đó khi bạn dành thời gian để đọc code chi tiết.

26. Không dành thời gian để học những điều bên dưới

Luôn luôn tạo cơ hội để mở rộng hiểu biết của bạn bằng cách suy nghĩ về cách mà những thứ này làm việc và đọc những vấn đề bên dưới. Những gì bạn học trong một project quan trọng hơn là việc chỉ hoàn thành công việc.

27. Qúa tự tin vào code của bạn

Rất nguy hiểm khi khẳng định là vì đây là code bạn viết, nó phải là tuyệt vời. Bạn học được nhiều thứ về lập trình khi bạn làm việc với nhiều điều mới và đạt được kinh nghiệm, vì vậy hãy nhìn lại các đoạn code cũ liên tục và luôn xem xét lại bạn đã phát triển như thế nào.

28. Không suy nghĩ về tính thương mại cho mỗi bản thiết kế, giải pháp hay thư viện

Mỗi sản phẩm đều có điểm tốt mà bạn chỉ cần học cách sử dụng và phân tích nó. Xem qua một vài ví dụ về một thư viện sẽ không làm bạn trở thành bậc thầy về nó, và nó cũng không phải là hoàn hảo cho mọi vấn đề gặp phải trong project. Hãy tiếp tục tranh luận về mọi thứ bạn sử dụng

29. Không nhận giúp đỡ khi bạn có vướng mắc

Nhận một phản hồi ngắn không làm bạn đau, yêu cầu một sử giúp đỡ không có nghĩa là bạn thiếu năng lực. Người giỏi sẽ nhìn ra nỗ lực của bạn và thừa nhận điều không biết đó như một cách thức để học. Đó là một tính cách nên có.

IV. Kiểm tra và bảo trì

30. Viết test để pass

Viết các test mà bạn biết sẽ pass là cần thiết. Chúng sẽ hỗ trợ refactor và tổ chức lại project an toàn hơn. Tuy nhiên, bạn cũng phải viết các test mà bạn biết sẽ không pass, chúng là cần thiết để theo dõi các vấn đề. VD, nên viết cả các trường hợp thành công và thất bại, khi kết quả trả về là true và false.

31. Không quan tâm đến test hiệu năng cho các trường hợp đặc biệt

Chuẩn bị cài đặt một quy trình test hiệu năng trong giai đoạn giữa của quá trình phát triển dự án để bạn có thể đảm bảo không gặp phải các vấn đề về hiệu năng.

32. Không kiểm tra việc thực hiện của bạn đã hoạt động

Hiếm khi một thực thi được xây dựng sẽ pass nhưng không hoạt động, nhưng nó vẫn có thể xảy ra và nó có thể gây khó khăn để sửa chữa hơn là bạn xem lại. Nhanh chóng kiểm thử mọi đoạn code là một thói quen quan trọng nên có.

33. Xây dựng một sự thay đổi lớn hay bỏ qua test sau khi tạo ra một đoạn code lớn

Điều này xảy ra khi bạn quá tự tin, và điều đó có thể làm tiêu tốn rất nhiều lần thời gian để nhận ra tại sao bạn không nên làm điều đó, vì vậy hãy đảm bảo là bạn luôn luôn có ở đó khi code của bạn bị lỗi.

34. Bỏ code bạn viết

Hãy luôn hỗ trợ các đoạn code bạn đã viết. Bạn là người phù hợp nhất để giúp đỡ những người khác hiểu nó. Bạn nên tạo ra các đoạn code dễ đọc cho chính bạn và những người khác ngay từ bây giờ

35. Bỏ qua các yêu cầu không phải là chức năng

Khi bạn cố gắng release gì đó, bạn có thể dễ dàng quên vài điều quan trọng khác như hiệu năng và bảo mật. Luôn tạo một danh sách cho những điều đó. Bạn không muốn chúng sẽ huỷ hoại một sản phẩm tuyệt vời bởi vì bạn đã xây dựng deadline mà không tính tới các yêu cầu không phải là chức năng đó.

Trên đây là một vài thói quen chúng ta hay gặp trong quá trình làm việc, hi vọng bạn không mắc phải các thói quen này. Nguồn tham khảo: Avoid these 35 habits that lead to unmaintainable code