Ngày thứ 256 của năm – thường là ngày 13/9, hoặc 12/9 nếu là năm nhuận – được gọi là ngày Lập Trình Viên; đối với tôi, ngày này năm nay đặc biệt hơn một chút, vì nó đánh dấu 1/4 thế kỷ từ khi tôi bắt đầu lập trình trên máy tính.
Vài kinh nghiệm xương máu ghi lại đây, hi vọng 25 năm nữa nhìn lại sẽ vẫn thấy hợp lý.
Chú ý: tôi không chịu trách nhiệm gì nếu bạn áp dụng mà không thành công hay gây thiệt hại.
- Không có ngôn ngữ lập trình tốt nhất, chỉ có ngôn ngữ lập trình phù hợp nhất (cho một việc gì đó).
- Không thể học một ngôn ngữ lập trình trong vòng 24h, chỉ là bạn tưởng thế thôi.
- Lập trình giống như chơi thể thao, càng chơi nhiều và càng đam mê thì sẽ càng giỏi.
- Lập trình không giống chơi game, vì không thể cheat và không thể bỏ tiền mua rank.
- Lập trình nhiều ngôn ngữ khác nhau giúp bạn chóng giỏi hơn so với chỉ làm việc với một ngôn ngữ duy nhất.
- Ít khi xuất hiện một thứ gì hoàn toàn mới mẻ trong lập trình, những đặc tính hay ho của C++, Java, C#, Python,… thực ra đã xuất hiện từ rất lâu trước đó, đặc biệt là trong LISP và Smalltalk.
- Lập trình viên khá viết code nhiều, lập trình viên giỏi viết code hay, lập trình viên xuất sắc dùng code đã có, lập trình viên vĩ đại xóa code.
- Bảo trì mã khó và vất vả hơn rất nhiều so với viết mã mới.
- Các công cụ quản lý version là thứ phù phiếm, điều quan trọng là hãy backup mã hiện tại của bạn.
- Backup mã là một chuyện, Restore nó lại là chuyện khác.
- Lối viết mã là đặc trưng cho mỗi lập trình viên, nó luôn khác nhau với từng người, tuy phong cách có thể hao hao giống nhau.
- Muốn lập trình giỏi, nhất thiết phải hiểu rõ về hệ thống.
- Tối ưu mã là việc rất khó, và hoàn toàn khác với các lý thuyết về độ phức tạp tính toán hay độ phức tạp không gian nhớ.
- Trình độ càng cao, code viết càng dễ hiểu.
- Không có cách viết mã tốt nhất, chỉ có cách viết hợp lý nhất với từng tình huống.
- Lỗi là một phần của thế giới, nó xuất hiện ở khắp mọi nơi, hệ điều hành, thư viện, trình dịch,… thậm chí cả trong những đoạn ghi chú.
- Lỗi nên được ghi nhận một cách tự động, vì rất có thể lần sau nó không xảy ra nữa.
- Ngay cả tài liệu kỹ thuật cũng vẫn có thể sai, vì lập trình viên của các hãng lớn trình độ cũng làng nhàng thôi.
- Quan tâm đến kết quả, đừng quan tâm đến giải thích, ngay cả chuyên gia cũng thường giải thích sai, nhất là trên stackoverflow.
- Chương trình chạy được là lúc những rắc rối thật sự mới bắt đầu.
- Khi lựa chọn giải pháp, nhu cầu khách hàng là thứ duy nhất quan trọng, tất cả các loại chuẩn đều là thiên kiến (Linux bảo mật hơn Windows, Oracle nhanh hơn SQL Server, C++ nhanh hơn Java,…)
- Chương trình tốt không phải là chương trình không có lỗi, mà là chương trình hoạt động tốt ngay cả khi xảy ra nhiều lỗi.
- Sau một thời gian code, bạn sẽ gặp khủng hoảng vì code viết ra rất tệ, vượt qua giai đoạn này trình độ của bạn sẽ lên một đẳng cấp mới.
- Đừng bao giờ code chỉ để cho xong, rất có thể bạn chính là người phải đi dọn cái đống rác đó.
- Nếu gặp một đoạn code nào đó có lỗi mà bạn không thể sửa nổi, hãy thử xóa nó đi.
thầy ơi làm sao để học tốt C++ ạ, em chưa lập trình bao h ạ !
Em thưa thầy. Em chưa hiểu cái thứ 7 ạ
Em muốn làm 1 việc, nếu là lập trình viên khá, em sẽ code thêm, nếu lập trình viên giỏi sẽ sửa code cũ, lập trình viên vĩ đại xóa bớt code cũ (nhưng vẫn làm được việc đó ~ vậy mới khó)
Em thưa thầy. Em chưa hiểu cái thứ 6 ạ
Nếu em học ngôn ngữ LISP, em sẽ thấy nó đã có hầu hết mọi thứ của Python hoặc C++, Java. Nên nhớ LISP ra đời từ trước đó rất lâu.