Làm thế nào để tăng năng suất trong lập trình? (Phần 2)

               

Nguyễn Hoàng Long

Ở phần trước, chúng ta đã biết được cách để giúp tăng tốc độ code, một trong hai thứ giúp chúng ta tăng năng suất lao động. Ở phần này, chúng ta sẽ tiếp tục bàn vệ việc: “Làm thế nào để tăng chất lượng code?”

Làm thế nào để tăng chất lượng code?

Đầu tiên, chúng ta cần làm rõ, như thế nào là code chất lượng. Tùy thuộc vào nhu cầu và sự kỳ vọng của bạn vào code, chúng ta sẽ có nhiều thứ để đánh giá chất lượng của code.

Chắc hầu hết chúng ta, những người đã, đang và từng là lập trình viên đều phải từng học qua và biết đến: “Lập trình hướng đối tượng”. Đây là một trong những hình mẫu lập trình được xem như tốt nhất hiện nay. Mặc dù đã xuất hiện từ rất lâu, nhưng vị thế của nó vẫn chưa hề sụt giảm. Chắc mọi người đều công nhận, nó là một hình mẫu khá lý tưởng và sẽ đem đến những chương chình chất lượng. Vì vậy, trong bài viết này, tôi xin phép sự dụng những tính chất của “Lập trình hướng đối tượng” để làm những yếu tố đánh giá chất lượng của code.

Như các bạn đã biết, “Lập trình hướng đối tượng” có 4 tính chất chính:

Tính trừu tượng (abstraction)

Tính đóng gói (encapsulation) và che giấu thông tin (information hiding)

Tính đa hình (polymorphism)

Tính kế thừa (inheritance)

Như vậy, một đoạn code hay một chương trình chất lượng, nên có 4 tính chất trên.


Tính trừu tượng (abstraction): Đây là khả năng của chương trình bỏ qua hay không chú ý đến một số khía cạnh của thông tin mà nó đang trực tiếp làm việc lên, nghĩa là nó có khả năng tập trung vào những cốt lõi cần thiết.

Có những thứ chúng ta không hiểu là gì những cũng rất đẹp… trừu tượng cũng vậy

Để làm được điều này, bạn cần có một cái nhìn tổng quan về dự án, hay những phần mà bạn cần làm. Xây dựng một bộ khung các chức năng hay các thuộc tính mà có thể sử dụng ở nhiều nơi, những thứ không thể thiếu thành các Interface hay các Class, Component. Rồi từ đó, bạn phát triển thành các chức năng bạn mong muốn. Đây là công việc không phải đơn giản, bởi bạn cần nắm được một cái nhìn tông quan, sau đó mới bắt đầu thiết kế. Điểm lợi của việc này là sẽ giúp bạn giảm thời gian khi tạo các tính năng mới mà giống với các tính năng đã có, và có thể tiếp tục phát triển tính năng mới này, trong một số trường hợp, nó sẽ giúp bạn hạn chế việc lỗi nếu bạn quên hay thiếu khi copy hay clone một đoạn code của những người khác.

Ví dụ, khi bạn là làm một trang web quản lý, chức năng thông thường và chủ yếu của nó sẽ là lên danh sách các sản phẩm, tạo các sản phẩm mới, sửa các sản phầm và xem các sản phẩm. Tùy vào đặc thù của các sản phẩm, thông tin cần hiển thị chắc chắn sẽ khác nhau, và bạn sẽ cần những trang khác nhau để cấu hình chúng. Tuy nhiên, nếu bạn nhìn kỹ vào các màn hình, chúng luôn có những điểm chung. Như màn hình danh sách, hầu hết đều gổm: Phần search, phần bảng thông tin, phần phân trang, các button chức năng tạo mới, sửa. Bạn có thể tạo thành một Component chung, khai báo sẵn sàng các thông tin cần thiết, các component sẽ cần sử dụng. Như việc phân trang, hấu hết chúng đều như nhau, việc lật trang, thay đổi số lượng hiện thị… bạn hoàn toàn có thể xây dựng các function tương ứng và cho hết vào một chỗ. Làm mới thì chỉ cần kế thừa thằng cũ và sửa lại một số tùy thuộc vào nghiệp vụ hay việc giao tiếp với các api.


Tính đóng gói (encapsulation) và che giấu thông tin (information hiding): tính chất này không cho phép người sử dụng các đối tượng thay đổi trạng thái nội tại của một đối tượng. Chỉ có các phương thức nội tại của đối tượng cho phép thay đổi trạng thái của nó. Việc cho phép môi trường bên ngoài tác động lên các dữ liệu nội tại của một đối tượng theo cách nào là hoàn toàn tùy thuộc vào người viết code. Đây là tính chất đảm bảo sự toàn vẹn của đối tượng.

Đóng gói hay đóng gói?
“Đóng gói” hay “Đóng gói”?

Với tính chất này, nó sẽ giúp bạn đảm bảo trong việc kiểm soát dữ liệu và luồng dữ liệu. Điều này sẽ cải thiện trong việc debug, quản lý các tiến trình bất đồng bộ điều cực kỳ khó khăn. Bạn có thể hiểu là mình đang tạo ra một sân chơi mà bạn có thể kiểm soát mọi thứ bên trong nó, những người ngoài chỉ có thể làm những điều mà bạn cho phép. Nó sẽ bảo vệ đoạn code và các tiến trình, và cũng phần nào giúp bạn tránh được việc người ngoài hack các chương trình của mình.

VD: Đối với lập trình web, khái niệm Redux trong React, Vuex trong Vuejs hay NgRx trong Angular chắc hẳn là khá quen thuộc. Và chúng là những thư viện hộ trợ bạn trong việc quản lý trạng thái của trang web. Và theo cách nào đó, nó đang thực hiện đúng tính đóng gói và che giấu thông tin này. Bạn hoàn toàn có thể định nghĩa các phương thức vào, ra, cho phép thay đổi thông tin state của ứng dụng. Những người sử dụng phải đi theo các phương thức mà bạn cho trước, nó bảo vệ trạng thái, tránh cho những người khác chỉnh sửa thông tin một cách không hợp pháp.


Tính đa hình (polymorphism): Thể hiện thông qua việc gửi các thông điệp (message). Việc gửi các thông điệp này có thể so sánh như việc gọi các hàm bên trong của một đối tượng. Các phương thức dùng trả lời cho một thông điệp sẽ tùy theo đối tượng mà thông điệp đó được gửi tới sẽ có phản ứng khác nhau. Người lập trình có thể định nghĩa một đặc tính (chẳng hạn thông qua tên của các phương thức) cho một loạt các đối tượng gần nhau nhưng khi thi hành thì dùng cùng một tên gọi mà sự thi hành của mỗi đối tượng sẽ tự động xảy ra tương ứng theo đặc tính của từng đối tượng mà không bị nhầm lẫn.

Đây là một việc giúp bạn giảm thiểu số lượng code, tuy nhiên cũng sẽ tăng thêm logic cho một đoạn code. Khi bạn truyền thêm điều kiện hay thông tin, đoạn code sẽ rẽ sang các nhánh để thực hiện các chức năng khác nhau. Mặc dù điều này sẽ tăng thêm logic và khiến cho code khó maintain hơn, nhưng bạn sẽ làm ra những thứ có thể sử dụng đa dạng hơn. Một thứ gì đó đa dụng luôn có ích hơn là một thứ gì đó dùng một lần rồi thôi. Việc bạn tăng logic trong code cũng sẽ giúp bạn cải thiện thêm khả năng xử lý logic. Tuy nhiên bạn cũng đừng quá lạm dụng điều này, vì khi có quá nhiều logic trong một đoạn code, nó sẽ tiềm ẩn những rủi ro mà bạn khó lòng kiểm soát hoàn toàn.

Ví dụ: Vẫn là trong làm web, khi bạn làm trang tạo sản phẩm hay người dùng, đôi khi bạn luôn muốn rằng mình sẽ sửa được thông tin của nó. Và nếu làm một màn chỉnh sửa bằng việc clone toàn bộ trang tạo là một cách, tuy nhiên việc đó thật sự quá trâu bò, hơn 80% logic mà trang chỉnh sửa sẽ được dùng lại của trang tạo. Nhưng nếu bạn gắn thêm một “Thông điệp”, một cái cờ hay một thông tin nào đó và rõ ràng thông tin cần thiết chính là id, hay name của dữ liệu, thứ mà giúp bạn gọi api để lấy thông tin chi tiết của cả sản phẩm. Bạn dùng chúng để rẽ nhánh, nếu có thì là màn tạo mới, nếu không có thì là màn chỉnh sửa. Màn chỉnh sửa chỉ cần chỉnh lại 20% logic còn lại mà thôi. Nhưng như đã nói, việc ghép 2 màn hình tạo và chỉnh sửa lại sẽ tăng logic của cả màn hình và gây tăng lỗi. Các lỗi thường gặp như cùng chung Title, những thứ đáng ra phải là “Sửa” nhưng lại là “Tạo”… Tuy nhiên nếu bạn làm tốt, bạn đã giảm đến 50% thời gian làm việc rồi.

Sửa “1 tí” thôi nên làm chung cho gọn

Tính kế thừa (inheritance): Đặc tính này cho phép một đối tượng có thể có sẵn các đặc tính mà đối tượng khác đã có thông qua kế thừa. Điều này cho phép các đối tượng chia sẻ hay mở rộng các đặc tính sẵn có mà không phải tiến hành định nghĩa lại. Tuy nhiên, không phải ngôn ngữ định hướng đối tượng nào cũng có tính chất này.

Làm lập trình, bạn chắc hẳn luôn muốn những dòng code sẽ chạy tốt với bản thân mình. Nhưng khi bạn mong muốn một điều gì đó cao cả hơn, không dừng lại ở việc cho bản thân và công ty mình, bạn muốn một cái gì đó có tính cộng đồng. Tính kế thừa là một điều không thể thiếu trong code của bạn. Nó sẽ giúp code của bạn có thể được truyền thì dự án này qua dự án khác, không dừng phát triển và trở thành một cái gì đó được nhiều người biết đến. Và chắc chắn đây là điều khó khăn nhất cũng như dễ dàng nhất để thực hiện. Bạn export nó và import lại vào một chỗ khác, đó chính là kế thừa. Nhưng để làm được điều đó, bạn phải đảm bảo rằng bạn phải tạo nên một cái gì đó thật chất lượng (thông qua các tính chất trên chẳng hạn ^^).

Hay trao đi một món quà

Việc tăng chất lượng code là rất khó và nó cần rất nhiều thời gian, công sức cũng như sự học hỏi của bản thân. Khi trong code của bạn có đủ cả 4 tính chất trên, code của bạn thật sự đã rất chất lượng rồi. Tuy nhiên đó chỉ là về mặt tổng quan, nhìn trên một hệ thống lớn, bạn vẫn cần phải cải thiện chất lượng code với những điều nhỏ nhặt hơn như Refactor code, Review lại code của mình, học hỏi các phương thức code mới từ đồng nghiệp để giúp code bạn sạch hơn, đẹp hơn, dễ đọc hơn. Những thay đổi đó dù nhỏ nhặt nhưng cứ tích cóp lại, dần dần sẽ trở thành một thứ gì to lớn, tạo thành kinh nghiệm cho bạn, cải thiện bản thân và chất lượng code của mình.