Nhái Cốm Blog

I love you just the way you are

0R8A4000_

11 nguyên tắc lập trình viên nên tuân theo

Leave a comment

Author: jsonmez
Original Post in English: 11 Rules All Programmers Should Live By

(lược dịch)

Cá nhân tôi là một người sống có nguyên tắc.

Phải thừa nhận rằng những nguyên tắc dưới đây tôi tự đặt ra cho chình mình, nhưng dẫu sao chúng vẫn là những nguyên tắc.

Tôi nhận ra rằng việc tạo những nguyên tắc cho bản thân giúp tôi làm việc hiệu quả hơn. Tôi có thể quyết định sớm nhiều vấn đề thay vì phải đối mặt với những quyết định một cách thụ động.

Liệu tôi có nên đi tập thể hình sáng hôm nay không?

Tôi có một nguyên tắc là sang thứ 4 tôi sẽ đi tập thể hình và hôm nay chính là thứ 4. Vì vậy tôi sẽ đi, việc đó đã được quyết định.

Tuần này, trong lúc nhớ lại những nguyên tắc tôi áp đặt cho chính mình, tôi đã nghĩ rằng sẽ rất tốt nếu tôi tổng hợp chúng lại thành một bộ nguyên tắc; bộ nguyên tắc bất kì lập trình viên nào cũng nên tuân theo.

Tôi cũng phải thừa nhận rằng phần lớn những nguyên tắc dưới đây tương tự như là những lời chỉ dẫn. Dù sao đi nữa, đây là những nguyên tắc mà tôi đề cập:

1. Công nghệ là cách bạn tìm ra giải pháp, bản thân công nghệ không phải là giải pháp

Chúng ta có thể sử dụng bộ khung ứng dụng Javascript (Javascript framework), Angular chẳng hạn , ngôn ngữ lập trình hay thậm chí là hệ điều hành mới nhất; nhưng bản thân chúng không phải là những giải pháp thực sự cho những vấn đề mà chúng ta, với tư cách những lập trình viên, phải giải quyết. Chúng chỉ đơn giản là những công cụ giúp chúng ta giải quyết vấn đề.

Chúng ta phải thật cẩn thận để không quá cuồng tín vào một công nghệ nào đó mà chúng ta thích hoặc được sử dụng rộng rãi. Đừng giết gà bằng dao mổ trâu!

2. Thông minh là kẻ thù của sự rõ ràng

Khi viết mã, bạn nên hướng đến việc viết sao cho rõ ràng và dễ hiểu.

Những dòng mã có khả năng liên hệ với mục đích thực hiện một cách rõ ràng có giá trị hơn nhiều so với những dòng mã khó hiểu, bất kể chúng tuyệt vời đến thế nào đi nữa.

Không hẳn luôn đúng nhưng nói chung, thông minh là kẻ thù của sự rõ ràng.

Khi ta viết mã “thông minh”, mã đó thường là không rõ ràng.

Mỗi khi bạn định làm gì đó “một cách thông minh”, bạn thực sự cần nhớ đến nguyên tắc này.

Thi thoảng chúng ta viết code “thông minh” nhưng vẫn sáng sủa nhưng đó không phải là vấn đề tôi đề cập đến.

3. Chỉ viết mã khi bạn buộc phải viết

Nguyên tắc này có vẻ hơi mâu thuẫn. Dù sao đi nữa, chẳng phải công việc của một lập trình viên là viết mã sao?

Câu trả lời là nó vừa đúng, vừa sai.

Công việc của chúng ta liên quan đến việc viết mã, nhưng chúng ta nên hướng đến việc viết sao cho ít nhất có thể mà vẫn giải quyết được vấn đề.

Điều này không có nghĩa chúng ta nên thu gọn mã của mình nhiều nhất có thể hay đặt tên biến chỉ bằng 1, 2 kí tự. Nó có nghĩa là chúng ta nên cố gắng chỉ viết mã cần thiết phục vụ cho tính năng được yêu cầu.

Thông thường, bạn sẽ bị cám dỗ bởi việc thêm vào thật nhiều tính năng hấp dẫn hay viết mã thật tổng quát và linh hoạt, sao cho nó có thể bao quát tất cả những tình huống khác nhau có thể xảy ra. Nhưng điều thường diễn ra là mỗi khi chúng ta cố gắng đoán xem tính năng nào là hữu ích hay vấn đề nào có thể xảy ra sau này, chúng ta thường đưa ra câu trả lời sai.

Những đoạn mã thêm thắt này không mang lại giá trị gì cả, trái lại nó ẩn chứa rất nhiều nguy cơ tiềm tàng. Càng nhiều mã, càng nhiều cơ hội xuất hiện lỗi cũng nhưng chúng ta phải tốn nhiều công sức hơn nhằm bảo trì phần mềm.

Một kĩ sư phần mềm tốt không viết mã trừ khi nó thật sự cần thiết.

Một kĩ sư phần mềm tuyệt vời sẽ xóa bớt đi nhiều mã nhất có thể.

4. Chú thích đa phần là không tốt

Tôi không ủng hộ cho việc viết chú thích kèm với mã và hoàn toàn đồng ý với Bob Martin khi anh ấy phát biểu rằng:

“Mỗi lần bạn viết một câu chú thích, bạn nên cau có và cảm thấy bực mình vì sự thất bại trong việc diễn tả của mình.” — Clean Code: A Handbook of Agile Software Craftmanship

Điều này khôgn có nghĩa bạn không nên viết bất kì lời chú thích nào; nhưng trong phần lớn trường hợp, bạn nên tập trung vào việc đặt tên cho dễ hiểu thay vì viết những câu chú thích.

Những câu chú thích chỉ nên được sử dụng khi không có cách nào xây dựng mối liên hệ rõ ràng giữa tên biến, tên hàm với mục đích của chúng. Chú thích được sử dụng để mô tả cho mục đích thực sự khi bạn không thể dễ dàng diễn đạt bằng mã.

Chẳng hạn một câu chú thích nói rằng một thứ tự bất bình thường xảy ra khi thực thi một đoạn mã không phải do lỗi mà là kết quả được biết trước, gây ra bởi một lỗi của hệ thống bên dưới.

Nói chung, những câu chú thích không chỉ không tốt vì sự không cần thiết trong phần lớn trường hợp mà còn bởi vì chúng không diễn đạt chính xác vấn đề.

Lập trình viên có xu hướng không cập nhập lại những câu chú thích cùng với mã, điều này dẫn đến việc những câu chú thích trở nên nguy hiểm bởi vì chúng có thể lái bạn sang một hướng đi hoàn toàn sai lầm.

Bạn có đối chiếu từng câu chú thích với mã tương ứng để đảm bảo rằng mã đang thực hiện chính xác điều mà câu chú thích đang diễn đạt? Trong trường hợp bạn làm như vậy, mục đích của việc sử dụng chú thích ở đây là gì? Trong trường hợp bạn không làm, liệu bạn có thể tin tưởng nội dung mà câu chú thích thể hiện hay không?

Đây là một tình huống cực kì khó xử, vì vậy tốt hơn hết là tránh nó càng xa càng tốt.

5. Luôn chắc chắn điều đoạn mã sẽ thực hiện trước khi viết

Điều này có vẻ hiển nhiên nhưng thực sự không phải như vậy.

Bao nhiêu lần bạn ngồi xuống, bắt đầu viết mã mà không hiểu cặn kẽ đoạn mã bạn sẽ viết sẽ làm những gì?

Tôi không thể nhớ nổi đã bao nhiêu lần mình làm như vậy. Vì thế đây là nguyên tắc tôi cần phải đọc thường xuyên.

Việc thực hành phát triển phần mềm theo hướng kiểm thử (Test Driven Development – TDD) có thể giúp bạn trong vấn đề này bởi vì rõ ràng là bạn phải biết đoạn mã thực hiện cái gì trước khi bạn viết nó. Nhưng nó sẽ không giúp bạn ngăn việc tạo ra những đoạn mã sai. Vì vậy, việc đảm bảo bạn hiểu chính xác và đầy đủ yêu cầu của tính năng mình đang xây dựng trước khi bạn thực hiện là cực kì quan trọng.

6. Kiểm tra mã trước khi chuyển đi

Đừng ném mã bạn viết qua và bắt đội ngũ kiểm thử chịu gánh nặng kiểm tra; bạn đang tiêu tốn thời gian của tất cả mọi người chỉ để có những báo cáo và giải pháp sửa lỗi không cần thiết.

Thay vì đó, hãy dành một chút thời gian kiểm tra toàn bộ các tình huống trước khi bạn thông báo mình đã hoàn thành việc thực thi mã.

Chắc chắn rằng bạn sẽ không thể tìm ra mọi lỗi trước khi bạn chuyển phần mềm đến đội ngũ kiểm thử. Nhưng ít nhất bạn sẽ tìm ra trước những lỗi ngớ ngẩn, những lỗi chúng ta vẫn thường mắc phải hết lần này đến lần khác.

Rất nhiều lập trình viên nghĩ rằng chỉ có đội ngũ kiểm thử mới thực hiện việc kiểm tra. Điều này đơn giản là không đúng. Chất lượng sản phẩm là trách nhiệm của tất cả mọi người.

7. Học kiến thức mới hàng ngày

Nếu bạn không cập nhập kiến thức mới hàng ngày, bạn sẽ ngày càng thụt lùi bởi vì tôi cá rằng bạn sẽ quên một cái gì đó.

Sẽ không quá tốn thời gian để học một cái gì đó mới hàng ngày.

Bạn chỉ phải dành khoảng 15 phút để đọc một cuốn sách. Tôi đã đọc trọn vẹn rất nhiều sách trong năm vừa qua chỉ với 45 phút mỗi ngày.

Những tiến bộ nhỏ bạn có được hàng ngày sẽ được tích lũy qua thời gian và trở nên to lớn trong tương lai. Nhưng bạn phải bắt đầu ngay bây giờ nếu bạn muốn giành được phần thưởng đó.

Bên cạnh đó, công nghệ đang thay đổi rất nhanh chóng.Nếu bạn không liên tục nâng cao các kĩ năng của mình và học những kĩ năng mới, bạn sẽ rất nhanh chóng bị bỏ rơi lại phía sau.

8. Lập trình là niềm vui

Thật vậy! Tôi nghĩ có lẽ bạn không chọn nghề này chỉ vì thu nhập cao.

Ý tôi là không có gì sai khi chọn một nghề có thu nhập tốt, nhưng bác sĩ hay luật sư có lẽ là một lựa chọn tốt hơn nhiều.

Lý do lớn nhất bạn trở thành một lập trình viên là bởi vì bạn yêu thích lập trình. Vì vậy, đừng quên rằng bạn đang làm điều mình yêu thích.

Lập trình mang lại rất nhiều niềm vui. Tôi ước rằng tôi có thể viết ra nhiều mã hơn nữa.

Trong thời gian này, tôi luôn quá bận với công việc của mình để dành nhiều thời gian cho việc lập trình. Đó là một trong những lý do tại sao tôi có thể hình dung rõ ràng niềm vui mà việc lập trình mang lại.

Có lẽ bạn đã quên đi niềm vui trong việc lập trình. Đây là lúc nhớ lại bạn đã từng vui vẻ thế nào với việc bắt đầu một dự án hoặc đơn giản là thay đổi cách nghĩ và nhận ra rằng bạn được lập trình và được trả tiền cho công việc đó.

9. Bạn không thể biết tất cả

Càng học nhiều bạn càng nhận ra rằng có quá nhiều điều bạn chưa biết.

Nhận ra điều này rất quan trọng bởi nếu không, bạn sẽ tự huyễn hoặc với suy nghĩ mình biết mọi thứ.

Sẽ chẳng có gì to tát nếu bạn không biết mọi câu trả lời.

Sẽ là bình thường nếu bạn phải nhờ ai đó trợ giúp hoặc giảng giải khi bạn không hiểu vấn đề.

Trong nhiều trường hợp, bạn có thể học điều mình cần biết ngay khi bạn phải biết. Bạn có thể tin tôi về vấn đề này vì nó diễn ra với tôi rất nhiều lần.

Ý tôi là đừng ép mình học tất cả mọi thứ bởi vì đó là nhiệm vụ bất khả thi. Thay vì vậy, bạn nên tập trung học những gì bạn cần biết và xây dựng cho mình các kĩ năng giúp bạn học hỏi nhanh hơn.

10. Phương pháp thực hiện tốt nhất tùy thuộc vào từng tình huống

Liệu phát triển phần mềm theo hướng kiểm thử (Test Driven Development – TDD) có phải là phương pháp tốt nhất?

Liệu chúng ta nên luôn luôn áp dụng lập trình theo cặp (pair program).

Bạn sẽ chẳng là gì nếu bạn không sử dụng IoC?

Câu trả lời cho tất cả những câu hỏi trên là “Nó phụ thuộc”.

Nó phụ thuộc vào từng tình huống.

Mọi người luôn cố gắng đưa ra cách làm tốt nhất. Họ sẽ nói với bạn rằng họ luôn làm vậy và bạn cũng nên làm theo. Nhưng điều đó đơn giản là không đúng.

Tôi làm theo rất nhiều phương pháp khi tôi lập trình, nhưng tôi cũng không làm theo vô điều kiện.

Các nguyên tắc là bất di bất dịch nhưng phương pháp thực hiện luôn thay đổi tùy theo tình huống.

11. Luôn hướng đến sự đơn giản

Tất cả các vấn đề đều có thể được chia nhỏ.

Giải pháp hiệu quả nhất thường lại là giải pháp đơn giản nhất.

Nhưng sự đơn giản không phải dễ dàng mà có. Bạn phải lao động để có được nó.

Mục đích của blog này nhằm đề cập đến sự phức tạp trong phát triển phần mềm, cũng như cuộc sống nói chung, và làm cho chúng trở nên dơn giản hơn.

Có lẽ bạn cũng như tôi đều thấy rằng đó không phải là một nhiệm vụ dễ dàng.

Bất kì gã ngốc nào đều có thẻ tạo ra một giải pháp phức tạp cho một vấn đề. Sẽ tốn nhiều công sức và thời gian để thay đổi một giải pháp nhằm giúp nó trở nên đơn giản hơn mà vẫn chính xác.

Hãy dành thời gian. Hãy nỗ lực hết mức. Và hướng đến sự đơn giản.

Những nguyên tắc của bạn là gì?

Trên đây là những nguyên tắc của tôi. Thế còn bạn thì sao?

Những nguyên tắc của cá nhân bạn là gì?

Bạn nghĩ cái gì là quan trọng, đáng để ghi nhớ hàng ngày?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s