10 điều Dành Cho Những Ai Sắp Vật Lộn Với Vb

[handung107]

Điều 1: Nên có một kế hoạch cụ thể

Trước khi cùng “quậy” với Visual Basic, bạn nên bỏ chút thời gian nguệch ngoạc lên giấy một kế hoạch về đề án của mình. Đừng để môi trường phát triển ứng dụng cực nhanh của Visual Basic biến bạn trở thành một lập trình viên cẩu thả, không có hệ thống.

Điều 2: Nên để Visual Basic giúp đỡ bạn

Nhờ người khác giúp đỡ mình cũng là cách thể hiện mình là một người khiêm tốn, cầu tiến (mặc dù thực ra có thể mình chẳng khiêm tốn chút nào và lại vô cùng bảo thủ, hì!). Visual Basic khuyến mãi cho bạn nhiều tùy chọn, góp phần tạo nên một cảm giác dễ chịu khi xài Visual Basic. Trong khung đối thoại Options, bạn có thể thiết lập các tùy chọn để quy định việc khai báo biến, việc ghi tự động (autosave) các đề án định kỳ theo các quãng thời gian quy ước, hoặc việc ép các ô điều khiển (control) phải được canh chỉnh theo khung lưới (grid),…

Điều 3: Nên thiết lập các quy ước đặt tên

Việc bổ sung các tiền tố (prefix) xác định tính chất cho các ô điều khiển và các biến giúp cho bản thân đoạn mã tự nhiên cũng trở thành tài liệu để dễ hiểu và dễ kiểm sửa (debug) hơn. Bằng việc xác định tất cả các thuộc tính (property) thay vì chấp nhận các thuộc tính mặc định, bạn cũng có thể làm cho đoạn mã của mình trở nên dễ đọc hơn.

Bạn có thể dùng quy ước đặt tên như sau:

Tiên tô Ô điêu khiên, biên Ví dụ

Txt Text box txtHoVaTen

Lbl Label lblChuThich

Cbo Combo box cboDanhSachKhachHang

Lst List box lstDanhSachHoSo

Chk Check box chkGioiTinh

Cmd Command button cmdThemDuLieu

Img Image imgHinh4x6

… … …

S Biến kiểu String sThongBaoLoi

L Biến kiểu Long lThanhTien

… … …

Pub_ Biến xài chung (public) pub_sThongBaoLoi

pri_ Biến cục bộ (private) pri_sThongBaoLoi

… … …

Điều 4: Nên chú thích cho đoạn mã

Khi viết các đoạn mã cho các đơn thể (module), các hàm (function) và các thủ tục (procedure) trong một đề án, bạn nên thêm các dòng chú thích cho chúng, vì như thế sẽ giúp bạn hiểu rõ vai trò, nhiệm vụ của chúng. Không nên cho rằng: Sau một năm, bạn sẽ luôn luôn nhớ chính xác cách thức làm việc của một hàm, một thủ tục nào đó. Ngược lại, nếu nghe lời dụ khị này của tụi tui thì khi bạn đã bước qua tuổi “thất thập cổ lai hy”, mỗi lần buồn buồn xem lại các đoạn mã này, bạn vẫn có thể giảng giải rõ ràng cho con cháu của mình tất cả các tuyệt chiêu mà bạn đã tung ra cách đấy ba - bốn chục năm.

Thậm chí, nếu đoạn ghi chú viết bằng tiếng Anh, và không may đề án của bạn lọt vào tay của hãng Microsoft thì các chuyên gia hàng đầu về công nghệ thông tin trên thế giới sẽ chẳng vất vả gì mấy khi “chôm” dễ dàng kỹ thuật lập trình của bạn.

Điều 5: Nên cố gắng chỉ một lần viết thôi

Bằng cách viết mỗi thủ tục một lần, rồi kêu nó (call) từ một số vị trí khác nhau trong đoạn mã của mình, bạn đã tự giảm tối thiểu các trường hợp gây ra lỗi từ việc không nhất quán sau nhiều lần viết cùng một thủ tục xử lý. Hơn nữa, khi phải thay đổi thủ tục xử lý này, bạn cũng chỉ cần sửa đổi nó một lần mà thôi.

 

[handung107]

Điều 6: Nên xài các ô điều khiển bên thứ ba (third-party)

Bạn có thể thực hiện nhiều thứ độc chiêu với một chương trình Visual Basic. Nhưng hỡi ôi, có nhiều thủ tục xử lý lại chiếm của bạn quá nhiều thời gian để viết và để tự kiểm tra. Lúc này, bạn nên nghĩ ngay đến thế giới những ô điều khiển bên thứ ba (thirdparty controls), bao gồm các ô điều khiển không có sẵn sau khi cài đặt Visual Basic, do chính cộng đồng các “tín đồ Visual Basic” (trong đó hẳn nhiên có thể có bạn nữa) chế biến, và nhiều khi do các công ty phần mềm trong và ngoài nước viết sẵn để bán (nếu không đủ tiền mua đồ dzin của chính hãng, bạn có thể ghé các cửa hàng CD-ROM trên khắp mọi miền đất nước để được phục vụ với giá rẻ rề, mà chất lượng lại không thua kém hàng ngoại nhập, nhưng làm như dzậy thì… kỳ lắm !).

Sử dụng các ô điều khiển loại này (dưới dạng các tập tin .OCX) có thể giải quyết cực kỳ hiệu quả nhu cầu xử lý của bạn, sự tồn tại của chúng liên quan đến mọi thứ mà bạn có thể tưởng tượng ra: ô điều khiển dữ liệu (data control), ô điều khiển phân trang (tab control), ô điều khiển văn bản màu mè hoa lá cành (enhanced text box), ô điều khiển công cụ đa phương tiện (multimedia tool), ô điều khiển kiểm lỗi chính tả (spelling checker),…

Tuy nhiên, bạn nên cẩn thận khi mua một ô điều khiển bên thứ ba. Có nhiều ô điều khiển chứa đầy những lỗi, còn những anh khác thì lại không xài được cho tất cả mọi cấu hình (configuration).

Vì thế, đôi lúc bạn buộc phải đao-lốt (download) các mảnh vá (patch, là phần sửa chữa của nhà cung cấp phần mềm) về dán (hiệu chỉnh) vào những chỗ còn lỗi để chúng mần tốt hơn.

Trước khi nghĩ đến chuyện mua một ô điều khiển bên thứ ba, bạn nên dùng công cụ API Viewer có sẵn của Visual Basic để kiểm tra xem có hàm nào trong Windows API (có sẵn khi cài đặt hệ điều hành Windows, và có sẵn sau khi cài đặt Visual Basic) đáp ứng được nhu cầu của bạn không. Nếu chịu chơi, kể từ phiên bản Visual Basic 5.0, bạn có thể xăn tay áo (trừ khi không mặc áo, hoặc mặc áo ba lỗ) tự tay tạo các ô điều khiển cho chính mình.

Điều 7: Nên tận dụng các tài nguyên (resource)

Nếu bạn có những vướng mắc về một kỹ thuật đặc biệt nào đó của Visual Basic, không nên vì tự ái mà chôn kín trong lòng, bạn hãy hỏi xem các bạn của mình có ai giúp gì được không (chẳng quê đâu mà sợ, vì một ngày nào đó có thể họ sẽ cầu cứu đến bạn); hoặc là chộp lấy một tạp chí nào đấy (như e-CHÍP đây chẳng hạn); hoặc là mua lấy một quyển sách, hoặc là… leo lên mạng Internet để kêu cứu.

Nếu bạn có thể bỏ cả ngày để ngồi trên Internet tán dóc (chat) với nhiều người lạ hoắc, thì bạn hoàn toàn có đủ kiên nhẫn để tìm kiếm các tài nguyên liên quan đến Visual Basic. Có rất nhiều điểm hẹn lý tưởng mà bạn có thể ghé chân vào, như: diễn đàn www.tek-tips.com, mạng của hãng Microsoft www.microsoft.com/msdn, www.microsoft.com/kb, …

Cách tốt nhất để giữ cho mình không lạc hậu là phải luôn luôn năng động, xem những cái mà người ta đang làm để học kiến thức của họ. Biết cách tìm ra và hấp thu kiến thức của người khác có thể là một trong những vốn quý nhất của bạn đấy !

Điều 8: Nên viết cho người sử dụng ứng dụng.

Các tay lập trình thường hay quên đối tượng mà họ sẽ cung cấp ứng dụng, đó là những người sử dụng ứng dụng. Thường thì bạn sẽ viết phần mềm cho những người khác bạn về nhu cầu, tâm lý, sở thích,... đặc biệt họ lại là những người bỏ tiền ra để hưởng thành quả của bạn.

Trong khi bạn khoái tạo các biểu mẫu (form) để hiển thị các màu sắc tươi tắn, hoặc sử dụng các công nghệ mới nhất, thì người sử dụng ứng dụng lại không hài lòng. Thay vào đó, họ lại muốn ứng dụng phải theo những tiêu chuẩn chung của … họ, phải có chút hội thoại ra vẻ có hồn người một tí!…

Tốt nhất, bạn nên thiết kế phần mềm na ná các ứng dụng Windows phổ biến. Ví dụ, một người sử dụng đã quen xài Microsoft Office, họ sẽ thích nghi với ứng dụng của bạn tốt hơn.

Các thanh công cụ (toolbar), chú giải (tooltip) và phần trợ giúp sống động (online help) là một vài món ăn chơi mà người sử dụng mong đợi trong phần mềm của họ. Quên nữa, bạn nên luôn đo ni ứng dụng cho sát với công việc bằng tay mà họ làm hàng ngày. Nếu được, bạn nên chat với họ để hiểu hết các đặc điểm phần mềm mà họ cần.

Điều 9: Nên cung cấp các thông báo lỗi trực giác

Bạn đã bao giờ gặp một thông báo lỗi chung chung như vầy chưa: “Một lỗi đã xảy ra. Ứng dụng không thể khởi động được!”? Chắc cú là có rồi! Bởi vì Windows hay có những thông báo kiểu như vậy lắm. Ví dụ: “This program has performed an illegal operation and will be shut down. Quit all programs, and then restart your computer. If the problem persists, contact the program vendor.” Có trường hợp đã tiếp xúc với người bán (contact the program vendor) cả chục lần vẫn không thoát khỏi thông báo khỉ gió này được, cài đặt lại Windows hoặc… thay máy tính khác thì ổn.

Trở lại vấn đề của chúng ta, “Một lỗi đã xảy ra…”, mà là lỗi gì đây? Cách khắc phục lỗi ra sao? Nhiều dân lập trình đã mắc sai lầm khi cung cấp những thông báo lỗi na ná như vậy. Sẽ dễ chịu hơn nhiều nếu kèm theo một thông báo chung chung như thế, bạn mô tả thêm cách khắc phục tình trạng gây lỗi. Bạn nên suy nghĩ bảy lần trước khi chọn giải pháp: tốn nhiều thời gian cho việc viết các thông báo lỗi trực giác hơn, nhưng tốn ít thời gian hơn cho việc giải quyết các vấn đề cho người sử dụng. Hay ngược lại?

Bạn nên sử dụng khả năng bẫy lỗi trong các ứng dụng của mình. Đừng bao giờ cho phép chương trình của bạn bị gãy vì một lỗi lúc chạy (runtime error), hoặc ít ra có gãy thì gãy cho nó duyên dáng một tí. Ví dụ, trước khi gãy cũng ra vẻ hối hận vì điều vừa xảy ra: “Tài nghệ của tại hạ quả là còn non kém nên đã gây ra sự thể ngoài mong muốn. Mong các hạ thông cảm. Hì hì!”, rồi cho gãy bằng cách kết thúc ứng dụng.

Một ứng dụng tốt phải luôn luôn bẫy được các lỗi phổ biến, cũng như quản lý được các sự cố ngoài ý muốn.

Điều 10: Nên tự tạo cho mình một lý lịch Visual Basic.

Có lần tui hỏi chuyện một tay lập trình trẻ để giới thiệu cho anh ta một chân phát triển ứng dụng Visual Basic trong một công ty. Anh ta mang cho tui xem một vài ứng dụng Visual Basic mà anh ta đã phát triển được, kể cả các biểu mẫu và những đoạn mã nữa. Thực sự đây là điều tui chưa từng thấy trước đây.

Bạn thử hỏi câu này xem: “Tôi có nên cho một nhân viên mới xem các biểu mẫu và đoạn mã của tôi không?”. Hầu như mọi người đều sẽ trả lời: “Không bao giờ!”. Việc làm đó chẳng chứng minh được gì về cái gọi là của tôi cả.

Vì vậy, sau này khi bắt đầu hành nghề viết chương trình, cho dù bạn có là tay mới vào nghề, hay là một chuyên gia, hoặc gì gì đó giữa khoảng này, bạn nên chắc cú rằng mình sẽ phải cố gắng hết sức để chứng minh cho mọi người thấy trình độ Visual Basic của mình mà không cần cậy thế vào bất cứ gì có sẵn, hay vào bất cứ ai. Đó mới chính là bản lý lịch Visual Basic trong sáng của bạn, nó làm cho mọi người kính nể, yêu quý bạn hơn, và đến lúc đó bạn có thể tự hào về nghề nghiệp của mình.

Hầu như mọi dân lập trình Visual Basic chỉ tập trung vào việc nghiên cứu cú pháp ngôn ngữ (language syntax). Việc học cú pháp hiển nhiên là cơ bản, nhưng phải học cách để lập trình đúng.

Mười điều nêu trên có thể giúp một dân lập trình giỏi trở thành “xịn” hơn. Hy vọng rằng bạn sẽ nắm được các quy tắc này và áp dụng chúng vào các đề án sắp tới của mình. Với những quy tắc đơn giản này, bạn có thể nâng kỹ năng Visual Basic của bạn lên tầm cao hơn.

(St)

 

[hai2hai]

Điều 1: Nên có một kế hoạch cụ thể

Trước khi cùng “quậy” với Visual Basic, bạn nên bỏ chút thời gian nguệch ngoạc lên giấy một kế hoạch về đề án của mình. Đừng để môi trường phát triển ứng dụng cực nhanh của Visual Basic biến bạn trở thành một lập trình viên cẩu thả, không có hệ thống.

Bài này viết cũng được đấy. Ít nhất cũng muốn nói lên điều "Việc học cú pháp hiển nhiên là cơ bản, nhưng phải học cách để lập trình đúng." Mà việc học cách để lập trình đúng lại ko phụ thuộc vào ngôn ngữ lập trình cho lắm.