Softech Aptech | Những mánh khoé “không bao giờ tiết lộ” của các lập trình viên vĩ đại

Chuyên mụcHoạt động
Lượt xem813,454
Cập nhật26/09/2019

NHỮNG MÁNH KHOÉ “KHÔNG BAO GIỜ TIẾT LỘ” CỦA CÁC LẬP TRÌNH VIÊN VĨ ĐẠI

Mánh khóe thứ nhất: Không bao giờ truyền dạy các “mánh khóe” này cho người khác. Hết bài.

Đùa đấy, các bạn đừng gạch đá mình tội nghiệp, mình buồn. Chẳng là dạo này mình chán stackoverflow, chuyển qua quora nghịch ngợm đôi chút. Đây cũng là một trang web hỏi đáp tương tự như stackoverflow, nhưng phạm vi rộng hơn rất nhiều, bao gồm toàn bộ mọi lĩnh vực đời sống.

Một điểm đặc biệt nữa là nó cho phép hỏi những câu chung chung hoặc “nhảm nhí”, do đó có rất nhiều câu hỏi – trả lời thú vị và “bá đạo” như: Mac Zuckerberg có giỏi PHP hay không? Tại sao người đời lại ghét sản phẩm của Apple? Làm sao nghe lén điện thoại bạn gái?… đủ thứ trên trời dưới đất.

Mình khuyên các bạn nên bỏ đi ít thời gian cho facebook, rảnh rỗi thì lên đây xem các câu hỏi về Computer Science/Computer Programming, sẽ học được nhiều điều thú vị lắm, giải trí cũng tốt nữa. Bài viết này là tổng hợp và chọn lọc những ý tưởng, câu trả lời hay của câu hỏi: What are the best-kept secrets of great programmers? – Những mánh khóe “không bao giờ tiết lộ” của các lập trình viên vĩ đại.

Mánh khóe code và test

Trong đa phần các trường hợp, sử dụng inheritance (kế thừa) là một design TỆ, làm cho code khó test và khó bảo trì. Hãy chuyển qua composition (sở hữu) và kết hợp với interface. (Có thể đọc thêm vềprefer composition over inheritance).
Đừng sử dụng interface cho tới khi bạn hoàn toàn rõ ràng về domain của chương trình. (Mỗi khi cần thêm 1 function, bạn sẽ phải thêm nó vào interface và implement của interface đó, gấp đôi công sức).
Bảo mật/mã hóa rất khó. Đừng tự làm MÀ hãy tái sử dụng (sử dụng thư viện, thuật toán có sẵn v…v), trừ khi bạn biết rõ mình đang làm gì.
Có vô vàn nguyên nhân làm crash một chương trình: deploy sai cách, input bị lỗi, người dùng dùng sai cách, quá tải … Chuẩn bị sẵn sàng cho những điều đó: Ghi log những exception gặp phải, deploy thử lên server test, đặt giới hạn cho bộ nhớ…
Kết nối mạng (HTTP, socket) rất dễ xảy ra vấn đề. Luôn nhớ đặt timeout cho các kết nối này, sử dụng thư viện để wrap chúng, retry nếu kết nối có vấn đề.
Mỗi dòng code thêm vào sẽ làm chương trình phức tạp thêm một chút, tăng khả năng có bug. Bỏ bớt code là cách hay nhất để giảm bớt số lượng bug =))).
Validate những thứ người dùng nhập vào, vừa đảm bảo tính bảo mật, lại hạn chế được bug.
Tái sử dụng code chưa chắc đã khiến code của bạn dễ bảo trì hơn. Tái sử dụng code giữa 2 domain khác nhau có thể làm chúng “dính chặt” với nhau hơn.
Chỉ test những thứ cần test, test ít thì dễ sót bug, test nhiều thì sẽ mất thời gian và tốn công update test case mỗi khi đổi requirement.
Mỗi khi commit code, hãy giữ số lượng code nhỏ, code chạy được, viết message rõ ràng bao gồm thứ bạn đã làm và lý do bạn làm thứ đó.
Với kiến trúc tốt, bạn vẫn có thể viết code lô. Tuy nhiên, với kiến trúc tốt, bạn có thể dễ dàng nâng cấp, thay thế phần code đểu đó. Tập trung xây dựng kiến trúc tốt, ít móc nối trước, về sau sẽ dễ thở hơn.
Code để lâu cũng rất dễ hư hỏng, do đó cần được refactor thường xuyên. Tuy nhiên cần tránh refactor code quá độ.

Mánh khóe làm việc

Rất khó để ước đoán thời gian cần làm để hoàn thành một module/dự án, đó là lý do người ta dùng Scrum.
Viết code để cho chính mình và người khác đọc. Thêm comment để giải thích “Vì sao”, thêm comment ở những nơi mà bạn nghĩ 1 năm sau bạn đọc code sẽ không hiểu gì.
Hiểu rõ thư viện/framework mà mình sử dụng, đừng có gắng viết lại từ đầu những thứ người khác đã tốn công viết rồi.
Cài đặt để việc build một project diễn ra nhanh chóng tiện lợi nhất có thể. Hãy chắc chắn bạn có thể build bằng command line, sẽ rất có ích (Có thể kích hoạt build từ xa, hoặc đưa project lên CI chẳng hạn).
Hiểu rõ những tool bạn sử dụng (IDE, source control, build tool, Photoshop). Cố gắng tìm hiểu và làm quen với việc dùng các hotkey, hạn chế dùng chuột. Bạn sẽ làm việc nhanh hơn và “pro” hơn.
Ngồi lâu rất có hại. Hãy tập một số thói quen để đảm bảo sức khỏe khi làm việc: Không ngồi nhiều, lâu lâu cho mắt nghỉ ngơi, sắp xếp bàn làm việc, bàn phím, chuột sao cho làm việc thoải mái…
Đừng áp dụng lung tung các framework/process/pattern vào dự án để “thể hiện”. Không phải lúc nào Test-Driven Development cũng tốt, không phải lúc nào cũng nên áp dụng DI/IoC.