Có một sự thật đớn đau ít người biết về nghề lập trình. Lập trình viên thường bỏ công sức để trau chuốt code của mình trở nên hoàn hảo mà quên 1 sự thật: Thứ quan trọng thật sự không phải là code, mà là sản phẩm. Biết được điều này, lập trình viên sẽ gia tăng hiệu suất làm việc, sản phẩm do anh ta làm ra cũng sẽ được coi trọng hơn

(Điều này chỉ đúng với các start-up, các project làm ra sản phẩm. Với các project outsource, code chính là sản phẩm, bọn Nhật nhiều khi review code rất kĩ, bắt lỗi tới từng câu lệnh, cách đặt tên biến. Tác giả là người nước ngoài chắc cũng không làm outsource nhiều nên không biết).

Code chỉ là công cụ

Công việc của developer chúng ta không phải là viết code, mà là sử dụng code để tạo ra phần mềm, với những chức năng mà người dùng mong muốn. Code là thứ giúp chúng ta thực hiện điều đó, nhưng xét cho cùng, nó chỉ là công cụ. Giống như công việc của thợ cắt tóc không phải là sử dụng kéo (kéo = code), công việc của họ là tạo ra thứ gì đó (một mái đầu đẹp) với cây kéo.

Tuy vậy, một số quy trình trong ngành phần mềm có thể làm ta lầm tưởng rằng code chính là sản phẩm. Vd, việc refactor code, có thể xem đó là 1 qui trình làm cho code tốt hơn, hoặc làm cho sản phẩm tốt hơn. Nhìn từ góc độ của khách hàng hoặc người quản lý, refactor code là một hành động vô bổ, còn có thể làm nảy sinh bug mới, tốn thời gian và công sức.

Sản phẩm chúng ta tạo ra (phần mềm) được đánh giá qua những gì người dùng nhìn thấy, chúng ta cần tự nhắc nhở mình điều này mỗi khi viết một dòng code. Nếu phần mềm nhàm chán, không đáp ứng đủ chức năng, người dùng sẽ éo thèm quan tâm đến những thứ đằng sau, toàn bộ những thứ đẹp đẽ tuyệt vời chúng ta làm trong code đều trở nên vô nghĩa.

Điều đó không có nghĩa là code hoàn toàn vô giá trị, có thể thoải mái thả nổi chất lượng. Những vấn đề như bảo mật, validation, khả năng chịu lỗi cần phải được giải quyết bằng cách code đúng cách, sử dụng đúng thư viện, đó cũng chính là công việc của lập trình viên chúng ta. Code chất lượng, dễ hiểu thì người khác sẽ review dễ dàng hơn (Theo mình, ý của tác giả ở đoạn này là: tuy khách hàng không quan tâm đến code của bạn, nhưng còn 1 số người khác như developer, technical lead  sẽ khá quan tâm đến nó).

Tập trung vào chức năng

Hãy tưởng tượng bạn đang ở trong một cuộc họp trực tiếp với khách hàng, hoặc product owner. Chúng ta báo cáo gì với họ? Chúng ta có nói rằng đã tạo được bao nhiêu class, viết được bao nhiêu dòng code ko? Hay chúng ta nói cho họ nghe về cách chúng ta sửa lỗi ứng dụng, script để deploy, hoặc ta thiết kế database như thế nào. Tiếc thay, câu trả lời thường là CÓ. Hãy nhìn mặt khách hàng lúc này, trông họ chan chán, ngu ngơ như con cá bơ, hoặc giả bộ gật gù chờ hết chuyện. Chúng ta đi vào quá nhiều chi tiết vô giá trị đối với khách hàng. Không phải học không biết, không hiểu, mà đơn giản là họ éo quan tâm (Ví dụ dễ thấy, nếu bạn nhận làm web quảng cáo cho 1 công ty, họ chỉ cần sản phẩm là 1 trang web kèm tên miền, họ không quan tâm bạn dùng PHP hay Java hay C#, bạn viết HTML4 hay HTML5, họ không biết, và có biết cũng không thèm quan tâm).

Hãy tượng tượng bạn có 1 đội designer trong công ty. Trong buổi họp, bạn phải nghe bọn designer lảm nhảm về photoshop, về việc tụi nó đã tạo layer thế nào, thiết kế gradient tương phản ra sao, tụi nó viết script xử lý ảnh như thế nào. Chúng ta éo quan tâm, chúng ta chỉ cần biết : Khi nào bọn mài design xong để tụi tao còn code.

Chúng ta nên tập trung vào chức năng khi báo cáo với khách hàng: chức năng tạo báo cáo đã xong, nhưng còn thiếu phần ABC; trang web đã hiển thị rõ đẹp trên di động, nhưng cần chỉnh sửa chút đỉnh trên tablet. Đây là những thông tin mà quản lý và khách hàng quan tâm, nó giúp họ hiểu rõ tiến độ của dự án, cho họ thêm thông tin trong việc lên kế hoạch

Mấy cái library vô dụng

Một câu hỏi đặt ra dành cho các bạn lập trình viên: Đã bao giờ các bạn chọn 1 library để sử dụng dựa trên source code của nó chưa? Mình thì chưa. Vd như mình cần tìm 1 library  hỗ trợ việc resize ảnh trong C#, mình sẽ google, sau đó xem library nào được nhiều người sử dụng nhất, chức năng có nhiều hay không, cách sử dụng có dễ hay không. Thứ mình quan tâm là gì, chính là sản phẩm, không phải code của thư viện đó. Nếu 1 thư viện được code rất có bài bản, áp dụng design pattern, interface, DI, nhưng mà chức năng chỉ có 1 chút, liệu bạn có chọn không? Câu trả lời đương nhiên là không.

Bạn thấy đấy, đến cả lập trình viên chúng ta còn không thèm quan tâm đến code của lập trình viên khác, làm sao bạn có thể đòi hỏi “lũ khách hàng” quan tâm đến code của mình.

Đúng, nhưng mà…

Vì không ai quan tâm đến code, chúng ta có quyền viết code ẩu cho xong chuyện. Không, hoàn toàn không phải. Code chất lượng thì sẽ cho ra sản phẩm chất lượng. Dù không ai quan tâm đến code, để giải quyết vấn đề ta vẫn phải dùng đến code. Quay lại chuyện cái kéo ở ban đầu, kéo bén hay kéo cùn thì đều cắt ra tóc được, nhưng xài kéo rỉ sét (code quá tệ) thì sẽ hại cả thợ lẫn người cắt. Công việc của lập trình viên chúng ta là chăm chút cho sản phẩm, không phải cho code. Hãy thử đặt mình vào vị trí của quản lý, hoặc khách hàng, tập trung vào chức năng, chứ không phải công cụ. Chức năng, chứ không phải code, mới là thứ mang lại giá trị thực sự cho sản phẩm ta làm ra.