Frequently Asked Questions (Faq) VB 6.0
Một File đã được Add vào trong Project nhưng sao không thấy nằm trong
Project Folder?
Sau khi bạn dùng menu Command Project | Add File .. để cho một File ( Form hay
Module) vào trong Project, Project biết lấy File ấy từ đâu nhưng không tạo ra một bản
sao (copy) của File ấy trong Project Folder. Nếu bạn muốn có một copy của File ấy
trong Project Folder bạn phải dùng File | Save As .. để chứa File ấy trong một File
trùng tên hay có tên mới trong Project Folder.
Nhớ là có khi bạn muốn giữ chỉ một bản của một Basic Module tại một chỗ và dùng nó
trong nhiều Project. Mỗi lần muốn dùng nó trong một Project mới bạn chỉ cần Add File
nó vào trong Project nhưng không muốn làm một bản sao của nó trong Project Folder.
Lợi điểm của cách nầy là khi cần sữa một Sub trong Basic Module bạn chỉ cần sữa
một bản thôi, chớ không cần phải vô từng Project Folder để sữa.
SetUp hay Package & Deployment là gì?
SetUp là công việc gói ghém tất cả những gì cần để chạy nhu liệu áp dụng
(application software) của bạn rồi sau đó đem cài đặt lên một computer khác.
Ngày xưa trong thời Operating System DOS, để chạy một nhu liệu áp dụng ta chỉ cần
một "exe" file của nhu liệu đó và mấy cái data files. Do đó chỉ cần sao (copy) những
files ấy vào một folder trên computer khác là chạy được ngay.
Một nhu liệu VB bạn vừa viết xong thì cần nhiều thứ lỉnh kỉnh mới chạy được. Ít nhất
nó cần những VB Components ta dùng từ Toolbox và những Library cho database
..vv..
Hầu hết các files yểm trợ nầy cần phải được đặt vào folder C:\Windows\System của
computer kia. File "exe" của nhu liệu áp dụng, Help file và các data file khác thì có thể
được đặt vào một folder theo sự lựa chọn của user. Thí dụ như C:\MyProgram.
Ngoài ra một số các VB ActiveX components cần phải được đăng ký vào Registry của
Windows, và các tin tức về ODBC cűng cần được setup nữa.
Microsoft có cho ta nhu liệu Package & Deployment Wizard để giúp ta cho vào
(include) những files nào ta cần trước khi nó bắt đầu công việc nén (compress) các
files lại thành những "cab" files (file có extension là "cab") và sanh ra một SetUp.exe
file với một SetUp.lst file. Ta cần chạy file SetUp.exe ở computer kia để nó làm ba
chuyện:
1. Giản (uncompress) các Cab files ra thành những file rời.
2. Copy các files ấy vào C:\Windows\System, C:\MyProgram và những folder
nhánh của C:\MyProgram nếu cần (td: C:\MyProgra\images, C:\MyProgra\sound
..)
3. Ðăng ký những VB ActiveX vào Registry
4. Tạo ra Data Source Name (DSN) file cho ODBC nếu bạn đang dùng.
Bạn có thể dùng Notepad để mở SetUp.lst ra xem cho biết. Nó chứa những dữ kiện
cần thiết cho việc setup. Khi chạy setup xong trên computer kia bạn sẽ thấy nó sanh
ra một file mới tên "st6unst.log" nằm trong cùng folder với nhu liệu áp dụng.
Sau nầy nếu bạn muốn uninstall (lấy nhu liệu ra khỏi computer) thì vô Control Panel
và click Add/Remove Programs. Khi dialog hiện ra với Tab Install/Uninstall chọn nhu
liệu bạn muốn uninstall rồi click nút Add/Remove. Windows sẽ dựa vào st6unst.log để
biết cần delete những files nào, ở đâu và xóa tên các VB ActiveX trong Registry
(deregister).
Thường thường các "cab" files vừa vặn cở của dĩa floppy 1.44MB. Những nhu liệu VB
nhỏ chiếm ít nhất 4 dĩa floppy. Nếu bạn chạy setup từ CD có khi thấy các file original
hoặc không bị compress hoặc được compress vào một cab file duy nhất rất lớn thay vì
nhiều cab files cở 1.44MB.
Lưu ý vài điểm sau:
•Package & Deployment của Microsoft có khi không register ActiveX component
của các công ty khác (third party software companies) khi ta chạy setup. Bạn
có thể thử tự register (manually) một ActiveX tên "theVBActiveX.ocx" bằng
cách dùng Start | Run :
regsvr32 c:\Windows\System\theVBActiveX.ocx
•Nếu Package & Deployment không register được các third party ActiveX như
Crystal Report, PDQComm, TrueDBGrid .vv.. thì thử dùng Wise Installation
hay InstallShield cho việc setup. Trong khi Package & Deployment của
Microsoft dựa vào Project file để biết bạn cần những ActiveX components nào
thì Wise Installation có thể "watch" bạn chạy thử nhu liệu áp dụng để biết bạn
cần những thứ gì? Nó bắt những Windows messages để biết việc đó, giống như
công an xét giấy những người đi vào một chỗ để biết có ai trong nhà. Trong
trường hợp nầy có khi nó bắt gặp cả Antivirus ActiveX luôn, nên bạn nhớ delete
component đó.
•Khi InstallShield uninstall một nhu liệu nó vô ý remove tất cả các ActiveX
components mà lúc bạn register quên tuyên bố là "shared" (được dùng chung
cho các nhu liệu khác). Có thể các Components đó đã hiện diện và được
register từ khuya rồi. Nhưng khi InstallShield register chúng lại không nói là
"shared" nên sau nầy lúc uninstall hậu quả tai hại vô cùng.
•Khi install một version mới của nhu liệu áp dụng của bạn hãy coi chừng
overwrite Access database file trên computer kia. Lần đầu tiên khi bạn setup
thì đặt một database trống, nhưng sau đó khách hàng bắt đầu dùng và cho
nhiều dữ kiện vào database rồi. Có khi nhu liệu SetUp cho bạn option là chỉ
copy một file vào khi nó chưa hiện hữu (exist).
•Nên chạy nhu liệu áp dụng viết bằng VB6 trên WindowsNT hay Windows98
thay vì Windows95.
•Debug một nhu liệu
•Debug là sữa các lỗi lầm trong code sao cho nhu liệu xử lý OK theo ý muốn
không quá chậm hay té lên, té xuống.
Cách dễ nhất để loại trừ Bugs là ra siêu thị mua một lon thuốc hiệu Bagon hay
Mortein đem về xịt lên code.
Nói cho cùng, debug chẳng qua là giai đoạn sau cùng của công tác thảo
chương mà thôi. Do đó, để công việc debug được nhẹ nhàng ta phải lưu ý đến
cả những giai đoạn trước đó trong chu kỳ phát triển nhu liệu.
•Trước hết, giả sử ta biết rõ và chính xác mình cần phải làm gì (Requirements
Specification).
Trong giai đoạn thiết kế phải đặt ngay kế hoạch sẽ thử code cách nào, khi nào
và ở đâu. Lưu ý là hể ta bỏ qua việc kiểm soát chỗ nào, nhu liệu sẽ té (crash) ở
chỗ đó. Không có gì ngao ngán bằng sở đánh thức mình nửa đêm vì nhu liệu
thiết yếu phải chạy 24 trên 24 tiếng của ta vừa mới té một cái ạch. Dĩ nhiên,
không ai dám nổi nóng với chúng ta vì họ tùy thuộc vào mình, nhưng làm việc
dưới áp lực như thế ta cần phải tránh càng nhiều càng tốt.
•Có một số lề lối căn bản (basic guideline) về debug:
1. Ðặt kế hoạch Test thật chI tiết. Nghĩ đến mọi trường hợp như user không biết
cách dùng, hoặc dữ kiện bị hư (invalid) .vv.. Nếu cần thử Propotype ( mẫu) thì
nên thực hiện càng sớm càng tốt để yên tâm là sau nầy code sẽ đạt đúng tiêu
chuẩn thiết kế.
2. Sau khi code xong lần đầu, nhớ kiểm lại bằng cách đọc từng dòng (gọi là
Desk Check). Ðừng xem Clean Compilation (compile không bị Syntax error) là
hay ho gì rồi lập tức chạy thử ngay. Tốt nhất là cắt nghĩa cho một partner hiểu
code mình viết (gọi là Walk through). Desk Check là cách chu đáo nhất để
kiểm Logic, vì nhiều khi ta không thể nào khám phá ra một lỗi trong logic bằng
cách thử bình thường.
3. Giữ cho code gọn gàng, dễ hiểu và chú thích rõ ràng. Hãy nhớ rằng trong
tương lai người bảo trì code sẽ rủa bạn nếu code bạn viết quá bí hiểm mà
không giải thích. Mỗi Variable đều cần phải được đặt tên hợp lý, cẩn thận. Ở
đầu mỗi Sub hay Function giải thích mục đích của routine, Input là gì, Output là
gì, có dùng kỹ thuật lập trình đặt biệt gì không. Bên trong Sub /Function giải
thích từng bước việc xử lý trừ khi quá hiển nhiên. Mỗi Logical Test Condition
đều phải được thử, chớ bỏ qua câu nào vì nghĩ rằng nó quá đơn giản. Ðể
breakpoint ở những chỗ ấy để kiểm value của các variables xem đó đúng như
đã định không.
4. Luôn luôn dùng Option Explicit trong mỗi Form/Module và tránh Declare
Variables bừa bãi. Giảm thiểu việc dùng Global Variables để ít bị ngạc nhiên
không biết process nào đã thay đổi value của variable bạn đang dùng. Nếu
phải làm đi làm lại một chuyện thì có lẽ bạn có thể thay thế nó bằng một
Sub/Function. Nếu hai Objects làm nhiều chuyện tương tự thì xem có thể gói
các Sub/Functions và Data Variables thành một Class không.
5. Trong mỗi Sub/Function đều nên có Error Handler để khám phá ngay bất
trắc. Chỉ nên để câu 'On Error Resume Next' sau khi đã debug xong xuôi và
biết chắc có thể bỏ qua trường hợp gặp error trong tương lai.
6. Nếu phần code bạn viết sẽ được ráp vào một phần khác thì test chỗ ráp
nhau (interface) bằng cách kiểm các Output Values của code bạn và Emulate
(giả bộ cho vào) Input Values từ phần code kia. Nếu cần làm Stress Test (cho
nhiều chuyện xãy ra xem code có chạy nhanh đủ và đúng không) thì nên thực
hiện càng sớm càng tốt.
7. Test nhu liệu trên một computer với MSWindows vừa cài đặt và không có gì
khác, ngay cả Antivirus, để khỏi phải nhức đầu vô lý khi nguyên nhân code gặp
khó khăn là vì mất Windows DLL hay bị nhu liệu Antivirus can thiệp.
Và sau cùng, giữ bình tỉnh, đừng nổi nóng với chính bạn hay với ai khác. Hãy
nhớ rằng bạn là một Professional, thả lỏng (relax) và giữ đầu óc mình minh
mẩn. Nếu hoàn cảnh bi đát quá thì hãy bắt chước tôi - cầu nguyện xin Chúa
giúp đở.
•
•Các giai đoạn trong chu kỳ phát triển một nhu liệu (Development Cycle)
•Ðại khái các giai đoạn chính của chu kỳ phát triển một nhu liệu là:
1. Muốn làm gì? (Requirement Specifications): Giai đoạn nầy khách hàng
bàn với software consultant để bài tỏ nguyện vọng của mình. Khách hàng chỉ
nói tổng quát, consultant phải phỏng vấn nhiều người trong sở để có một hình
ảnh đầy đủ về vấn đề.
2. Thiết kế (Design) : Từ Requirement Specifications bước qua giai đoạn Thiết
kế. Lúc nầy sẽ thấy có nhiều điểm không được nêu rõ trong Requirement
Specifications nên cần làm cho sáng tỏ (clarification). Công việc nầy do
Systems Analyst thực hiện. Nếu dự án lớn thì có Software Architect thiết kế
tổng quát trước khi chia ra các Team Leaders ( thường thường là Systems
Analysts). Trong giai đoạn nầy có khi phải làm Prototype (thử mô hình mẫu) để
biết chắc kỹ thuật mình dùng có đủ khả năng và thích hợp với nhu cầu dự án
không.
Thiết kế là giai đoạn quan trọng nhất trong chu kỳ phát triển một nhu liệu.
Chẳng những ta nghĩ cách xây dựng nhu liệu, mà còn kế hoạch chi tiết cách
thử lúc nào, ở đâu trong code. Ta phải tưởng tượng mọi cảnh huống bất thường
(unusual scenarios) nhưng có thể xãy ra để liệu cách đối phó.
3. Thảo chương (Coding hay Implementation): Ðây là giai đoạn thảo
chương và debug. Trong phần Debug thì có Unit Test (thử từng bộ phận) và
Integration Test (thử chung). Mỗi khi có sữa đổi một chút thì phải thử lại nhiều
thứ nên nếu có thể viết Test Script để tự động hóa công việc thử nầy ( gọi là
Regression Test) thì tiết kiệm rất nhiều thì giờ. Nếu nhu liệu phải phản ứng
nhanh chóng (good response) trong khi chạy Real-time thì phải thử nó trong
hoàn cảnh phải giải quyết nhiều thỉnh cầu cùng một lúc (gọi là Stress Test).
4. Chạy thử (Acceptance Test): Ở tại sở của khách hàng, Software consultant
chứng kiến các giai đoạn chạy thử để xem nhu liệu xử lý mọi chuyện đúng như
liệt kê trước đây. Các công chuyện xử lý chạy có nhanh đủ không, nhất là trong
trường hợp nhu liệu phải giải quyết rất nhiều thỉnh cầu cùng một lúc. Trong
những hoàn cảnh bất bình thường, nhu liệu có đứng vững không. Nếu dự án
lớn, trước Acceptance Test còn có thêm một giai đoạn gọi là Factory Test khi
Software Consultant đến tận công ty ta để chứng kiến ta chạy thử.
5. Cho dùng (Commissioning, Roll-Out): Khi cho dùng rồi là bắt đầu giai
đoạn Bảo đảm (Warranty) và Bảo trì (Maintenance). Bảo trì là thăm viếng lại
nhu liệu để chửa trị Bug (fixing bugs) hay sữa đổi (modification) hay làm thêm