Khóa Hàm Th Visual Basic 6.0
Chương Chín - Debug
Bugs là nhng li lm ca program mà ta phát hin khi chy nó. Debug
là công vic loi tt c nhng li lm trong chương trình để nó chy êm
xuôi trong mi hoàn cnh.Thông thường mun fix mt cái bug nào trước
hết ta phi tìm hiu lý do khiến nó xut hin. Mt khi đã biết được duyên
c ri ta s nghĩ ra cách gii quyết. Nói chung, có hai loi bugs:
1. Hoc là program không làm đúng chuyn cn phi làm vì
programmer hiu lm Specifications hay được cho tin tc sai lc,
hoc là program b sót chi tiết cn phi có. Trường hp ny ta gii
quyết bng cách gim thiu s hiu lm qua s nâng cp kh năng
truyn thông.
2. Program không thc hin đúng như ý programmer mun. Tc là
programmer mun mt đàng mà bo chương trình làm mt ngã vì
vô tình không viết lp trình đúng cách. Trường hp ny ta gii quyết
bng cách dùng nhng Software Tools (k c ngôn ng lp trình)
thích hp, và có nhng quá trình làm vic có h thng.
Trong hãng xe hơi người ta dùng t Quality Control để nói đến vic chế
ra chiếc xe không có li lm gì c. Để đạt mc tiêu y, chng nhng cn
có người kim phm mà chính các nhân viên lp ráp thn trng để công
vic chính ca người kim phm là xác nhn kết qu tt ch không phi
tìm li lm.Có nhiu yếu t nh hưởng đến cht lượng ca mt program
như chc năng ca program, cu trúc ca các b phn, k thut lp trình
và phương pháp debug. Debug không hn nm giai đon cui ca d án
mà tùy thuc rt nhiu vào các yếu t k trước trong mi giai đon trin
khai.
Chc năng ca chương trình (Program Specifications)
Du program ln hay nh, trước hết ta phi xác nhn rõ ràng và t m
cn phi làm gì, bao nhiêu người dùng, mng như thế nào, database ln
bao nhiêu, phi chy nhanh đến mc nào .v.v..Có nhiu chương trình phi
b thay đổi na chng vì programmers hiu lm điu khách hàng mun.
Kh nht là lúc gn giao hàng mi khám phá ra có nhiu đim trong
chương trình khách mun mt đàng mà ta làm mt ngã. Do đó trong s
liên h vi khách hàng ta cn phi hi đi, hi li, phn hi vi khách hàng
nhiu ln điu ta hiu bng thư t, tài liu, để khách xác nhn là ta biết
đúng ý h trước khi xúc tiến vic thiết kế chương trình. Nếu sau ny khách
đổi ý, đó là quyn ca h, nhưng h phi tr tin thay đổi (variation).
Cu trúc các b phn
Program nào cũng có mt kiến trúc tương t như mt căn nhà. Mi b
phn càng đơn gin càng tt và cách ráp các b phn phi như thế nào để
ta d th. Trong khi thiết kế ta phi biết trước nhng yếu đim ca mi b
phn nm đâu để ta chun b cách th chúng. Ta s không h tin b
phn nào hoàn ho cho đến khi đã th nó, dù nó đơn sơ đến đâu.Nếu ta
mun dùng mt k thut gì trong mt hoàn cnh nào mà ta không biết
chc nó chy không thì nên th riêng r nó trước. Phương pháp y được
gi là Prototype. Ngoài ra, ta cũng nên kế hoch cho nhng trường hp
bt ng, đin hình là bad data - khi user bm lung tung hay database
cha rác rến. Nếu chương trình chy trong real-time (tc là data thu
nhp qua Serial Comm Port, Data Acquisition Card hay mng), bn cn
phi lưu ý nhng trường hp khác nhau tùy theo vic gì xy ra trước, vic
gì xy ra sau. Lúc by gi Logic ca chương trình s tùy thuc vào trng
thái (State) ca data. Tt nht là nghĩ đến nhng Scenarios (din tiến
ca nhng hoàn cnh) để có th th tng giai đon và tình hung.Ngày
nay vi k thut Đối Tượng, giai đon thiết kế ny là lúc quyết định các
Data Structures (tables, records ..v.v.) và con s Forms vi Classes. Nh
rng mi Class gm có mt Data Structure và nhng
Subs/Functions/Properties làm vic (operate) trên data y. Data structure
phi cha đầy đủ nhng chi tiết (data fields, variables) ta cn. Kế đó là
nhng cách chương trình process data. Subs/Functions nào có th cho bên
ngoài gi thì ta cho nó Public, còn nhng Subs/Functions khác hin hu
để phc v bên trong class thì ta cho nó Private.
K thut lp trình
Căn bn ca programmers và các thói quen ca h rt quan trng. Nói
chung, nhng người hp tp, nhy vào viết chương trình trước khi suy
nghĩ hay cân nhc chính chn thì sau ny bugs lòi ra khp nơi là chuyn
t nhiên.
Dùng Subs và Functions
Nếu giai đon thiết kế kiến trúc ca chương trình ta chia ra tng Class,
thì khi lp trình ta li thiết kế chi tiết v Subs, Functions .v.v.., mi th s
cn phi th như thế nào. Nếu ta có th chia công vic ra tng giai đon
thì mi giai đon có th mà mt call đến mt Sub. Th gì cn phi tính ra
hay ly t nơi khác thì có th được thc hin bng mt Function. Thí d
như công vic trong mt tim git i có th gm có các bước sau:
1. Nhn hàng
2. Phân chia tng loi
3. Ty
4. Git
5. i
6. Vô bao
7. Tính tin
8. Giao hàng
Trong đó các bước 1,2,6 và 8 có th là nhng Subs. Còn các bước 3,4,5 và
7 nhng Functions, thí d như khi ta giao cho Function Git mt cái áo
dơ ta s ly li mt cái áo sch.Nh rng đim khác bit chính gia mt
Sub và mt Function là Function cho ta mt kết qu mà không làm thay
đổi nhng parameters ta đưa cho nó. Trong khi đó, du rng Sub không
cho ta gì mt cách rõ ràng nhưng nó có th thay đổi tr s (value) ca bt
c parameters nào ta pass cho nó ByRef. Nhc li là khi ta pass mt
parameter ByVal cho mt Sub thì ging như ta đưa mt copy (bn sao)
ca variable đó cho Sub, Sub có th sa đổi nó nhưng nó s b b qua,
không nh hưởng gì đến original (bn chính) variable.Ngược li khi ta
pass mt parameter ByRef cho mt Sub thì ging như ta đưa bn chính
ca variable cho Sub để nó có th sa đổi vy.Do đó để tránh trường hp
vô tình làm cho tr s mt variable b thay đổi vì ta dùng nó trong mt
Sub/Function bn nên dùng ByVal khi pass nó như mt parameter vào
mt Sub/Function.Tht ra, bn có th dùng ByRef cho mt parameter pass
vào mt Function. Trong trường hp đó dĩ nhiên variable y có th b sa
đổi. Điu ny gi là phn ng ph (side effect), vì bình thường ít ai làm
vy. Do đó, nếu bn tht s mun vượt ngoài qui ước thông thường thì
nên Comment rõ ràng để cnh cáo người s đọc chương trình bn sau
ny.Ngoài ra, mi programmer thường có mt Source Code Library ca
nhng Subs/Functions ưng ý. Bn nên dùng các Subs/Functions trong
Library ca bn càng nhiu càng tt, vì chúng đã được th nghim ri.
Đừng s Error
Mi khi chương trình có mt Error, hoc là Compilation Error (vì ta viết
code không đúng văn phm, ng vng), hoc là Error trong khi chy
chương trình, thì bn không nên s nó. Hãy bình tĩnh đọc cái Error
Message để xem nó mun nói gì. Nếu không hiu ngay thì đọc đi đọc li
vài ln và suy nghim xem có tìm được mách nước nào không. Ngh
programming ca chúng ta s gp Errors như ăn cơm ba, nên bn phi
tp bình tĩnh đối din vi chúng.
Dùng Comment (Chú thích)
Lúc viết code nh thêm Comment đầy đủ để bt c khi nào tr li đọc
đon code y trong tương lai bn không cn phi da vào tài liu nào khác
mà có th hiu ngay lp tc mc đích ca mt Sub/Function hay đon
code.Như thế không nht thiết bn phi viết rt nhiu Comment nhưng h
đim nào khác thường, bí him thì bn cn thông báo và gii thích ti
sao bn làm cách y. Có th sau ny ta khám phá ra đon code có bugs;
lúc đọc li có th ta s thy du rng ý định và thiết kế đúng nhưng cách
lp trình có phn thiếu soát chng hn.Tính ra trung bình mt
programmer ch làm vic 18 tháng mi ch. Tc là, gn như chc chn
code bn viết s được người khác đọc và bo trì ( debug và thêm bt). Do
đó, code phi càng đơn gin, d hiu càng tt. Đừng lo ngi là chương
trình s chy chm hay chiếm nhiu b nh, vì ngày nay computer chy
rt nhanh và b nh rt r. Khi nào ta tht s cn phi quan tâm v vn
tc và b nh thì điu đó cn được thiết kế cn thn ch không phi da
vào nhng tiu xo v lp trình.
Đặt tên các variables có ý nghĩa
Kh nht là làm vic vi các variables có tên vn tt như K, L, AA, XY. Ta
không có mt chút ý nim chúng là ai, hin hu để làm gì. Thay vào đó,
nếu ta đặt các tên variables như NumberOfItems, PricePerUnit, Discount
.v.v.. thì s d hiu hơn.Mt trong nhng bugs khó thy nht là ta dùng
cùng mt tên cho local variable (variable declared trong Sub/Function)
global variable (variable declared trong Form hay Basic Module).
Local variable s che đậy global variable cùng tên, nên nếu bn mun nói
đến global variable trong hoàn cnh y bn s dùng lm local variable.
Dùng Option Explicit
Bn nên trung tín dùng Option Explicit đầu mi Form, Class hay
Module. Nếu có variable nào đánh vn trt VB6 IDE s cho bn biết ngay.
Nếu bn không dùng Option Explicit, mt variable đánh vn trt được xem
như mt variable mi vi giá tr 0 hay "" (empty string).Nói chung bn
nên thn trng khi assign mt data type cho mt variable vi data type
khác. Bn phi biết rõ bn đang làm gì để khi b phn ng ph (side
effect).
Desk Check
Kim li code trước khi compile. Khi ta compile code, nếu không có error
ch có nghĩa là Syntax ca code đúng, không có nghĩa là logic đúng. Do đó
ta cn phi biết chc là code ta viết s làm đúng điu ta mun bng cách
đọc li code trước khi compile nó ln đầu tiên. Công vic ny gi là Desk
Check (Kim trên bàn). Mt chương trình được Desk Checked k s cn ít
debug và cha ít bugs không ng trước. Lý do là mi scenarios đã được
tiên liu chu đáo.
Son mt Test Plan
Test Plan lit kê tt c nhng gì ta mun th và cách th chúng. Khi th
theo Test Plan ta s khám phá ra nhng bug và tìm cách loi chúng ra. H
sơ ghi li lch s ca Test Plan (trc trc gì xy ra, bn đã dùng bin pháp
nào để gii quyết) s b ích trên nhiu phương din. Ta s hc được t
kinh nghim Debug và biết rõ nhng th trong d án đã được th theo
cách nào.
X lý Error lúc Run time
Khi EXE ca mt chương trình viết bng VB6 đang chy, nếu gp Error, nó
s hin th mt Error Dialog cho biết lý do vn tc. Sau khi bn click OK,
chương trình s ngưng. Nếu bn chy chương trình trong VB6 IDE, bn có
dp bo program ngng trong source code ch có Error bng cách bm
button Debug trong Error Dialog. Tiếp theo đó bn có th tìm hiu tr s
các variables để đoán nguyên do ca Error. Do đó, nếu bn bt đầu cho
dùng mt program bn viết trong s, nếu tin thì trong vài tun đầu, thay
gì chy EXE ca chương trình, bn chy source code trong VB6 IDE. Nếu
có bug nào xy ra, bn có th cho program ngng trong source code để
debug.Khi bn dùng statement: On Error Resume Nextthì t ch đó
tr đi, nếu chương trình gp Error, nó s b qua (ignore) hoàn toàn. Đim
ny tin ch giúp chương trình EXE ca ta tránh b té cái ch ri biến
mt, rt là "quê" vi khách hàng. Nhưng nó cũng bt li là khi khách hàng
cho hay h gp nhng trường hp l, không gii thích được (vì Error b
ignored mà không ai để ý), thì ta cũng bí luôn, có th không biết bt đầu
t đâu để debug. Do đó, dĩ nhiên trong lúc debug ta không nên dùng nó,
nhưng trước khi giao cho khách hàng bn nên cân nhc k trước khi dùng.
Dùng Breakpoints
Cách hay nht để theo dõi execution ca program là dùng Breakpoint để
làm cho program ngng li mt ch ta mun trong code, ri sau đó ta
cho program bước tng bước. Trong dp ny ta s xem xét tr s ca
nhng variables để coi chúng có đúng như d định không.Bn đoán trước
execution s đi qua ch nào trong code, chn mt ch thích hp ri click
bên trái ca hàng code, ch du chm tròn đỏ như trong hình dưới đây:
Nếu bn click lên du chm tròn đỏ mt ln na thì là hy b nó. Mt cách
khác để đặt mt breakpoint là để editor cursor lên hàng code ri bm F9.
Nếu bn bm F9 ln na khi cursor nm trên hàng đó thì là hy b break
point.Lúc program đang dng li, bn có th xem tr s ca mt variable
bng cách để cursor lên trên variable y, tooltip s hiên ra như trong hình
dưới đây:
Có mt s chuyn khác bn có th làm trong lúc ny. Bn có th nm du
chm tròn đỏ kéo (drag) nó ngược lên mt hay nhiu hàng code để nó s
execute tr li vài hàng code. Bn cho program execute tng hàng code
bng cách bm F8. Menu command tương đương vi nó là Debug | Step
Into. S có lúc bn không mun program bước vào bên trong mt