Đánh giá code tốt (good quality) nó có nhiều khía cạnh, một trong các khía cạnh khá quan trọng không thể bỏ qua là Readability (khả năng đọc hiểu) và Maintainability (khả năng bảo trì).
Nói về Maintainability trước nhé:
Chất lượng của một sản phẩm không chỉ ở cái bề ngoài, không phải chỉ là "người ta quan tâm tới sản phẩm chạy tốt, tiện dụng, không lag, không ai quan tâm anh dùng công nghệ gì" mà nó còn ở bên trong.
Mình không hiểu khách hàng của bác trình độ tới đâu mà lại chỉ quan tâm đến vẻ bề ngoài như vậy? Nhưng khách hàng của mình khi làm project cho họ, mình muốn dùng công nghệ ACB nào đó, muốn dùng mô hình Deployment XYZ nào đó ... đều phải chỉ rõ lí do, thậm chí cần slide bảo vệ, slide thuyết trình để thuyết phục họ. Họ review từng dòng code của team, review năng lực của từng member trong team.
Bản thân mình chưa bao giờ làm việc với một khách hàng mà chỉ quan tâm đến vẻ bề ngoài của sản phẩm. Một khách hàng thông minh người ta thừa khả năng để hiểu rõ cái quan trọng chính là phần bên trong. Bởi lẽ cái gì cũng có hạn sử dụng của nó, sản phẩm CNTT cũng không ngoại lệ, nếu cái họ nhận được từ mình là một sản phẩm chạy mượt, ngon, không lag ở thời điểm hiện tại nhưng lại khó bảo trì, khó sửa chữa, khó mềm dẻo với thay đổi trong tương lai thì liệu họ có accept không? Chạy mượt ở hiện tại, nhưng sau 1 năm nữa muốn thay đổi thì phải đập đi làm lại tốn nhiều chi phí thì họ có đồng ý với một sản phẩm như thế không? Nếu là bạn thì bạn có đồng ý nhận một sản phẩm như thế không?
Mình nghĩ là đừng nên đoán (hoặc fixed) suy nghĩ của khách hàng, cái đó là cái cực kì khó đoán, không lường trước được và bất định (có thể thay đổi bất cứ lúc nào), đôi khi cái họ cần rất phức tạp đến mức mình không đáp ứng nổi, cũng đôi khi nó lại cực kì đơn giản đến không ngờ.
Còn bàn về Readability:
Khi source code dễ đọc (Easier for read) thì tức là Readability của nó cao. Có ai muốn viết ra một đoạn code mà chỉ chúa mới hiểu không? Mình tin là không. Còn những bạn nào tư duy tốt, giải thuật tốt, Toán tốt, thì họ cũng sẽ KHÔNG viết ra một đoạn code khó hiểu đâu, hay chí ít, họ cũng không bao giờ coi nhẹ tính chất Readability của một đoạn code đâu bạn :)
Chia sẻ về quan điểm của bạn:
Mình chỉ tuyệt đối đồng ý với quan điểm cần coi trọng và đặc biệt coi trọng tiếng Anh, còn những skill khác, mỗi người mỗi việc nó đặc thù khác nhau, tùy môi trường mà ta nên improve cái nào cho phù hợp. Và điều cốt lõi quan trọng cần đảm bảo là khả năng adapt một cách flexible trong các môi trường khác nhau (adapt cả về trình độ lẫn thái độ), điều đó làm nên giá trị thực sự (right value) của một cá nhân so với một cá nhân khác. Nếu ép một Scientist triển khai một hệ thống phần mềm, chưa chắc người ta đã làm "ngon" bằng các bạn trẻ bây giờ đâu, bạn ạ ;)
Nói về Maintainability trước nhé:
Chất lượng của một sản phẩm không chỉ ở cái bề ngoài, không phải chỉ là "người ta quan tâm tới sản phẩm chạy tốt, tiện dụng, không lag, không ai quan tâm anh dùng công nghệ gì" mà nó còn ở bên trong.
Mình không hiểu khách hàng của bác trình độ tới đâu mà lại chỉ quan tâm đến vẻ bề ngoài như vậy? Nhưng khách hàng của mình khi làm project cho họ, mình muốn dùng công nghệ ACB nào đó, muốn dùng mô hình Deployment XYZ nào đó ... đều phải chỉ rõ lí do, thậm chí cần slide bảo vệ, slide thuyết trình để thuyết phục họ. Họ review từng dòng code của team, review năng lực của từng member trong team.
Bản thân mình chưa bao giờ làm việc với một khách hàng mà chỉ quan tâm đến vẻ bề ngoài của sản phẩm. Một khách hàng thông minh người ta thừa khả năng để hiểu rõ cái quan trọng chính là phần bên trong. Bởi lẽ cái gì cũng có hạn sử dụng của nó, sản phẩm CNTT cũng không ngoại lệ, nếu cái họ nhận được từ mình là một sản phẩm chạy mượt, ngon, không lag ở thời điểm hiện tại nhưng lại khó bảo trì, khó sửa chữa, khó mềm dẻo với thay đổi trong tương lai thì liệu họ có accept không? Chạy mượt ở hiện tại, nhưng sau 1 năm nữa muốn thay đổi thì phải đập đi làm lại tốn nhiều chi phí thì họ có đồng ý với một sản phẩm như thế không? Nếu là bạn thì bạn có đồng ý nhận một sản phẩm như thế không?
Mình nghĩ là đừng nên đoán (hoặc fixed) suy nghĩ của khách hàng, cái đó là cái cực kì khó đoán, không lường trước được và bất định (có thể thay đổi bất cứ lúc nào), đôi khi cái họ cần rất phức tạp đến mức mình không đáp ứng nổi, cũng đôi khi nó lại cực kì đơn giản đến không ngờ.
Còn bàn về Readability:
Khi source code dễ đọc (Easier for read) thì tức là Readability của nó cao. Có ai muốn viết ra một đoạn code mà chỉ chúa mới hiểu không? Mình tin là không. Còn những bạn nào tư duy tốt, giải thuật tốt, Toán tốt, thì họ cũng sẽ KHÔNG viết ra một đoạn code khó hiểu đâu, hay chí ít, họ cũng không bao giờ coi nhẹ tính chất Readability của một đoạn code đâu bạn :)
Chia sẻ về quan điểm của bạn:
Mình chỉ tuyệt đối đồng ý với quan điểm cần coi trọng và đặc biệt coi trọng tiếng Anh, còn những skill khác, mỗi người mỗi việc nó đặc thù khác nhau, tùy môi trường mà ta nên improve cái nào cho phù hợp. Và điều cốt lõi quan trọng cần đảm bảo là khả năng adapt một cách flexible trong các môi trường khác nhau (adapt cả về trình độ lẫn thái độ), điều đó làm nên giá trị thực sự (right value) của một cá nhân so với một cá nhân khác. Nếu ép một Scientist triển khai một hệ thống phần mềm, chưa chắc người ta đã làm "ngon" bằng các bạn trẻ bây giờ đâu, bạn ạ ;)
No comments:
Post a Comment