7 thói quen đơn giản của 1% kỹ sư hàng đầu
(engineercodex.substack.com)- "Cách các coder ưu tú thể hiện năng lực vượt trội hơn những coder khác"
Hãy là kỹ sư, đừng chỉ là coder (Be an engineer, not a coder)
- Kỹ thuật là giải quyết vấn đề
- Những kỹ sư giỏi nhất xem code là phương tiện để đạt được mục tiêu
- Viết code có niềm vui riêng, nhưng viết code không có mục đích thì không có nhiều ý nghĩa. Thay vào đó, code được dùng để thiết kế giải pháp cho người dùng
- Việc coding theo đuổi sự sáng tạo! Sự sáng tạo thường nảy sinh dưới các ràng buộc. Khi thêm vào "ràng buộc" là một vấn đề rõ ràng cần giải quyết, kỹ sư sẽ có tự do khám phá và tạo ra giải pháp theo cách mà họ cho là phù hợp
- Những kỹ sư giỏi nhất có tư duy lấy sản phẩm làm trung tâm và trên hết luôn ưu tiên giải quyết vấn đề cho con người, điều này dẫn đến bước tiếp theo
Viết code cho con người, không phải cho máy tính (Code for the human, not the computer)
"Bất kỳ kẻ ngốc nào cũng có thể viết code mà máy tính hiểu được. Lập trình viên giỏi viết code mà con người có thể hiểu được." - Martin Fowler
- Code không chỉ dành cho máy tính mà còn dành cho con người
- Code là để cho các kỹ sư cùng nhóm đọc, bảo trì và xây dựng tiếp trên đó
- Code là dành cho người dùng, dù đó là một đứa trẻ dùng điện thoại, một nhà phát triển gọi API hay chính bạn
- Những kỹ sư giỏi nhất luôn đánh giá giá trị của code cho mọi loại người dùng
- Nếu code đó không làm hài lòng dù chỉ một nhóm khách hàng, nó sẽ không được đưa vào production
Tách mình khỏi chính đoạn code (Detach from the code itself)
- Kỹ sư xuất sắc không bám chấp vào bản thân đoạn code
- Họ không sợ xóa đi cả phần code đã hoàn thành khoảng 90% và làm lại nếu điều đó giúp kết quả cuối cùng tốt hơn về tổng thể
- Họ tích cực đón nhận phản hồi vì code không phải là thứ mang tính cá nhân
- Code không hoàn hảo. Không ai quan tâm đến code hoàn hảo. Người ta chỉ quan tâm đến code tạo ra thay đổi
- Cách tốt nhất để tự rèn mình không bám chấp vào code là "nhận ra rằng sau 20 năm, phần lớn code của bạn rất có thể sẽ trở thành technical debt, không còn được dùng nữa hoặc bị viết lại"
Sử dụng các tiêu chuẩn nhất quán (Use consistent standards)
- Khi viết code, hãy tuân thủ các tiêu chuẩn và phong cách coding nhất quán
- Giữ được tính nhất quán (consistency) sẽ giúp cả bạn trong tương lai lẫn đồng đội đọc và hiểu code dễ hơn
- Dùng một style guide nhất quán cũng giúp mở rộng cả team lẫn codebase dễ hơn
- Đây là cách các công ty như Meta/Google có thể triển khai rất nhiều code nhanh chóng mà không khiến codebase trở nên không thể đọc hay bảo trì theo thời gian
- Mọi công ty đạt hiệu suất cao đều đã nội tại hóa style guide, hiểu lợi ích của chúng và tuân theo nhiều nhất có thể
- Google đã open source một số style guide của mình
- Meta có C++ style guide trong một phần open source của họ
- Mẹo: dành thời gian thiết lập Linter để formatting cho team của bạn chắc chắn là xứng đáng
Viết code đơn giản (Write simple code)
- Mọi kỹ sư ưu tú mà tôi biết có thể đã tạo ra thứ gì đó phức tạp trong quá trình xây dựng, nhưng kết quả cuối cùng luôn là code dễ đọc và dễ hiểu
- Cách diễn đạt hay nhất của tôi về điều này là code của họ "thỏa mãn về mặt thẩm mỹ"
- Code của họ sạch sẽ, có tổ chức và logic (clean, organized, and logical)
- Mỗi quyết định đưa ra trong code đều có ý nghĩa, và nếu không thì nó được ghi chú rất rõ trong code
- Một cách tốt để viết clean code là tuân theo các nguyên tắc như SOLID. Ban đầu chúng được thiết kế với OOP (lập trình hướng đối tượng) trong đầu, nhưng có thể mở rộng sang lập trình nói chung
- Single Responsibility: một class chỉ nên có một trách nhiệm
- Open-Closed: các đối tượng phần mềm (class, module, v.v.) nên mở với việc mở rộng nhưng đóng với việc sửa đổi để tạo ra code dễ dự đoán và dễ bảo trì
- Liskov Substitution: kiểu con phải có thể thay thế kiểu cha mà không làm ảnh hưởng đến tính đúng đắn của chương trình
- Interface Segregation: code không nên phụ thuộc vào một interface khổng lồ mà nó không dùng hết. Thay vào đó, package nên được phép chứa và import các interface nhỏ hơn, cụ thể hơn
- Dependency Inversion: module cấp cao không nên phụ thuộc vào module cấp thấp; cả hai nên phụ thuộc vào abstraction để thúc đẩy thiết kế hệ thống linh hoạt và tách rời hơn
- Một ví dụ là việc đặt tên (Naming): tên tốt không chứa giá trị ma thuật, có sự phân biệt rõ ràng, thể hiện tên hàm mang tính mô tả và các biến dễ hiểu
Không cho phép điều bất ngờ xảy ra (Don’t allow surprises)
- Code không nên tạo ra kết quả ngoài dự kiến. Điều này có thể đạt được bằng cách tuân theo các nguyên tắc code và viết test phù hợp
- Code tốt là code có thể dự đoán được
- Test củng cố tính rõ ràng và khả năng dự đoán của code, đồng thời mang lại sự tự tin. Với các test tự động chất lượng cao, team có thể thay đổi code mà không lo làm hỏng những phần mình không nhìn thấy
- Một vài loại test
- Unit test cho các component riêng lẻ và các hàm được cô lập
- Integration test cho sự tương tác giữa nhiều component
- End-to-end test để đánh giá chức năng của toàn bộ hệ thống từ góc nhìn người dùng
- Test nên đơn giản. Khi đọc một test thất bại, bạn phải dễ dàng nắm được điều gì đã sai
- Biết những gì không nên test cũng rất quan trọng
- Ví dụ, nếu công sức cho end-to-end test lớn hơn lợi ích thực tế của chương trình, test có thể được thay thế bằng tài liệu hóa cẩn thận, monitoring và gửi cảnh báo cho đúng người (ví dụ: code owner)
- Ngoài ra, test không nên kiểm tra các chi tiết triển khai trong code, chẳng hạn như kiểm tra một CSS selector cụ thể trong code frontend, hoặc chỉ dùng data attribute hay screenshot test
Giao tiếp thường xuyên (Communicate often)
- Một hệ thống tuyệt vời không được tạo ra một mình. Những kỹ sư giỏi luôn trải qua review thiết kế, chủ động xin phản hồi và liên tục lặp lại thiết kế ban đầu của code
- Kiến thức của ai cũng có những khoảng trống mà người khác có thể giúp lấp đầy. Góc nhìn mới thường giúp làm code rõ ràng hơn hoặc đưa ra cách tiếp cận mới mà trước đó bạn chưa nghĩ tới
- Những kỹ sư giỏi nhất coi trọng giao tiếp và hợp tác, không ngại dành thời gian làm việc cùng nhau để có được kết quả cuối tốt hơn
- Điều này có thể đơn giản như ping đồng đội để nhờ review nhanh tài liệu hoặc thêm reviewer cho một pull request quan trọng
Code nhanh... và chậm (Code fast… and slow)
- Những kỹ sư giỏi nhất mà tôi biết hoàn thành dự án rất nhanh, nhưng lại code rất chậm
- Nghe lạ đúng không?
- Tất cả các nguyên tắc và thói quen ở trên đều khiến giai đoạn đầu của việc coding tốn nhiều thời gian hơn. Nhưng chính nhờ chúng mà kỹ sư có thể đẩy dự án tiến lên từng bước vững chắc
- Bằng cách dành thời gian dùng tiêu chuẩn, test đúng cách, áp dụng nguyên tắc và giao tiếp thường xuyên, bạn sẽ tiết kiệm được nhiều thời gian hơn về lâu dài
- Tôi đã trực tiếp trải qua điều này khi còn là intern và junior engineer, và có lẽ nhiều kỹ sư khác cũng vậy: bạn có thể vội vàng tiến 3 bước rồi đâm vào chướng ngại và phải lùi lại 5 bước
Đừng mù quáng làm theo quy tắc (Don’t follow rules blindly)
- Những "quy tắc" và "nguyên tắc" ở trên chỉ là các guideline đơn giản. Không phải lúc nào mọi thứ cũng khớp gọn gàng với guideline
- Đôi khi đoạn code bạn đang viết có thể là một hình vuông không chui vừa hình tròn, và điều đó không sao cả
- Trong trường hợp đó, hãy tài liệu hóa lý do vì sao code được viết theo cách cụ thể đó
- Nếu không, một ai đó trong tương lai như chính bạn sau này có thể nhìn vào code và nghĩ: "Wow, hồi đó mình ngốc thật. Sao cái này lại không theo tiêu chuẩn của bọn mình nhỉ?"
- Rồi họ sẽ tốn 20 giờ để viết lại cho đúng chuẩn chỉ để đi đến cùng một kết luận như trước
- Thực tế của phát triển phần mềm là không phải mọi đoạn code đều sạch sẽ hay tuân thủ quy tắc một cách hoàn hảo
- Nhưng code nhất quán, sạch sẽ, dễ hiểu, có thể test và có giá trị thì hoàn toàn có thể tồn tại
- Một vài mẫu hình khác tôi nhận thấy ở những kỹ sư giỏi nhất
- Có kiến thức domain sâu ở ít nhất một lĩnh vực. Tất cả các kỹ sư tôi từng ghi nhận đều tập trung vào một lĩnh vực cụ thể như hạ tầng frontend, hệ thống phân tán, UI sạch, v.v., và trở thành chuyên gia nên hiện giờ họ đang ở vị trí hàng đầu trong lĩnh vực đó
- Thường xuyên và đúng cách tự marketing bản thân. Những kỹ sư này không ẩn mình ở nơi khó thấy. Mọi người làm việc cùng họ trong team đều biết giá trị và chuyên môn của họ, và đó là kết quả của việc tự marketing hợp lý cùng với thực hiện những dự án có tầm ảnh hưởng
11 bình luận
Tôi đã có được những góc nhìn rất hay. Cảm ơn nhé :)
Bài viết hay đấy!
Kỹ thuật cũng quan trọng, nhưng điều quan trọng vẫn là tạo ra những sản phẩm thực sự mang lại lợi ích cho con người, điều này lại một lần nữa khiến mình phải suy ngẫm!!!
Cảm ơn bạn vì bài viết hay!
Hóa ra là 7 thói quen, nhưng nội dung lại thành 9 cái nhỉ lol
Tôi cũng đã đếm thử rồi.. hình như cái ở cuối với cái ở đầu chỉ là tiêu đề thôi! haha
Ồ, bài viết hay và phần lớn đều thấy đồng cảm haha
Nội dung đỉnh nhất từ trước đến nay trong số những bài viết kiểu này mà tôi từng xem.
Nếu khái quát hóa thêm một chút thì đây là một bài viết hay, hữu ích cho mọi người.
Đến mức này thì cảm giác không còn là tóm tắt mà gần như là bản dịch rồi... Dù vậy vẫn rất cảm ơn vì phần tóm tắt.
Đây đúng là bài viết đáng để thỉnh thoảng đọc lại.
Đúng là vậy thật haha, tôi cũng định để đó đọc đi đọc lại.