"Bây giờ cái gì cũng có trên mạng. Library và source code đầy rẫy. Thay vì tự suy nghĩ và tự code thì chỉ cần cop về. Thế là mất gốc".
Dù đang là một ngành nghề có thu nhập và cơ hội việc làm đảm bảo, nghề code cũng không phải là miễn nhiễm với những lời chỉ trích. "Coder bây giờ lười và thích ăn sẵn" là một trong những lời chỉ trích đó. Đi dạo quanh các diễn đàn code, trò chuyện với các nhà quản lý hay các lão làng kỳ cựu, bạn có thể bắt gặp những lời chỉ trích dạng như: "Bây giờ cái gì cũng có trên mạng. Library và source code đầy rẫy. Thay vì tự suy nghĩ và tự code thì chỉ cần cop về. Thế là mất gốc".
Đã đến lúc chúng ta cần suy nghĩ lại về tư tưởng nghề nghiệp của mình.
"Ăn sẵn" là bắt buộc
Một trong những bước đột phá từ lập trình tuần tự (procedural) lên hướng đối tượng (object-oriented) là khả năng tái sử dụng code một cách dễ dàng và khoa học. Thay vì phải copy lại một đoạn code khi bạn sử dụng một tính năng, bạn chỉ cần "gói" đoạn code sử dụng lại nhiều lần vào một hàm hoặc một class. Bất cứ khi nào bạn hoặc một người khác cần sử dụng tới đoạn code đó, người này sẽ không cần phải copy và paste (và sửa) mà chỉ cần gọi đến hàm bạn đã cung cấp qua API.
Tư tưởng cốt lõi ở đây là rất đơn giản: đừng bao giờ lặp lại những việc người khác (hoặc chính bạn) đã làm. Nếu bạn có nhiệm vụ tính toán và tổng hợp số liệu đã lấy lên từ database, trọng tâm của bạn là khâu xử lý số liệu chứ không phải là khâu lấy data từ DB. Một coder tốt luôn hiểu rằng các dự án phần mềm luôn luôn là những nỗ lực tập thể. Ôm đồm lấy tất cả mọi thứ không phải là ý kiến hay.
Việc đem library từ trên mạng hoặc thậm chí là copy code từ GitHub, từ StackOverflow cũng mang một bản chất tương tự. Khi thực hiện công việc code, bạn đều sẽ phải đối mặt với những đề bài hết sức rõ ràng (nếu không rõ thì phải hỏi lại PM, team lead, BA). Nhiệm vụ tối thượng của bạn là giải quyết đề bài ấy chứ không phải là tự nghĩ ra giải thuật tốt nhất, tự tạo library của riêng mình v...v...
Copy code thực chất đã trở thành một phần không thể thiếu của nghề code.
Đừng nghĩ điều này chỉ áp dụng với những library "đao to búa lớn" kiểu I/O, các framework đình đám hay các package/library bạn nhận được từ đồng nghiệp. Trong trường hợp đã có ai đó đã implement một function tương tự như những gì bạn cần mà bạn vẫn quyết tâm code lại từ đầu thay vì gọi đến hàm của người khác, hoặc trong trường hợp bạn cố chấp code lại những bài toán đã quá phổ biến trên GitHub, những vấn đề Google rất nhanh là ra... bạn thực sự đáng trách vì làm phí phạm thời gian sếp trả lương cho bạn.
"Ăn sẵn" có đầu óc
Nói như vậy không có nghĩa rằng một coder tốt chỉ có thể đem thành quả của người khác về sử dụng. Nếu bạn copy code, bạn vẫn phải biết cách đánh giá đoạn code đã copy về để tối ưu khi cần thiết. Tiếp đến, giữa một biển các thư viện và các đoạn mã nguồn mở đang có trên mạng, bạn cũng cần phải biết cách so sánh và đánh giá để chọn ra tùy chọn thích hợp nhất. Bất kỳ một coder nào cũng cần phải thành thục các kỹ năng, thao tác cần thiết để có thể thử nghiệm và so sánh các giải pháp sẵn có (refactor, debug, v...v...). Nếu thấy giải pháp sẵn có là không đủ yêu cầu, hiển nhiên bạn phải tự implement những gì bạn cần từ đầu.
Không biết copy code cũng đáng trách, mà copy code kiểu mù quáng cũng đáng trách.
Nhưng, nói đến kỹ năng copy code là nói đến cách copy có đầu óc, có chọn lọc và đánh giá.
Vậy, nếu đã bỏ công ra tìm hiểu sâu để tìm hiểu các giải pháp sẵn có thì tại sao không tự giải lấy bài toán ngay từ đầu? Câu trả lời nằm ở chỗ tự mình nghĩ ra một giải pháp và cải tiến một giải pháp có sẵn là hai phạm trù tách biệt, giống như là viết văn và phê bình văn học vậy. Trong phần lớn các trường hợp, cải tiến một giải pháp sẵn có sẽ vừa giúp tiết kiệm thời gian và chi phí, vừa giúp mang lại hiệu quả tốt nhất có thể
Dĩ nhiên, tất cả không có nghĩa rằng coder được quyền ngừng học hỏi. Nhưng câu hỏi bạn cần phải đặt ra là "ưu tiên học hỏi cái gì trước tiên?". Từ kinh nghiệm bản thân của tôi, một phần lớn hình ảnh và các đánh giá được đồng nghiệp dành cho bạn sau này sẽ nằm ở những gì bạn đang phải chịu trách nhiệm chứ không phải là những gì bạn có thể được giao phó trong tương lai. Điều này có nghĩa rằng bạn nên cân bằng giữa quá trình học hỏi giữa những công nghệ mới mẻ đang gây sốt và chính hệ thống bạn đang nắm. Trọng tâm của một coder được giao phó xử lý dữ liệu vẫn là xử lý dữ liệu chứ không phải là lấy data từ DB, nhưng tìm hiểu tất cả các thành phần hệ thống từ database cho đến tận front-end sẽ là một cách tốt để chứng minh năng lực trong tương lai.
Luôn luôn ghi nhớ một trong những tư tưởng cốt lõi của nghề phần mềm: Đánh giá kết quả, KHÔNG đánh giá quá trình.
Nói tóm lại, một coder giỏi phải là một người thích thử nghiệm, ham học hỏi, nhưng cũng phải là một người biết "ăn sẵn" khi cần. Nhiệm vụ tối thượng của một coder là đưa ra giải pháp chất lượng nhất, tiết kiệm thời gian nhất cho bài toán được giao phó. Quá trình giải bài toán ấy sẽ bao gồm cả những đoạn code do chính bạn nghĩ ra lẫn những gì bạn "ăn sẵn" từ người khác.