Jonathan Blow là một lập trình viên dạng “khủng”. Khó mà tưởng tượng nổi năng suất làm việc của Jonathan. Anh ta là một lập trình viên phát triển game độc lập. Để làm được những dự án độc lập kiểu này bạn phải có năng suất làm việc gấp khoảng chục lần mức trung bình. Hơn nữa code của game phải rất chuẩn chỉ. Khi render ở tốc độ 60 frame trên một giây thì chỉ cần một sự rò rỉ bộ nhớ cực nhỏ ở một frame cũng có thể gây ra crash game sau vài giờ chơi.
Không những một tay dựng lên các game project với một lượng lớn source code cùng nội dung kèm theo, Jonathan còn đang phát triển một ngôn ngữ lập trình mới!
Làm thế nào Jonathan đạt được năng suất làm việc khủng khiếp như vậy? Sau đây là 5 bí quyết mà Jonathan chia sẻ với LTV chúng ta.
1. Đừng có tối ưu
Sự thôi thúc để tối ưu code thường đến quá sớm. Những giải pháp “thông minh” để tăng performance sẽ chỉ làm tăng độ phức tạp và làm phá sản mục tiêu cuối cùng. Hãy làm cho code chạy đã! Việc tối ưu cứ để sau, khi nào cần thiết.
2. Hãy tối ưu hướng tới sự giản đơn
Bạn có thể tối ưu cho thời gian chạy. Bạn có thể tối ưu cho không gian lưu trữ. Nhưng điều quan trọng nhất bạn nên tối ưu là cho thời gian của chính bạn. Hãy tối ưu code để nó dễ đọc, dễ hiểu. Nếu bạn phải dừng code và tự hỏi, “cái này làm việc thế éo nào nhỉ?” hay “tại sao nó lại không làm cái mà nó cần làm?” – thì tức là bạn vừa lãng phí thời gian của chính mình.
3. Các kiến thức Khoa học máy tính mang tính học thuật và “thú vị” là không thực tế
Cần phải sử dụng một cách cẩn trọng các phương pháp từ môn Khoa học máy tính trong trường học. Nhiều phương pháp được mô tả trong sách kinh viện được tối ưu sâu cho một trường hợp cụ thể. Không phải tất cả đều không thực tế, tuy nhiên lợi ích của chúng thường được thổi phồng lên. Và nếu như bạn sử dụng những phương pháp đó, bạn có thể nhận ra là lợi ích mang lại không bù đắp nổi chi phí bỏ ra.
4. Những sự trừu tượng hóa đơn giản nhất thường là tốt nhất
Kẻ thù thực sự của năng suất chính là tâm trí của LTV. Càng nhiều suy nghĩ chất chứa trong đầu, thì năng suất càng giảm. Vì thế sự phức tạp chính là kẻ thù. Hãy dùng các giải pháp đơn giản nhất có thể. Hãy đề cập nhiều hơn đến việc lặp qua mảng thay vì các cấu trúc dữ liệu thông minh. Nếu bạn có thể để tất cả mọi thứ vào trong đầu, bạn sẽ nhanh hơn. Bạn sẽ không thể cho hết mọi thứ vào đầu nếu có hàng đống thứ phức tạp.
Bình loạn: Tôi nghĩ là có nhiều LTV mới vào nghề thích sử dụng các cấu trúc dữ liệu “cao cấp” và các tính năng ngôn ngữ “nâng cao” để thể hiện khả năng. Tôi gọi đó là hội chứng “huấn luyện viên sư tử” (*). Những sự thể hiện như vậy có vẻ ấn tượng, nhưng trừ khi chúng chuyển thành thắng lợi cho dự án, bạn hãy tránh xa!
Với mỗi class/method thêm vào trong code, độ phức tạp có thể tăng không phải tuyến tính mà là cấp số mũ. Xóa code, do đó, luôn tốt hơn là thêm code vào. Đừng đưa code vào function khi mà chúng có thể để inline.
5. Đừng viết code tổng quát hóa
Các đoạn code tổng quát hóa quá mức mềm dẻo quá mức thường là lãng phí thời gian. Chúng thường khó để maintain và là nguồn gốc của các bug tiềm tàng. Hardcode thực ra cũng không tệ nếu code của bạn chỉ làm một thứ duy nhất.
Hy vọng với những bí kíp quý giá trên đây, các bạn có thể vận dụng vào công việc của bản thân để công lực coding ngày càng thâm hậu.
(*) hội chứng huấn luyện viên sư tử: người huấn luyện sư tử thường dùng ghế để chỉ vào con sư tử, đó không phải vì sư tử sợ cái ghế, mà cũng giống như chúng ta, nó bị choáng ngợp bởi quá nhiều thông tin. Nó cố để tập trung vào cả 4 cái chân ghế, nhưng mà nó không thể. Do đó mà nó sẽ bị giảm năng suất (năng suất ở đây là ăn thịt được nhiều huấn luyện viên!)
Các bạn có thể xem thêm bài gốc ở đây
Đam mê Code 