12/08/2018, 16:36

Từ lập trình viên 10x tới lập trình viên 0.1x: tối ưu hoá bằng cách giản lược

Bạn chắc hẳn đã nghe kể về những lập trình viên 10x trong huyền thoại, những người có năng suất lao động gấp 10 lần người bình thường. Nếu bạn muốn trở thành một lập trình viên giỏi hơn, những huyền thoại này có thể khiến bạn trở nên mất tinh thần, nhưng thực chất họ cũng không hẳn là một hình ...

Bạn chắc hẳn đã nghe kể về những lập trình viên 10x trong huyền thoại, những người có năng suất lao động gấp 10 lần người bình thường. Nếu bạn muốn trở thành một lập trình viên giỏi hơn, những huyền thoại này có thể khiến bạn trở nên mất tinh thần, nhưng thực chất họ cũng không hẳn là một hình tượng hữu ích: làm thế nào để bạn có thể code nhiều gấp mười lần? Trong khi đó lại có một khái niệm hữu hiệu hơn nhiều về lập trình viên 0.1x: bất cứ ai cũng có thể lựa chọn việc code chỉ tương đương 10% so với một lập trình viên bình thường. Và đó là điều khả thi.

Đương nhiên việc code ít lại nghe có vẻ có vấn đề, vì vậy hãy cùng định nghĩa lại một chút. Liệu bạn có thể chỉ với 10% số dòng code như bây giờ mà tạo ra được sản phẩm vẫn chạy như cũ, với một lượng lỗi tương đương và số lượng tính năng không thay đổi? Câu trả lời có thể vẫn là không, nhưng ít ra đây là một mục tiêu mà bạn có thể phấn đấu được.

Tăng năng suất bằng cách giảm lượng code

Làm thế nào để có thể giữ nguyên chất lượng sản phẩm khi giảm lượng code?

Sử dụng ngôn ngữ lập trình cao cấp hơn

Hoá ra rất nhiều người trong số chúng ta đã trở thành lập trình viên 0.1x mà không cần phải cố gắng khi được so sánh với lập trình viên thế hệ cũ, những người bị gò bó với những ngôn ngữ lập trình cấp thấp.

Nếu như bạn không phải lo lắng về việc quản lý bộ nhớ thủ công hay phải tự phác thảo ra một cấu trúc dữ liệu thì bạn có thể code ít hơn để đạt được cùng một mục tiêu.

Sử dụng code có sẵn

Thay vì phải code chay từ đầu, hãy sử dụng thư viện có sẵn phù hợp.

Ví dụ, đầu tuần này tôi đã xem xét vấn đề về tăng version trong mã nguồn và tài liệu. Sau một thời gian tìm kiếm, tôi tìm thấy có một công cụ mã nguồn mở đã làm được chính xác những gì mà tôi cần. Vì nó đã được sử dụng bởi rất nhiều người và được nâng cấp nhiều lần, nên nó đã được thiết kế và chạy thử cẩn trọng với ít lỗi hơn so với những gì tôi có thể nỗ lực tạo ra khi tự viết code.

Sử dụng thời gian để suy nghĩ

Có một điều đáng ngạc nhiên là dành nhiều thời gian cho việc lên kế hoạch có thể giúp tiết kiệm thời gian trong dài hạn.

Nếu bạn có 2 ngày để sửa lỗi cho phần mềm, thì việc lên kế ý tưởng giải quyết vấn đề xứng đáng chiếm 10%, tương đương một tiếng rưỡi, của quỹ thời gian đó. Có khả năng giải pháp đầu tiên mà bạn nghĩ ra trong vòng 5 phút đầu không phải là phương án tốt nhất, đặc biệt khi vấn đề cần giải quyết là phức tạp. Sử dụng thêm 1 tiếng để suy nghĩ và bạn có thể chỉ phải mất 2 giờ để giải quyết công việc thay vì 2 ngày.

Đủ chức năng tốt

Hầu hết các chức năng đều gồm 3 phần:

  • Phần khách hàng phải có
  • Phần khách hàng thích có, nhưng ko bắt buộc
  • Phần khách hàng đồng ý là không cần thiết

Phần cuối cùng thì thường được bỏ, tuy nhiên bạn sẽ thường xuyên bị đề nghị thực hiện phần thứ 2 - phần mà product manager và khách hàng mong muốn, tuy nhiên ko hề bắt buộc.

Hãy tìm ra những phần tối thiểu thực sự cần thiết để có thể deliver chức năng đó càng sớm càng tốt, thường thì sau đó mọi người cũng ko còn quan tâm đến những thứ không quan trọng nữa đâu.

Loại bỏ chức năng

Một vài chức năng không cần thiết phải thực hiện. Một vài chức năng nên được thực hiện theo một cách khác tốt hơn là yêu cầu từ đầu của khách hàng.

Thay vì luôn trả lời "ok, tôi sẽ làm", hãy thực sự suy nghĩ về việc tại sao chức năng đó lại cần thiết. Nếu bạn có thể nhanh chóng đưa ra những ý kiến ưu việt, chắc chắn product manager hay khách hàng sẽ sẵn sàng nghe theo đề nghị của bạn.

Loại bỏ sản phẩm

Thi thoảng sẽ có những sản phẩm mà bạn ko nên làm: nó sẽ không có khách hàng, hay ko kiếm được lãi. Sử dụng hàng tháng trời cho một sản phẩm chả ai dùng, sẽ là sự phí phạm thời gian, thậm chí có thể gây cảm giác thất vọng chán chường.

Lean Startup là một phương pháp luận nhắc đến điều này: trước khi bỏ thời gian để phát triển một sản phẩm, hãy thực hiện các công việc tối thiểu để xác nhận sản phẩm đó có đáng để tiếp tục hay ko.

Kết luận

Mục tiêu của một lập trình viên không phải viết code mà là xử lý các vấn đề.

Từ những quyết định đơn giản trong việc lập trình đến những quyết định lớn trong kinh doanh, có nhiều cách để bạn giải quyết vấn đề mà không cần code nhiều.

Bởi vậy, đừng bắt tay vào việc với câu hỏi "Làm sao để tôi có thể viết được đoạn code này?" mà hãy bắt đầu với câu hỏi "Làm thế nào để giải quyết vấn đề này?" Đôi khi bạn có thể đạt được kết quả tốt hơn khi loại bỏ không giải quyết các vấn đề đó. Khi bạn có thể giải quyết được nhiều vấn đề hơn mà không cần code thêm, bạn sẽ thấy bản thân trở nên có năng suất hơn, đặc biệt khi nhìn vào tổng thể của vấn đề.

Source: From 10x programmer to 0.1x programmer: creating more with less

0