Trường học có thể dạy bạn các công cụ, các ngôn ngữ lập trình, các nguyên lý, các mô hình, các kiến trúc, các phương pháp, các quy tắc, các kĩ năng… Họ cũng có thể cho bạn làm thử những dự án cá nhân, dự án nhóm, làm những nghiên cứu hoặc khảo sát. Nhưng có một vài thứ trường học sẽ không thể dạy bạn. Không phải vì họ không biết, mà vì các lập trình viên cần nhiều năm để học những bài học này.
Tôi sẽ trình bày vài thứ như vậy dưới đây, đúc rút từ gần 30 năm theo nghiệp code và hàng nghìn vấn đề gặp phải trong quá trình phát triển sản phẩm.
Đừng phát minh lại bánh xe (Don’t reinvent the wheel)
Nghe có vẻ hiển nhiên, nhưng rất nhiều lập trình viên sẽ phát triển một cái gì đó mà thậm chí không cần tìm kiếm trên google, họ đơn giản nghĩ vấn đề này khá cụ thể, không có sẵn thư viện. Trong thực tế, bạn sẽ thường thấy rằng có những thư viện mã nguồn mở ngoài kia cho những gì bạn cần. Các thư viện đã được nhiều người kiểm tra và sửa lỗi trong nhiều năm, chất lượng mã thường sẽ rất tốt. Hãy nhớ: Công việc của bạn không phải là viết mã, mà là giải quyết vấn đề. Vì vậy, hãy tìm kiếm giải pháp trước khi viết bất kỳ cái gì.
Đừng lặp lại chính mình (DRY – Don’t Repeat Yourself)
Nếu bạn phải làm một việc gì đó nhiều lần, hãy cố gắng giảm thiểu khối lượng công việc mỗi lần.
Giả sử bạn sẽ viết 100 nhiệm vụ trong trò chơi nhập vai của mình. Hãy dành vài ngày đầu tiên để viết một khung (framework). Nhớ kỹ: mỗi nhiệm vụ chỉ nên có 1 hoặc 2 dòng mã.
Một ví dụ khác rất thường gặp: một ứng dụng web trong đó mọi phương thức khác đều mở kết nối cơ sở dữ liệu, tạo một câu lệnh, lặp qua tập kết quả, tất cả được gói gọn trong lệnh try và catch để đóng tài nguyên. Thay vào đó, hãy sử dụng AOP hoặc một khung như spring data để giảm khối lượng mã xuống còn 1 dòng hoặc ít hơn.
Tự động hóa các tác vụ lặp lại
Khi bạn phát triển phần mềm, bạn sẽ biên dịch, kiểm tra, đóng gói trong trình cài đặt, triển khai trong máy chủ, tạo thẻ trong hệ thống kiểm soát phiên bản của bạn,… Bạn sẽ làm điều này hàng trăm lần. Thiết lập quy trình trên github actions flow (hoặc công cụ tương tự) sẽ theo dõi hệ thống kiểm soát phiên bản của bạn, kiểm tra, xây dựng, chạy thử nghiệm đơn vị, đóng gói mã của bạn, triển khai mã ở bất kỳ nơi nào cần đến, gửi email cho bất kỳ ai cần được thông báo,… Điều này sẽ giúp việc hàng ngày của bạn chỉ đơn giản là viết mã và gửi lên repos, mọi thứ khác diễn ra mà không cần can thiệp trực tiếp. Hãy tìm hiểu về CI/CD sớm nhất có thể.
Bạn sẽ không cần nó đâu (YAGNI – You ain’t going to need it)
Trong quá trình phát triển, rất thường xuyên, ai đó sẽ yêu cầu: “chúng ta nên phát triển tính năng X vì có thể chúng ta sẽ cần nó sau này”. Chủ đầu tư sẽ thường xuyên yêu cầu thêm tính năng cho sản phẩm, và họ sẽ quên mất tính năng này sau vài ngày. Có khả năng là “sau này” sẽ không bao giờ đến. Hơn nữa, nếu bạn phát triển X ngay bây giờ hoặc sau này thì thường sẽ mất cùng một khoảng thời gian. Bằng cách hoãn X, bạn có thể tập trung vào các tính năng mang lại giá trị được yêu cầu ngay bây giờ và cung cấp chúng nhanh hơn.
Sử dụng các công cụ thích hợp cho công việc
Một số nhà phát triển cho rằng ngôn ngữ không quan trọng. Tôi hoàn toàn đồng ý. Một số ngôn ngữ tốt hơn ở một số nhiệm vụ so với những ngôn ngữ khác. Ví dụ, bạn muốn phân tích tệp apache log để tìm các yêu cầu thường xuyên đến trang web của mình. Bạn có thể viết chương trình C 200–300 LOC để thực hiện việc đó hoặc bạn có thể viết 1 dòng AWK và nhận được câu trả lời ngay lập tức.
Nhắc lại, việc của bạn là giải quyết vấn đề, không phải là viết mã hay chứng minh bạn thành thạo một ngôn ngữ nào đó.
Đừng tối ưu hóa sớm
Trước tiên, hãy viết mã đơn giản nhất có thể giải quyết được vấn đề. Mã đó phải ngắn gọn, dễ hiểu và chính xác, đừng lo lắng nếu nó không hiệu quả. Sau khi bạn bắt đầu sử dụng chương trình, nếu nó đủ nhanh, bạn đã hoàn thành. Nếu nó chậm, hãy sử dụng các công cụ profiler và tìm ra các nút thắt sau đó giải quyết chúng, nhớ rằng chỉ giải quyết các nút thắt mà thôi.
Làm test trước, thường xuyên bổ sung chúng
Bạn nên viết một vài test trước khi viết bất kỳ dòng mã nào. Sử dụng các công cụ như Jasmine hoặc JUnit chẳng hạn. Tất nhiên test sẽ hỏng vì bạn chưa viết mã, nhưng nó giúp bạn hình dung tốt hơn nhiệm vụ cần giải quyết. Sau khi bạn viết mã và vượt qua các bài test, nhận được dấu kiểm màu xanh lá cây, bạn biết mình đã hoàn thành phần nhiệm vụ này, và viết một bài kiểm tra khác cho phần tiếp theo.
Các test sẽ tồn tại mãi mãi với mã của bạn, nó được tích lũy thành một bộ các bài kiểm tra và bạn sẽ chạy tất cả chúng tự động nhiều lần với mọi thay đổi. Theo cách này, bạn sẽ nhanh chóng phát hiện ra lỗi khi bạn thay đổi điều gì đó.
Tái cấu trúc liên tục
Khi bạn viết nhiều mã hơn, bạn sẽ nghĩ ra những cách tốt hơn để làm một việc gì đó. Đừng ngại quay lại và thay đổi mã trước đó để làm cho nó dễ đọc và có thể sử dụng lại hơn. Khi tôi xem công cụ kiểm soát phiên bản của mình, tôi xóa nhiều mã hơn là thêm vào.
Nếu bạn có một bộ kiểm tra xác thực các hàm hiện có (xem phần trước), bạn có thể chạy lại chúng để đảm bảo quá trình tái cấu trúc của bạn không làm hỏng thứ gì đó.
Hãy tạo một “sản phẩm khả thi tối thiểu (MVP – Minimal Viable Product)
Đây là một khái niệm khó nắm bắt, ngay cả đối với các lập trình viên lâu năm.
Giả sử có người thuê bạn xây nhà. Bạn xây móng, kết cấu gỗ, mái, hệ thống ống nước, chạy dây, tường,… có thể mất 3–6 tháng để hoàn thành. Trong khi đó, khách hàng đang ở khách sạn. Anh ta không thấy giá trị nào cho đến khi ngôi nhà hoàn thiện và sẵn sàng. Chủ nhà có thể xem xét công trình thường xuyên để đảm bảo mọi thứ được xây dựng theo đúng thông số kỹ thuật của mình, nhưng cuộc sống của anh ta không khá hơn cho đến 6 tháng sau khi anh ta chuyển đến. Điều gì xảy ra khi anh ta chuyển đến và nhận ra phòng tắm quá xa phòng của mình? Bạn phải giải quyết nó, sẽ mệt đấy!
Phần mềm thì khác, bạn có thể thay đổi mọi thứ. Bạn có thể chỉ cần dựng một nơi trú ẩn với một số thanh gỗ vào ngày đầu tiên. Khách hàng có thể thử ngay. Có thể anh ta phàn nàn rằng nó quá nhỏ và anh ta phải chui vào. Bạn có thể thêm tường bùn sau vài ngày và biến nơi trú ẩn thành một túp lều. Khách hàng tiếp tục phản hồi cho bạn, có thể anh ta lạnh vào ban đêm. Bạn sửa đổi túp lều và thêm lò sưởi. Bây giờ chủ nhà nghĩ rằng nó quá tối và anh ta không thể đọc. Bạn thêm một số ngọn nến, v.v… Bạn tiếp tục thêm và thay đổi mọi thứ dựa trên phản hồi. Cuối cùng, bạn có thể biến nơi trú ẩn nhỏ đó thành một biệt thự 3 tầng.
Mô hình này tốt hơn nhiều cho phần mềm.
- Khách hàng nhận được giá trị ngay lập tức, ngay cả khi họ không cảm thấy thoải mái lắm lúc đầu.
- Bạn cho phép khách hàng thay đổi quyết định.
- Anh ấy sẽ có được một ngôi nhà đáp ứng nhu cầu của mình tốt hơn ngôi nhà ban đầu đã định.
- Ngay cả khi dự án bị hủy bỏ giữa chừng, bạn vẫn mang lại một số giá trị
- Khách hàng thực sự hài lòng, họ trở thành một phần trung tâm của quá trình phát triển và có được ngôi nhà đáp ứng được nhu cầu của mình.
Bình luận mới