Thiết kế chương trình Excel VBA là bước quan trọng để từ đó xây dựng nên một chương trình quy mô lớn [IPO]

[tuhocvba]

Thiết kế chương trình Excel VBA là bước quan trọng để từ đó xây dựng nên một chương trình quy mô lớn [IPO]
1. Làm rõ Input, quá trình xử lý, Output như thế nào?
Thiết kế là việc suy nghĩ và đi tới quyết định phải làm như thế nào để hiện thực hóa mong muốn, ý muốn.
Đối với các thủ tục chỉ vài chục hay hơn trăm dòng code, việc suy nghĩ làm cái gì, làm như thế nào để hiện thực hóa ý tưởng, có lẽ là chỉ diễn ra trong đầu.
Tuy nhiên với một chương trình vài trăm dòng code, sử dụng nhiều thủ tục bên trong, nếu chỉ là những suy nghĩ trong đầu, thì thật khó có thể hiện thực dự án. Nếu có làm thì sẽ xảy ra nhiều vấn đề phát sinh giữa chừng, hoặc code chồng chéo, không tận dụng hiệu quả tài nguyên hệ thống.
Trong hoàn cảnh đó, việc tổ chức một cách có hệ thống bằng IPO (INPUT→PROCESS→OUTPUT) có thể giúp chúng ta thiết kế một chương trình rõ ràng, hiện thực hóa ý tưởng một cách khả thi mà ít gặp những trở ngại phát sinh giữa chừng.
Check!

INPUT：Dữ kiện đầu vào​

PROCESS：Các bước xử lý​

OUTPUT：Dữ liệu đầu ra mong muốn​

Hãy vận dụng suy nghĩ này vào Excel, ta sẽ thấy rất hiệu quả đấy.
Làm rõ ý tưởng, đâu là thông tin đầu vào, form giao diện trông như thế nào,... bằng cách sử dụng các graph trực quan hoặc có khi chỉ là những ghi chú bằng chữ nhưng cụ thể. Các quá trình xử lý trung gian là gì, tính toán dữ liệu như thế nào, thể hiện kết quả ra sao... Càng làm rõ ý tưởng càng tốt.
Hầu hết các công việc của chúng ta đều được cấu thành từ ba yếu tố như hình minh họa sau đây:

Bạn cần đăng nhập để thấy đính kèm

2. Đối với Excel VBA, chúng ta có nhiều thuận lợi trong thiết kế.
Hầu hết công việc Excel VBA đều nhận Input là file excel hoặc sheet nào đó của file excel, đi qua quá trình xử lý, và output cũng là một file excel hoặc một sheet của file excel đã được xử lý dữ liệu.
Vì vậy, nếu so sánh với các chương trình làm việc trên máy tính, thì việc thiết kế một chương trình Excel VBA có nhiều thuận lợi hơn.

Bạn cần đăng nhập để thấy đính kèm

Vì vậy, để làm rõ xử lý, cần chú ý nêu rõ là chúng ta đang xử lý với file nào, sheet nào, với trường dữ liệu nào (cột dữ liệu)...
Mục đích là để tạo ra Output trông như thế nào.

Trên diễn đàn, hầu hết chúng ta chỉ tập trung nói về Process, tôi muốn xử lý như thế này. Trong khi đó, làm rõ Input là gì, Output trông như thế nào-đó cũng là một việc rất quan trọng. Nhưng một số bạn thậm chí còn chẳng đưa file input lên. Hoặc file input không đúng với thực tế sau này, dẫn tới việc code không bao quát hết các khả năng. Hoặc không làm rõ Output mình muốn như thế nào cũng là điều thường gặp trên diễn đàn.

3. Công việc thiết kế sẽ giúp việc code đạt hiệu suất cao nhất.
Công việc thiết kế thường mát 70% thời gian của toàn dự án. Đây cũng là giai đoạn chính, bởi người yêu cầu code gần như không thể đọc code, mà họ giao tiếp với người code thông qua bản thiết kế. Thiết kế của anh là đúng/không đúng với ý tưởng mong muốn của tôi-họ trả lời được ngay. Trong khi đó, đối với việc đọc code, hoặc thậm chí chạy thử chương trình rồi check lại kết quả, thường mất nhiều thời gian hơn.
Khi xong giai đoạn thiết kế, thì việc code diễn ra rất nhanh. Ví dụ, chúng tôi có thể phải mất cả tuần chỉ để họp hành làm rõ các thắc mắc về thiết kế. Nhưng khi thiết kế đã được hai bên thống nhất, thì việc code chỉ trong 1-2 ngày là xong.

Tuy nhiên, trong quá trình làm việc thực tế trên diễn đàn, tôi nhận thấy các bạn thường rất sốt ruột, muốn người code bắt tay vào ngay việc code. Muốn có ngay bản demo, tâm lý ấy thật khó hiểu.

 

[vbano1]

Với những người đang học VBA thì không nói làm gì, bạn có thể làm gì tùy thích. Nhưng khi áp dụng vào công việc, nhất là khi đem nó ra để giới thiệu cho mọi người cùng sử dụng, thì nhất thiết đừng quên 5 nguyên tắc sau mà một người phát triển Tool VBA cần nắm.
Bởi vì nếu không nắm được những nguyên tắc sau, thứ bạn làm ra có thể không được coi trọng, điều đó có thể làm cho bạn suy sụp khi đã ra biết bao nhiêu là công sức mà lại không nhận được sự đón nhận nồng nhiệt.

1. Phải cống hiến một cách rõ ràng về hiệu suất công việc cho người sử dụng nó.
Nếu như có thể định lượng (đưa ra con số cụ thể) về hiệu suất của công việc khi sử dụng Tool VBA khi so sánh với làm bằng tay hoặc bằng công cụ phần mềm khác, thì điều đó sẽ làm nổi bật vai trò của Tool, đáp ứng được kỳ vọng mong mỏi của mọi người ra sao.

2. Phải tạo ra một chương trình dễ hiểu.
VBA chẳng phải là kiến thức thông thường để bất cứ ai cũng có thể hiểu được. Nhưng cho dù như thế, thfi vẫn phải viết làm sao để mọi người có thể đọc nó. Có một vấn đề quan trọng sau này, đó là ai sẽ sửa chữa hay update khi phát sinh vấn đề.
Ngay kể cả một người thành thạo VBA cũng có thể nói rằng: Tôi chẳng phải là người tạo ra chương trình này, cho nên tôi không thể hiểu được, tôi không thể nào sửa chữa hay nâng cấp cập nhật cho anh được. Điều đó thật là tồi tệ, macro bạn làm ra chẳng khác nào là bản record macro.
Vì vậy, không chỉ comment vào trong code để làm cho nội dung rõ ràng dễ hiểu, mà bản thiết kế chương trình sẽ là thứ mà ai cũng có thể đọc và hiểu được, thay vì nhìn vào code, mọi người có thể đọc thiết kế và trao đổi dựa trên nội dung thiết kế này.

3. Phải chịu trách nhiệm về chất lượng Output của chương trình.
Người phát triển Tool phải chịu trách nhiệm về hoạt động của Tool. Các hoạt động cần thiết, như đưa ra các định nghĩa sử dụng trong chương trình, ai thiết kế, ai code, ai test... là điều đương nhiên mà người phát triển Tool phải phân rõ. Tuy nhiên, khi Tool được đưa vào sử dụng, Output của Tool phải có người chịu trách nhiệm, và đó không ai khác chính là người phát triển Tool.
Anh làm ra Tool, người khác sử dụng Tool đó rồi đưa ra Output sai, đó là điều không hay nhưng vẫn cần có người chịu trách nhiệm. Bởi vậy đi kèm với Tool luôn có Luật (rule) và Manual (hướng dẫn sử dụng).

4. Tool hoạt động dễ thích nghi với Input, người dùng hiểu được logic của Input sẽ cho ra Output như thế nào.
Người không có kiến thức về chương trình cũng có thể hiểu được chương trình sẽ làm ra cái gì, hoạt động ra sao, đó chính là điều mà người làm Tool phải thực hiện được. Như vậy cần có mô tả Input ra sao, Output như thế nào là điều cần thiết. Ngoài ra, người dùng hiểu rõ Input, có thể tùy biến thay đổi giá trị đầu vào mà Tool vẫn chạy, đó là điều mà một người làm Tool nên hướng tới.
Ta ví dụ, không chỉ cố định một bảng tính chỉ có 25 cột hay 2000 dòng dữ liệu.

5. Dự đoán được các trường hợp phát sinh và đưa ra xử lý phù hợp.
Có rất nhiều tình huống có thể gây nên lỗi, dù cho bản thiết kế hoàn hảo tới đâu. Tuy nhiên, khi có lỗi xảy ra thì xử lý sẽ là như thế nào, đưa ra thông báo cho người dùng ra sao, đó là điều mà người thiết kế phải suy nghĩ.

 

[giaiphapvba]

Tên Biến
Một chương trình dễ đọc, dễ hiểu luôn được đánh giá cao. Điều này có ý nghĩa của nó, nếu bạn làm việc theo nhóm, có mối liên kết tới các thành viên khác. Ngoài ra, điều này còn đặc biệt có ý nghĩa nếu như sau này cải tiến code, bạn không còn ở nhóm đó nữa, làm thế nào để người khác cũng có thể đọc được code của bạn, do đó, có một vài qui tắc bất thành văn.
Gọi là bất thành văn, bởi vì thực ra nó không phải luật, nó là thói quen được hình thành, và được công nhận bởi đa số người khác.

1. Tiếp đầu ngữ của tên biến nên làm thế nào để mọi người đều hình dung được nó là kiểu biến gì.
Ví dụ:

intCount,strName

intCount làm chúng ta liên tưởng tới kiểu biến integer.
strName thì lại làm chúng ta liên tưởng tới kiểu biến String.
Dưới đây là các qui ước bất thành văn hay sử dụng:

Kiểu biến	Ký hiệu viết tắt
Integer	int
Long	lng
Single	sng
Double	dbl
String	str
Date	dtm
Boolean	bln
Variant	var
Range	rng

Một số người thì thường sử dụng các biến có chữ f ở đầu, ví dụ fXuatHien khai báo là kiểu Boolean. Chữ f là chữ cái đầu của từ flag (nghĩa là cờ).

2. Nên tách các chữ viết hoa hợp lý để dễ đọc tên biến.
Nếu tên biến viết là deliverydate , thì thật khó đọc. Nhưng nếu chúng ta viết là DeliveryDate thì lại dễ đọc.
Vì vậy, các chữ cái bắt đầu của một từ thì thường viết hoa, các chữ còn lại viết thường, đây không phải là luật, đơn thuần là thói quen qui ước để mọi người dễ đọc tên biến.
Nếu bạn không giỏi tiếng anh, bạn cũng có thể sử dụng các tên biến bằng tiếng việt, nhưng qui ước trên vẫn được sử dụng vì chúng ta bị ràng buộc liên kết bởi các thành viên khác trong cùng đội. Có như vậy người khác mới dễ đọc code của các bạn.

3. Hằng số thường được viết hoa.

Const TAX_RATE As Currency = 0.08
Const USER_PASSWORD As String = "hogehoge"

4. Nên có chú thích cho chương trình (hàm) theo cấu trúc sau:

'-----------------------------------------------------------
' Chức năng: Từ vùng rng, lấy giá trị var trả về giá trị hàng hoặc cột
' Input: rng/Phạm vi tìm kiếm、var/Gá trị tìm kiếm,strDim/r→hàng,c→cột
' Output: Hàng hoặc cột
'-----------------------------------------------------------
Function findCell( _
  ByRef rng As Range, _
  ByVal var As Variant, _
  Optional strDim As String = "r")

  'Xử lý

End Function