Đứng ở góc độ người dùng thì họ không cần biết mình code linh động, code có chú thích, code đẹp, code có quản lý tốt hay không, cái họ quan tâm là kết quả có đúng không, thao tác có tiện không, thời gian chờ có lâu không, giao diện nhìn có bắt mắt không, nên em nghĩ sẽ không tốn thời gian giải thích cho người dùng nhiều. Những vấn đề này chỉ có những người viết code quan tâm với nhau thôi.
...
Trên ngữ cảnh của một procediure, khi tôi nói users tức tôi nói "users of the procedure", tức là người viết code, hoặc cái đối tượng gọi procedure.
...
Em đồng ý với thầy một đoạn code nên chú thích thì sẽ tốt hơn một đoạn code không có chú thích, nó sẽ hữu ích cho mình cũng như người khác đọc để hiểu. Đối với những đoạn code phức tạp, khi mình viết cho một người nào đó đọc (có thể sau này mình cần đọc lại) thì viết chú thích sẽ tiết kiệm thời gian đọc hiểu hơn. Em cũng đồng ý hàm nào làm đúng công việc của nó là điều cần thiết khi viết code, nhưng không phải không có lý do mà người ta tạo ra optional hay được phép khai báo biến có giá trị NULL làm gì, nó vẫn có ích trong trường hợp nào đó, chỉ khi lạm dụng nó quá nhiều theo như thầy nói dẫn đến việc code khó hiểu hay khó bảo trì thì mới phản tác dụng.
...
Cứ theo dõi code VBA trên diễn đàn này sẽ thấy.
Có một vài hàm được viết ra với cả đống options. Nhìn vào rừng bỏ bố. Sỡ dĩ một số thành viên khác vẫn dùng và khuyến khích (recommend) dùng là vì họ quen với lối code này, và đã quen thuộc với hàm này.
Nếu bạn để ý sẽ thấy các thành viên được khuyến khích sẽ chẳng hiểu gì cả, cứ nhắm mắt mà theo thôi.
Mạt khác, có những hàm viết rất hoành tráng đầy đủ tùm lum, nhưng đưa đến ngừoi dùng thì họ tá hoả tam tinh. Chính thực là do ngừoi viết chỉ cốt hoành tráng mà không giải thích cách sử dụng.
...
Nói về hướng đói tượng cũng như việc quản lý code thì em không thấy liên quan gì tới máy mạnh hay yếu, em thấy quan trọng ở cách tổ chức và quản lý code,
mỗi cá nhân có cách tổ chức và quản lý code khác nhau, miễn sao họ cảm thấy thuận tiện cho công việc, dễ hiểu, dễ tái sử dụng, không gây mất thời gian bảo trì hay mở rộng tính năng sau này là được, với thầy thì cách thầy đang làm thầy thấy hiệu quả nhưng em thì không ( có thể em chưa thấy giải pháp của thầy dựa trên code thực tế nên em vẫn sẽ bảo vệ quan điểm của mình), như em tạo sp cho bảng DanhSachHocSinh để dành các câu truy vấn liên quan tới bảng đó thì em nghĩ sẻ quản lý tốt hơn so với tạo từng câu SP riêng lẽ chứ, giả sử nếu
thêm câu lệnh INSERT,UPDATE,DELETE thì em sẽ tạo thêm các @option nữa cho các câu lệnh đó, hoặc tái sử dụng các biến đang có trong những câu lệnh khác trong cùng 1 SP, sau này cần chỉnh sửa nội dung bảng nào thì em chỉ cần vào SP của bảng đó là được.
...
Trên quan điểm của một project manager, câu bôi đỏ trên sẽ được khuyên đỏ.
Tổ chức quản lý code thuộc về project chứ không phải cá nhân. Bởi vì bạn quen dựng project cá nhân cho nên có thể tự mình quản lý.
Trên thực tế, chỉ những developers kỳ cựu mới được leader cho quyền tự phân lấy interfaces của module mình viết ra. Các developers non thì chính thức chỉ là người dịch thuật toán thành code.
Những project lớn, code có peer review. Viết mà không đủ chú thích cho dễ hiểu tụi nó khuyên đỏ tan nát hết.
"Tái sử dụng" là một trong những tínhn chất của LTHĐT. Chính vì cái này mà tôi mới nói chuyện rằng việc nào procedure nấy, nhiều việc thì viết thêm một cái procedure gọi mấy cái kia. Căn là tránh một cái ôm đồm một đống công việc. Và viết một cái hàm "uyển chuyển" với nhiều options là đường lối xưa (xem định nghĩa overhead bên dưới). Lý do:
- theo quan niệm ai là việc nấy của LTHĐT thì nếu công việc A và B không chia sẻ nhau đa số code thì A nên độc lập với B. Nếu số code chia sẻ xứng đáng gọi là một công việc thì thêm phần tử C để cho A và B cùng gọi C. Code như vậy mới dễ "tái sử dụng". Vì chúng rõ rệt và riêng biệt. Lúc debug có thể bubble từ dưới lên trên. Lúc cần thay đổi thì chỉ cần nhắm đúng cái procedure chứa phần cần thay đổi.
Phần tô tím ở trên cũng sẽ được khuyên đỏ.
Trên nguyên tắc lập trình, những cái thay đổi dữ liệu, nếu có thể được thì nên được đặt riêng với những cái chỉ truy xuất dữ liệu.
Đối với SQL Server procedure, điều này khá quan trọng vì tôi có thể cho users class A quyền Insert nhưng không Update, user class B chỉ truy vấn. Chia ra nhiều procedures giúp tôi kiểm soát điều này dễ dàng. (có nhiều cách đi vonngf để không chia cũng được, nhưng cách kiểm soát rắc rối hơn)
Đối với lập trình thì đó là nhiệm vụ của ByVal và ByRef.
Microsoft có nói rõ là ByVal sẽ tạo overhead, bởi vì chương trình phải copy một phiên bản local của tham, nhét tham vào stack và khi thoát thì lấy trở ra. Vậy thì ByVal được cái lợi gì? Cái lợi rõ rệt nhất của nó là người sử dụng hàm chỉ cần nhìn vào câu khai báo là có thể an tâm rằng biến nạp vào tham này sẽ không bị thay đổi. Nói cách khác, hàm khai báo ByVal HỨA rằng nó sẽ không thay đổi giá trị của biến nạpn vào tham.
Nếu bạn có dùng C++ thì cũng biết C++ đã khổ tâm với Const biết bao nhiêu để bảo vệ cái tính chất "tôi hứa rằng tôi sẽ không biến đổi trị của biến này"
...
Em chỉ biết khái niệm override và overload trong lập trình hướng đối tượng, và em nghĩ thầy đang nhầm overload thành overhead.
Overhead của hướng dối tượng là kết nối trễ, là bảng ảo (virtual table).
Overhead của hàm là gọi hàm thì phải lập stack, và kết nối.
Overhead của các tham ByVal là phải copy lại thành một biến mới. Nếu biến là một object thì có thể liên hệ nhiều điều khác.
... các overhead khác...
Khi tôi nói overhead của kỹ thuật chia ra nhiều hàm nhỏ là tôi muốn nói cái điểm thứ hai ở trên.
