text:
Trí huệ là gì?
Thích Nhất Chân
Theo đạo Phật, không bao giờ có tâm thức hoạt động mà lại
không có cảnh hay đối tượng. Đạo Phật chia thức ra làm sáu lãnh vực giới hạn bởi
sáu căn (mắt, tai, mũi, lưỡi, thân và ý) và sáu cảnh đối tượng (sắc, thanh,
hương, vị xúc và pháp mà thành ra sáu thức).
Sáu thức này lấy chỗ y cứ là sáu căn nên theo sáu căn mà đặt
tên là thức y nơi mắt (nhãn thức), thức y nơi tai (nhĩ thức), thức y nơi mũi (tỉ
thức), thức y nơi thân (thân thức) và thức y nơi ý (ý thức).
Tâm thức có để làm gì? Để tiếp nhận và phân biệt sáu cảnh. Do
đó không thể có một tâm thức thuần túy trống không, không có cảnh hay đối tượng
gì hết. Nhưng trong sáu thức ấy tính chất phân biệt hầu như không có tác dụng gì
nơi năm thức đầu, mà phân biệt dường như là thức. Và vì trong các kinh luận (tiểu
thừa) chỉ chấp nhận có sáu thức mà thôi, thế nên hầu như toàn thể mọi hoạt động
của tâm đều tùy thuộc vào ý thức. Trong khi thân chỉ trực tiếp đón nhận lấy hình
tướng của năm cảnh sắc, thanh, hương, vị, xúc mà thôi, thì việc phân biệt tốt
hay, xấu đẹp, phải trái, đúng sai để rồi khởi lên mọi thứ tâm sở hoặc ác là phần
vụ của ý thức.
Ý thức không những phân biệt rất mạnh về cảnh ngay hiện tại mà còn nhớ lại các
cảnh thuộc quá khứ, mơ ước các cảnh trong tương lai cũng rất mãnh liệt. Nói tóm
lại, cái tâm không ngớt suy nghĩ tứ tung, không ngừng phân biệt ta người của
chúng ta chính là ý thức vậy.
Hoạt động của tâm thức nói chung được đánh giá theo ba lãnh
vực: đức lý, thanh tịnh và Trí huệ mà chúng ta vẫn gọi là tam học: Giới, Định,
Huệ. Trong ba lãnh vực này, Định thuộc về phương diện kỹ thuật tôi luyện tâm cho
thanh tịnh nhằm đặt đến Huệ. Và vì Trí Huệ là cứu cánh, cho nên Định là phương
tiện quan trọng bậc nhất để đạt đến Trí Huệ.
Nhưng Trí Huệ là gì đây? Trước hết phải hiểu rằng Trí huệ là thuộc về tâm thức (các
nhà A Tỳ Đàm coi Huệ là một tâm sở). Mà tâm thức thì phải có đối tượng. Vậy đối
tượng của Trí Huệ là gì?
Chúng ta đã biết đối tượng của tâm thức là sáu cảnh sắc,
thanh, hương vị xúc và pháp. Vậy trong sáu cảnh ấy, cảnh nào là đối tượng của
Trí huệ? Lại nữa trong sáu thức thời Trí huệ thuộc thức nào? Nếu bảo rằng đối
tượng của Trí huệ là một cảnh nào đó trong sáu cảnh thì hóa ra Trí huệ không phổ
cập và phổ biến khắp các cảnh, tức không biết hết các cảnh, vậy thì sao là Trí
huệ được. Nếu cho rằng sáu cảnh đều không phải là đối tượng của Trí huệ, vậy Trí
huệ là một tâm thức không có đối tượng. Một tâm thức như thế không thể có được,
mà có đi nữa thì cũng hoàn toàn ngu ngơ, không biết gì hết, có khác gì vật vô
tri, sao gọi là Trí huệ được.
Lại trong sáu thức nếu Trí huệ chỉ thuộc về một thức thôi thì
cái biết của Trí huệ cũng không phổ cập hết, sao gọi là Trí huệ được. Nếu Trí
huệ không thuộc về thức nào hết, thì hóa ra Trí huệ không phải là tâm nữạ Điều
này trái với giáo lý của đạo Phật.
Thế nên phải hiểu rằng đối tượng của Trí huệ phải là tất cả các cảnh, thức saú
cảnh; và Trí huệ phải là một tâm sở có mặt và hoạt động khắp sáu thức.
Nhưng nếu thế thì Trí huệ có khác gì sáu thức đâu? Và nếu ai
có sáu thức tức là có Trí huệ đó hay sao? Vậy thì Phật và phàm phu có gì khác
nữa đâu?
Tuy đối tượng của sáu thức và của Trí huệ đều là sáu cảnh.
Song sự nhận biêõt cảnh theo xu hướng nghiệp riêng biệt của nó. Như thức loài
người biết nước là nước, thức loài cá biết nước là chỗ ở, thức ngạ quỉ biết nước
là lửa, thức chư thiên biết nước là lưu li. Còn Huệ nhận biết là nhận biết về sự
thật, về thật tướng của các cảnh. Sáu cảnh sắc, thanh, hương, vị, xúc, pháp đề
có sự thật là vô thường, là khổ, là vô ngã (theo giáo lý tiểu thừa), là KHÔNG,
là duy thưõc, duy tâm, là pháp thân, là chân như ... (theo giáo lý đại thừa).
Tóm lại cảnh hay đối tượng của Trí huệ là chân lý của tất cả các pháp được thâu
nhiếp trong sáu lãnh vực sắc, thanh, hương, vị xúc và pháp.
Lại nữa tuy Huệ là một tâm sở, thuộc về cả sáu thức, song Huệ
vẫn là một hoạt động rất đặc biệt của tâm thức mà không phải hễ cứ có tâm thức,
có đủ sáu thức là có thể nói là có Huệ được. Trước hết trong sáu thức thời ý
thức thể hiện rõ tính chất của huệ hơn hết. Tính chất ấy chính là khả năng phân
biệt và biết suy luận của ý thức. Năm thức đầu thuộc mắt, tai, mũi, lưỡi, thân
không có khả năng phân biệt và suy luận như ý thức mà chỉ nhận biết các cảnh một
cách trực tiếp theo cảm quan. Thế nên khi Trí Huệ phản ảnh qua sáu thức này nó
thể lộ ra hai phương diện thuộc tác dụng của nó: một phương diện trực tiếp thân
chứng vô phân biệt, tức là năm thức đầu khi được Trí huệ hóa; một phương diện
nữa gián tiếp qua suy luận phân biệt chính xác và tương ưng với sự thật, tức
thuộc thức thứ sáu ý thức khi được Trí huệ hóa.
Chân lý của sự vật, tức tất cả các pháp nhiếp trong sáu cảnh,
cũng theo đó mà được thể nhận ra qua hai phương diện trên của Huệ. Chân lý được
chứng qua phương diện trực tiếp vô phân biệt của Huệ thuộc năm thức đầu là thật
tướng, là đệ nhứt nghĩa (paramārtha) của các pháp, và chân lý được thấy qua
phương diện gián tiếp có phân biệt suy lý, lập luận, trình bày, giảng giải của
Huệ thuộc ý thức (Duy thức học gọi hai phương diện này là căn bổn trí và hậu đắc
trí).
Như thế cho thấy Huệ là một năng lực nhận biết của toàn thể
tâm thức (tức là cả sáu thức) tương ưng với chân lý của toàn thể mọi sự vật.
Đồng thời Huệ cũng trở thành phương tiện duy nhất thật sự có giá trị để đạt đến
chân lý của sự vật. Và như vậy là có đến hai phương tiện trực tiếp và gián tiếp
để đạt đến chân lý đều thuộc về Trí Huệ.
Đa số người Phật tử hiểu lầm, nghe nói đến Trí huệ thời chỉ
biết lờ mờ là vô phân biệt gì đó, hoặc đừng chấp tướng, hay phá chấp này nọ và
hễ cứ nghe lý luận, nói năng trình bày là cho là thế trí, chấp ngôn ngữ, chưa
chứng... nhưng nếu ngay chính Đức Phật mà cứ vô phân biệt, không nói năng không
trình bày, thì Phật có đó có ích gì và có khác gì một khúc gỗ đâu, và làm sao để
cho mọi người đả thông được để thể nhập vào chân lý đây? Sự giác ngộ của Đức
Phật không phải chỉ để giác ngộ mà là để độ chúng sanh, Phật dùng vô phân biệt
trí để chứng ngộ thật tướng chân thật của vạn pháp không phải để vô phân biệt,
mà là để phân biệt giảng nói cho chúng sinh sáng tỏ. Tâm giác ngộ là cả sáu thức
đều giác ngộ, chứ không phải chỉ có năm thức đầu vô phân biệt còn thức thứ sáu
tức ý thức thì bỏ đi vì bản chất của nó là phân biệt. Trái lại khi tâm giác ngộ
thể hiện ra qua năm thức thì thành ra vô phân biệt và khi thể hiện qua thức thứ
sáu thì thành ra là phương tiện trí (nói theo đại thừa), bởi vì chính nhờ cái
khả năng phân biệt ấy làm phương tiện nên Đức Phật mới độ được chúng sanh bằng
caõch phân biệt thuyết pháp cho chúng sanh được ngộ nhập và chân lý.
Lại nữa, tuy ở trên phân tích cho thấy Trí huệ có hai tác
dụng trực tiếp nhận thức và gián tiếp suy luận về chân lý. Hai tác dụng này như
trên đã nói tương ưng với năm thức cảm quan và ý thức phân biệt. Song hầu như
chính cái tác dụng gián tiếp suy luận của ý thức mới đóng vai trò chính và chi
phối luôn cả hai mặt của Trí huệ. Nghĩa là phân biệt mới là chính là toàn thể
Trí huệ chứ không phải là vô phân biệt. Tại sao vậy?
Như đã nói một tâm thức thời
phải có đối tượng, nếu không có đối tượng thời tâm thức sẽ diệt mất. Trí huệ là
tâm thức, nên Trí huệ phải có đối tượng và ở đây đối tượng là chân lý đệ nhứt (paramārtha).
Theo tiểu thừa chân lý ấy là Niết bàn (nīrvāna), theo đại thừa thời là tính
KHÔNG, cả hai đều lý tưởng tuyệt ngôn, cả hai đều không thuộc vào lãnh vực của
có. Nếu thế đối tượng của Trí huệ không phải là một cái gì có thuộc về hoặc sắc
hoặc thanh, hương, v.v... Nếu đối tượng không có thì đâu còn có tâm thức nào
hiện khởi nữa để mà gọi là Trí huệ. Điều này không phải là lạ gì trong giáo lý
đại thừa, những danh từ như vô phân biệt, vô tâm, vô niệm, tuyệt lự hoặc các
phương châm như vô tâm tiện thị Đạo (vô tâm chính là Đạo), ngôn ngữ đạo đoạn,
tâm hành xứ diệt (trừ hết mọi ngôn từ, diệt hết mọi trạng thái tâm) Đối cảnh mạc
sinh tâm (đối cảnh đừng sinh tâm)... đều cho thấy sự xác nhận cảnh giới không có
tâm (hay ít ra là ý thức phân biệt) nữa mới là đạo, là chân lý cứu cánh.
Trên phương diện lý luận cảnh
giới vô tâm hết sức phi lý. Tại sao? Vì phải không có đối tượng thì tâm đâu còn
có đó nữa để mà gọi là chân lý.
Nếu bảo rằng không có đối tượng nữa thì cái còn lại là tâm và
chính tâm này là chân lý. Nhưng nếu không có đối tượng thì tâm đâu còn có đó nữa
để mà gọi là chân lý.
Nếu lại nói rằng ở đây cái không có là không có tâm (nên mới
nói là vô tâm, vô phân biệt) chứ không phải là không có cảnh. Một khi vô tâm rồi
thì chính cảnh ấy là đạo, là chân lý. Song nếu đã không có tâm thì lấy gì để
biết là có cảnh, để trực nhận rằng đó là Đạo hay chân lý đây? Thế nên tâm diệt
thì cảnh cũng diệt theo.
Do đó, nếu cảnh đã là Niết bàn tịch diệt, là KHÔNG, thì làm
gì có Trí huệ hay bất cứ một thứ tâm nào nữa. Mà nếu đã vô phân biệt thì lấy gì
để nhận ra (để giác ngộ ra) rằng đối tượng kia là Niết bàn, là tính KHÔNG. Như
vậy đủ thấy kinh nghiệm về chân lý tuyệt đối (như vô phân biệt, tính không...)
chỉ là một cách nói, trên mặt luận lý thời hoàn toàn nghịch lý. Lại nữa đã vô
tâm và vô cảnh thì dựa vào đâu để mà lập nghĩa là lập danh và chân lý, là Đạo?
Phải chăng như vậy là hoàn toàn không có một kinh nghiệm thật sự nào hết về chân
lý của sự vật, nghĩa là thật sự không thể nào có được một cảnh KHÔNG, hay một
trạng thái tâm vô phân biệt gọi là giác ngộ?
Xin trả lời có, có giác ngộ, có một kinh nghiệm thật sự về
tính KHÔNG và Niết bàn, chân lý của sự vật. Đức Phật và chư tổ sư thường nhắc
nhở chúng ta đừng hiểu các danh xưng như KHÔNG là đoạn diệt, không có gì hết,
đừng nghĩ vô tâm, vô phân biệt là trơ trơ như gỗ đá, Đức Phật bảo dừng giải
thích về Niết Bàn, vì mọi giải thích đều sai. Niết bàn là tịch diệt, song không
hề phải là đoạn diệt.
Để tỏ rõ vấn đề trên, chúng
ta phải nên hiểu rằng tâm thức tuy có sáu lãnh vực khác nhau, song vẫn là một
tòan thể bất khả phân ly. Thế nên nơi năm thức cảm quan đầu không thể thiếu ý
thức phân biệt được. Các nhà A Tỳ Đàm gọi loại ý thức này là "ngũ câu thức"
nghĩa là ý thức cùng khởi với năm thức cảm quan. Một khi năm thức khởi lên là ý
thức khởi theo ngay liền mà phân biệt. Nên tuy bản chất của năm thức cảm quan là
trực tiếp nhận cảnh. Song trong thái độ trực tiếp ấy đã có sẵn thái độ phân biệt
suy luận gián tiếp của ý thức rồi. Thế nên mọi kinh nghiệm trực tiếp đều được ý
thức, được nhận ra là gì (tức phân biệt), được ghi nhận ý nghĩa, và được cho
danh xưng.
Trí huệ cũng vậy, khi thể hiện ra quan năm thức cảm quan như
là vô phân biệt trí, thì đồng thời phân biệt trí đã thể theo "ngũ câu thức" sẵn
sàng ngay đó để nghi nhận ngay lấy cái kinh nghiệm vô tâm, bô ngôn tuyệt lự, vô
cảnh, vô tướng là gì và như thế nào rồi?
Phải nên hiểu rằng cái kinh nghiệm vô phân biệt không nên được hiểu một cách
ngây thơ là không có phân biệt, không có ý thức, không có tâm, không có suy nghĩ
gì hết ... mà chính là trạng thái ý thức phân biệt đi sát với năm thức cảm quan
để thấy ra được cái kinh nghiệm trực tiếp của năm thức cảm quan đối với sự vật
như chính sự vật là (yathābhūta), tức chân lý của sự vật.
Phân biệt kỹ hơn, chúng ta sẽ thấy toàn thể tâm thức của
chúng ta có một phần không phân biệt luôn luôn trực tiếp liên hệ chặt chẽ với
chân lý của sự vật, đó là năm thức cảm quan. Năm thức này trình diện toàn thể sự
thật của sự vật ra trước ý thức cho ý thức phân biệt. Ý thức là phần đón nhận,
đánh giá và thưởng thức các sự vật của tâm thức, tức thuộc phần phân biệt của
tâm thức. Phần ý thức là phức tạp hơn hết: một mặt nó đi sát cùng với năm thức
cảm quan để nhận diện các sự vật đúng với sự thật của chúng. Mặt khác nó liên hệ
với mọi tạm sở thiện, bất thiện khác qua các sự chi phối của tâm vô minh và các
kiến chấp, nhất là ngã chấp, rồi duyên khắp ba thời quá khứ, hiện tại vị lai để
rồi không ngót hoạt động theo chiều hướng thúc đẩy của tham, sân và si. Ở mặt
này nó rối loạn và đầy bất an. Tâm thức bị kết án và bị đối trị qua sự tu tập
giớị định, huệ là phần tâm thức này của ý thức.
Song cái phần ý thức phân biệt đi sát với năm thức cảm quan là phần quan trọng
nhất trong công việc tựu thành Trí huệ. Chính phần ý thức phân biệt ấy là Trí
huệ. Bởi năm thức của cảm quan chỉ biết chiếu rõ thật tướng của sự vật chứ không
đưa lại ý nghĩa gì hết, còn phần ý thức phân biệt liên hệ với vô minh, với ngã
chấp, thì luôn luôn cho sự vật những ý nghĩa theo ngã, ngã sở, theo các tâm tham,
sân, si, đầy phiền não, chứ không biết gì đến thật tướng của sự vật. Thế cho nên
chỉ còn cái phần ý thức phân biệt đi sát theo năm thức cảm quan mới nhận chân
được chính xác ý nghĩa của thật tướng mà thôi.
Ví như tôi nhìn một quyển sách, nhãn thức trực tiếp chiếu rọi
quyển sách ấy đúng như nó là và không chút phân biệt nó là gì hết, tức thời ý
thức đi cùng với nhãn thức phân biệt ngay đó là một quyển sách. Ngay giai đoạn
này sự thật của quyển sách được nhận ra, Trí huệ ở ngay tại đây. Song lập tức
cái phần ý thức vô minh chấp ngã sẽ ào ạt hưng khởi, nào là "đây là một quyển
sách của tôi mua cách đây hai hôm, của một tác giả mà tôi rất thích như đáng
giận thay, thằng cháu tôi đã làm cháy mất mấy chục trang..." trong một tâm niệm
như thế, nó duyên đủ nào tôi, của tôi, người khác, nào vui, nào buồn, nào quá
khứ, hiện tại ... và làm che mờ đi mất Trí huệ của tâm thức đối với thật tướng
của sự vật, chỉ là một vật với màu sắc, hình tướng, do nhân duyên mà có đó, được
gọi là quyển sách.
Sự tu tập thông thường chỉ là chế ngự cái phần ý thức phân
biệt liên hệ với ngã chấp và tham, sân, và si này, chứ không phải là tiêu diệt
toàn thể ý thức. Và chế ngự như thế là để cho phần ý thức đi sát với năm thức
cảm quan được tự do phân biệt trực tiếp sự vật, nghĩa là ý thức trực nhận ra sự
thật của sự vật, mà không bị cái phần ý thức phiền não kia ào ạt xen vào, đem
các ý nghĩa phiền não gán cho sự vật và che mờ đi mất nghĩa chân thật của nó.
Các phương pháp để chế ngự như thế được gọi là thiền định. Nhờ thiền định ý thức
đi cùng với năm thức cảm quan không bị ý thức phiền não xâm hại, nhờ thế nó độc
tôn hiện hành và làm cho sự vật hiển hiện ra như tật, tình trạng ấy được gọi là
Trí huệ, nên mới nói là Định sinh Huệ.
Tóm lại không có phân biệt (như năm thức cảm quan) thời không
thể là Trí huệ được, mà phân biệt theo xu hướng ngã và tham, sân, si cũng không
thể nào là Trí huệ được. Phải có phân biệt nhưng không phân biệt theo ngã hay
tham, sân, si mà phân biệt đi sát với năm thức cảm quan chiếu hiện, mới chính là
Trí huệ. Nhờ có phân biệt cho nên chân lý của sự vật mới có ý nghĩa là vô thường,
vô ngã, là Niết bàn, là Không, là Chân Như ... và mới được có các danh xưng như
vậy. Và cũng nhờ có phân biệt nên các ý nghĩa này mới được trình bày rành mạch,
rõ ràng, đúng lý cho người nghe hiểu rõ mà tin nhận.
Tác dụng thể nhận trực tiếp ra chân lý, tác dụng để thành lập
ý nghĩa cho chân lý và tác dụng để truyền bá chân lý. Tác dụng đầu tiên là kinh
nghiệm cá nhân, tác dụng thứ ba là truyền kinh nghiệm cá nhân sang cho tha nhân,
tác dụng thứ hai ở giữa là căn bản cho cả hai tác dụng kia, và nó mới chính thật
là bản thể trong sáng của ý thức phân biệt và được gọi là Trí huệ (prajnā).
Lại nếu nói cho trọn đủ về ý thức thì nó có thêm một tác dụng
thứ tư nữa là tác dụng phiền não và tạo nghiệp, theo tác dụng này ý thức còn
được gọi là nghiệp thức, vọng tưởng, tình thức, phân biệt (theo nghĩa xấu) biến
kế chấp, tâm phan duyên ... nó liên hệ chặt chẽ với vô minh, ngã chấp, tham ái.
Tác dụng thứ tư này, đối với các hữu tình chưa giác ngộ, hoàn
toàn đóng vai trò chính và chi phối toàn thể tâm thức. Hữu tình vốn chấp ngã, vô
minh và tham ái nên luôn luôn chỉ thấy có tác dụng thứ tư này là hoạt động duy
nhất của tâm thức mà thôi. Họ không ngờ đâu rằng trong cái tâm thức đầy phân
biệt phiền não đó của họ lại có các thành phần của Trí huệ trong sánh, luôn luôn
trực tiếp với chân lý của sự vật. Đại thừa gọi phần Trí huệ đó của tâm thức
trong khi tâm thức còn đang đầy chấp ngã phiền não là Như Lai tạng, hay rõ hơn
là "tại triền Như Lai" (tức Như Lai tính khi còn đang ở trong triền phược). Và
chính do trong tâm thức của chúng sinh đã có sẵn thành phần Trí huệ này, nên tâm
chúng sinh mới trở thành giác ngộ, và nhờ đó chúng sanh thành Phật, nên phần Trí
huệ ấy cũng được gọi là Phật tính của chúng sinh.
Vấn đề Trí huệ thật ra còn rất là phức tạp. Chúng ta còn cần
phải biết rõ Trí huệ của Phật khác với Trí huệ của A La Hán, Bích Chi Phật ra
sao? Phải chăng nếu chúng ta đã có sẵn Trí huệ trong tâm rồi thời chắc chắn là
chúng ta có Trí huệ? Tại sao (theo Đại thừa) Phật lại thuyết đối tượng của Trí
huệ là Không, là mộng, huyễn, bào, ảnh... Tại sao Trí huệ không thôi chưa đủ là
giác ngộ hay sao mà lại còn cần phải có đại bi? Có đại bi rồi cũng chưa đủ hay
sao mà còn phải có công đức nữa? Công đức và đại bi liên hệ thế nào với Trí huệ?
Rồi còn hạnh nguyện là gì nữa? Rồi Phật là Giác (Sambuddha), Giác là khác hay là
một với Trí huệ(Prajnā).
Và cũng chính từ vấn đề Trí huệ này mà chúng ta có thể lần phanh ra được chân ý
nghĩa của Phật. Tại sao (theo Đại thừa) Phật lại có Pháp thân, Báo thân Phật và
Hóa Thân Phật? Từ đó pháp tịnh độ là gì, báo độ, hóa độ ra sao? Tịnh độ để làm
gì và có ý nghĩa gì? Vô vàn ý nghĩa khác nữa mà giáo pháp Đại thừa chính là nỗ
lực để trình bày cho chúng ta tin hiểu về tất cả các ý nghĩa ấy. Tin hiểu để làm
gì? Để thực hành đúng và để vững tin chắc chắn sự lựa chọn và chấp nhận đạo Phật
của chúng ta là một hành động thiết thực nhất, hoàn toàn hữu ích và cần thiết
nhất cho toàn thể cuộc sống vô minh của chúng ta. Và trên bước đường thực hành
của chúng ta, hình bóng Phật sẽ không bao giờ phai nhạt mà trái lại luôn luôn
sống động, cụ thể trong từng hơi thở, từng tư tưởng, từng nhịp tim đập của chúng
ta.
Với Trí huệ làm nền tảng, Phật pháp trở nên hết sức tâm sâu
và bao la vô hạn, thế nên làm người con Phật phải nên cẩn trọng lắng nghe cho kỹ
và lắng nghe thật nhiều, suy xét cho kỹ và sao cho thật rộng trước khi tiến vào
phương tiện thực hành.
Trích từ Chùa Khuông Việt, Na Uy
Minh Quang posted January 30, 2002
[ Up ] [ Vọng Kiến ] [ Mười Điều Biện Ma ] [ Đại Lễ Rằm Tháng Giêng ] [ Bát Nhã Tâm Kinh - SC Như Thủy ] [ Lược Sử Phật Thích Ca ] [ Pháp Môn Tu Tắt ] [ Khuyến Thế Ca 1 ] [ Tánh Không Luận ] [ So Sánh Kinh Pháp Cú 1 ] [ Trí Huệ Là Gì ] [ Chỉ Nguyệt Lục ] [ Cúng Cháo - Nguyên Tạng ] [ Bài Giảng Phật-Đản - Thích Như Tấn ] [ Người Tìm Leo Núi Chỉ Có Bản Đồ - Thích Thanh Từ ]

markdown:
|
|
|
|
Trí huệ là gì?
Thích Nhất Chân
Tâm thức có để làm gì? Để tiếp nhận và phân biệt sáu cảnh. Do
đó không thể có một tâm thức thuần túy trống không, không có cảnh hay đối tượng
gì hết. Nhưng trong sáu thức ấy tính chất phân biệt hầu như không có tác dụng gì
nơi năm thức đầu, mà phân biệt dường như là thức. Và vì trong các kinh luận (tiểu
thừa) chỉ chấp nhận có sáu thức mà thôi, thế nên hầu như toàn thể mọi hoạt động
của tâm đều tùy thuộc vào ý thức. Trong khi thân chỉ trực tiếp đón nhận lấy hình
tướng của năm cảnh sắc, thanh, hương, vị, xúc mà thôi, thì việc phân biệt tốt
hay, xấu đẹp, phải trái, đúng sai để rồi khởi lên mọi thứ tâm sở hoặc ác là phần
vụ của ý thức.
Đa số người Phật tử hiểu lầm, nghe nói đến Trí huệ thời chỉ
biết lờ mờ là vô phân biệt gì đó, hoặc đừng chấp tướng, hay phá chấp này nọ và
hễ cứ nghe lý luận, nói năng trình bày là cho là thế trí, chấp ngôn ngữ, chưa
chứng... nhưng nếu ngay chính Đức Phật mà cứ vô phân biệt, không nói năng không
trình bày, thì Phật có đó có ích gì và có khác gì một khúc gỗ đâu, và làm sao để
cho mọi người đả thông được để thể nhập vào chân lý đây? Sự giác ngộ của Đức
Phật không phải chỉ để giác ngộ mà là để độ chúng sanh, Phật dùng vô phân biệt
trí để chứng ngộ thật tướng chân thật của vạn pháp không phải để vô phân biệt,
mà là để phân biệt giảng nói cho chúng sinh sáng tỏ. Tâm giác ngộ là cả sáu thức
đều giác ngộ, chứ không phải chỉ có năm thức đầu vô phân biệt còn thức thứ sáu
tức ý thức thì bỏ đi vì bản chất của nó là phân biệt. Trái lại khi tâm giác ngộ
thể hiện ra qua năm thức thì thành ra vô phân biệt và khi thể hiện qua thức thứ
sáu thì thành ra là phương tiện trí (nói theo đại thừa), bởi vì chính nhờ cái
khả năng phân biệt ấy làm phương tiện nên Đức Phật mới độ được chúng sanh bằng
caõch phân biệt thuyết pháp cho chúng sanh được ngộ nhập và chân lý.
Như đã nói một tâm thức thời phải có đối tượng, nếu không có đối tượng thời tâm thức sẽ diệt mất. Trí huệ là tâm thức, nên Trí huệ phải có đối tượng và ở đây đối tượng là chân lý đệ nhứt (paramārtha). Theo tiểu thừa chân lý ấy là Niết bàn (nīrvāna), theo đại thừa thời là tính KHÔNG, cả hai đều lý tưởng tuyệt ngôn, cả hai đều không thuộc vào lãnh vực của có. Nếu thế đối tượng của Trí huệ không phải là một cái gì có thuộc về hoặc sắc hoặc thanh, hương, v.v... Nếu đối tượng không có thì đâu còn có tâm thức nào hiện khởi nữa để mà gọi là Trí huệ. Điều này không phải là lạ gì trong giáo lý đại thừa, những danh từ như vô phân biệt, vô tâm, vô niệm, tuyệt lự hoặc các phương châm như vô tâm tiện thị Đạo (vô tâm chính là Đạo), ngôn ngữ đạo đoạn, tâm hành xứ diệt (trừ hết mọi ngôn từ, diệt hết mọi trạng thái tâm) Đối cảnh mạc sinh tâm (đối cảnh đừng sinh tâm)... đều cho thấy sự xác nhận cảnh giới không có tâm (hay ít ra là ý thức phân biệt) nữa mới là đạo, là chân lý cứu cánh.
Trên phương diện lý luận cảnh
giới vô tâm hết sức phi lý. Tại sao? Vì phải không có đối tượng thì tâm đâu còn
có đó nữa để mà gọi là chân lý.
Để tỏ rõ vấn đề trên, chúng
ta phải nên hiểu rằng tâm thức tuy có sáu lãnh vực khác nhau, song vẫn là một
tòan thể bất khả phân ly. Thế nên nơi năm thức cảm quan đầu không thể thiếu ý
thức phân biệt được. Các nhà A Tỳ Đàm gọi loại ý thức này là "ngũ câu thức"
nghĩa là ý thức cùng khởi với năm thức cảm quan. Một khi năm thức khởi lên là ý
thức khởi theo ngay liền mà phân biệt. Nên tuy bản chất của năm thức cảm quan là
trực tiếp nhận cảnh. Song trong thái độ trực tiếp ấy đã có sẵn thái độ phân biệt
suy luận gián tiếp của ý thức rồi. Thế nên mọi kinh nghiệm trực tiếp đều được ý
thức, được nhận ra là gì (tức phân biệt), được ghi nhận ý nghĩa, và được cho
danh xưng.
![]()
|
|


text:
Từ hơn một thập kỷ nay, các nhóm phần mềm đã được hưởng những lợi ích từ các phương pháp phát triển agile. Họ đã kế tục các phương pháp phát triển tăng cường và theo vòng lặp, ở đó các giải pháp được hình thành và phát triển thông qua những sự hợp tác. Các phương pháp tiếp cận truyền thống không linh hoạt thường tạo ra phần mềm bằng cách phát triển tuần tự theo từng phân đoạn. Ví dụ như quy trình thác nước (waterfall process), trong đó từng hoạt động như phân tích yêu cầu, thiết kế, phát triển và kiểm thử được thực hiện một cách tuần tự.
Mặc dù trước đây, quy trình phát triển thác nước là tiêu chuẩn để phát triển các hệ thống lớn, phức tạp trong nhiều năm, nó cũng có những hạn chế đáng lưu ý. Đầu tiên là nó khiến lãng phí công việc khi phải cố gắng hoàn thiện các tài liệu trước khi thiết kế và hoàn thiện các thiết kế trước khi viết mã, mặc dù ta đã biết rõ rằng các yêu cầu sẽ thay đổi theo thời gian. Hơn nữa, khi để quá trình kiểm thử và triển khai tích hợp đến phân khúc cuối cùng thì các vấn đề thường được phát hiện quá muộn để có thể được giải quyết mà không làm trễ dự án. Nếu mà chúng ta đang sống trong một thế giới mà ở đó mọi thứ đều di chuyển chậm chạp thì có thể bỏ qua 2 bước đó được. Nhưng trước áp lực phải tăng cường tạo ra các hệ thống mang tính sáng tạo thì các tổ chức lại giảm đi nhu cầu sử dụng phương pháp này.
Mặc dù chúng được phổ biến rộng rãi trong các nhóm phát triển hệ thống công nghệ thông tin, các phương pháp agile cũng có thể áp dụng tốt để phát triển sản phẩm phần cứng, điện tử và phần mềm. Phát triển phần mềm nhúng khác với việc phát triển các ứng dụng công nghệ thông tin chủ yếu ở chỗ nó bị hạn chế khi triển khai ở các thiết bị cuối cùng, chẳng hạn như hiệu năng bộ xử lý và bộ nhớ. Phần mềm nhúng thường thực hiện các hoạt động thời gian thực phức tạp trong những điều kiện ràng buộc. Hãy suy nghĩ về hệ thống điều khiển bằng máy tính giống như một túi khí bảo vệ chứa trong xe hơi. Chúng cần phải đáp ứng ngay lập tức (những khi gặp tai nạn), và cũng cần phải hoạt động một cách đáng tin cậy. Các phương pháp agile ban đầu được thiết kế cho các đội dự án nhỏ, ở cùng một chỗ, trong các ngành công nghiệp không chính quy. Cần phải mất nhiều năm phát triển để phương pháp agile có thể tiếp nhận được các dự án lớn và phức tạp hơn.
Khi được dùng như một phần của phương pháp tiếp cận dựa trên kiến trúc, sự tích hợp liên tục (Continuous Integration - CI) và phát triển theo hướng kiểm thử ( Test-Driven Development - TDD) mở rộng phương pháp agile cơ bản đủ để cung cấp cả chất lượng cao lẫn tính linh hoạt của dự án. Bài viết này tìm hiểu cách phương pháp agile, CI và TDD có thể được sử dụng như thế nào trong việc phát triển phần mềm nhúng. Bài viết cũng mô tả những lợi ích của sự kết hợp này.
Bằng cách nào mà sự tích hợp liên tục và phát triển theo hướng kiểm thử phù hợp với phương pháp agile
Giờ dây hầu hết mọi người đã nghe qua về phương pháp agile. Các khái niệm mà chúng mang đến cho việc phát triển phần mềm đã thay đổi cách thức mà các đội nhóm tổ chức công việc của họ, cách thích ứng với các yêu cầu luôn thay đổi và cách thức phát hành phần mềm. Tích hợp liên tục (CI) được tạo ra cho quy trình phát triển agile, vì vậy cách tiếp cận phương pháp này là chủ đề cho bất kỳ cuộc thảo luận nào về tích hợp liên tục. Nó tổ chức việc phát triển theo các nhóm chức năng của người dùng. Những nhóm chức năng này được chia thành các nhóm hay các chặng công việc nhỏ.
Ý tưởng là không cố gắng giải quyết tất cả vấn đề ngay từ ban đầu, mà tập trung vào những gì bạn đã biết. Vì vậy, nhóm nghiên cứu thiết kế, xây dựng, và kiểm thử những gì họ biết về các chức năng mong muốn. Điều này tạo ra một sản phẩm làm việc dựa trên tập hợp con các yêu cầu của sản phẩm hoàn chỉnh. Sau đó, cả nhóm sẽ làm việc tiếp với các yêu cầu có độ ưu tiên cao tiếp theo và cứ thế quá trình được lặp lại. Tất nhiên, nhìn thì thấy rất đơn giản, và quy trình này cũng có nhiều biến thể khác nhau, nhưng có một điều cốt lõi là: Từng bước xây dựng sản phẩm và dần dần cải thiện mọi thứ trong quá trình xây dựng đó.
Theo Martin Fowler của công ty tư vấn ThoughtWorks, tích hợp liên tục (IC) là phương pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên. Mỗi ngày, các thành viên đều phải theo dõi và phát triển công việc của họ ít nhất một lần. Việc này sẽ được một nhóm khác kiểm tra tự động, nhóm này sẽ tiến hành kiểm thử truy hồi để phát hiện lỗi nhanh nhất có thể. Cả nhóm thấy rằng phương pháp tiếp cận này giúp giảm bớt vấn đề về tích hợp hơn và cho phép phát triển phần mềm gắn kết nhanh hơn.
Điều này dẫn đến thành công của quá trình tích hợp liên tục. Nếu ý tưởng tích hợp liên tục là để tìm ra các vấn đề một cách nhanh chóng thì nó mang lại cho nhà phát triển các thông tin phản hồi về công việc của mình, sau đó sử dụng một phương pháp đánh giá công việc nhanh chóng. phát triển theo hướng kiểm thử lấp đầy khoảng cách đó. Với phương pháp phát triển theo hướng kiểm thử, bạn xây dựng bài kiểm thử và sau đó phát triển chức năng cho đến khi mã vượt qua được bài kiểm tra đó. Khi có những bổ sung, bài kiểm thử cho đoạn mã đó có thể được thêm vào khi bạn cố gắng build đoạn mã đó. Điều này đảm bảo rằng những bổ sung mới không phá vỡ công việc đã hoạt động trước đó, và những đoạn mã nào "mang tính nguy hiểm" sẽ được cảnh báo ngay. Sự kết hợp điển hình của tích hợp liên tục và sự phát triển theo hướng kiểm thử được minh họa trong hình 1.
Hình 1. Phương pháp agile sử dụng tích hợp liên tục và phát triển theo hướng kiểm thử
Các loại dự án được hưởng lợi từ tích hợp liên tục
Các nhóm phát triển có ít hơn 50 người làm việc trên các dự án có độ phức tạp không cao thì phù hợp với phương pháp phát triển agile lẫn tích hợp liên tục. Tuy nhiên, vì các sản phẩm ngày càng "thông minh hơn", nên chúng cũng ngày càng phức tạp hơn.
Ngày càng nhiều các sản phẩm có sử dụng phần mềm nhúng. Bạn thấy những chiếc xe mới bây giờ được tiếp thị về mã lực của nó thì ít mà về công nghệ phần mềm nhúng thì nhiều (Ví dụ: Tự vào chỗ đỗ xe, các cảnh báo an toàn tiên tiến, hiệu quả sử dụng nhiên liệu và hệ thống thông tin giải trí). Số lượng các dòng mã được viết để tạo ra một chiếc xe mới nhiều hơn so với số lượng các dòng mã được viết cho một máy bay phản lực chiến đấu F16.
Với nhu cầu gia tăng độ phức tạp đồng thời các sản phẩm phải được sản xuất nhanh để đáp ứng cho thị trường. Và việc thịnh hành của các phần mềm nhúng kết hợp với yêu cầu thời gian chặt chẽ hơn đã mang lại sự lựa chọn cho các nhà phát triển về các phương pháp agile và tích hợp liên tục (IC).
Sử dụng các phương pháp agile để phát triển các hệ thống nhúng
Phương pháp agile cho phép các nhóm làm phần mềm và hệ thống đáp ứng sự thay đổi một cách nhanh chóng. Cách tiếp cận linh hoạt này giúp giảm nguy cơ trễ dự án, điều mà trước đây đã gắn liền với quy trình phát triển phần mềm truyền thống, trong đó việc tích hợp từng thành phần lại với nhau được coi là nỗ lực ở giai đoạn cuối cùng. Giai đoạn này thường là nguyên nhân gây nhầm lẫn so với đặc tả thiết kế ban đầu nhưng lại được phát hiện quá muộn để có thể sửa chữa cho kịp thời hạn.
Tuy nhiên, đối với các nhóm phát triển hệ thống, họ là những người phải tạo ra nhiều thứ hơn là phần mềm, thì lại hoài nghi về một số điểm ở phương pháp agile này. Họ nói rằng nếu bỏ qua quá nhiều yếu tố khi lên kế hoạch từ ban đầu, thì cuối cùng bạn sẽ có những phần mềm kém chất lượng và không tương thích với phần cứng. Nếu không tiến hành checkpoint (kiểm tra) sớm và thường xuyên để xác nhận tiến độ so với kế hoạch chi tiết về kiến trúc, thì nhóm dự án có thể thất bại, không thể sản xuất ra thành phần hoạt động được trong các hệ thống lớn. Hơn nữa, đối với các nhà phát triển hệ thống phức tạp, những người đang tìm kiếm khả năng tái sử dụng của thiết kế hoặc khả năng mở rộng cho các yêu cầu của dự án lớn hơn thì các phương pháp agile lại tỏ ra hạn chế.
Những lo ngại này cũng dễ hiểu, bởi vì mô hình hóa và kiến trúc không phải là điểm trọng tâm của các kỹ thuật agile. Nhưng cách tiếp cận tích hợp liên tục đối với quá trình phát triển hệ thống cung cấp một số cải tiến so với những phương pháp agile thuần túy. Sự tích hợp liên tục giúp các nhóm phát triển hệ thống linh hoạt và đáp ứng với những thay đổi nghiệp vụ nhanh chóng, đồng thời cũng đảm bảo rằng các phần cứng và phần mềm thực tế được phát triển đồng bộ liên tục. Sự tích hợp liên tục cho phép các thành viên trong nhóm làm việc hiệu quả trong lĩnh vực của mình, tập trung vào các nhiệm vụ mà họ đang hoàn thành một cách tốt nhất. Vào cuối mỗi ngày, họ biết rằng những đóng góp của họ được tích hợp vào dự án và các bộ phận thành phần làm việc với nhau. Và nếu có gì đó không được tích hợp thì nó sẽ nhanh chóng được phát hiện.
Hãy xem xét một số các thành phần thiết yếu trong phát triển và phân phối hệ thống phức tạp và khám phá việc tích hợp liên tục (CI) giúp đáp ứng những thách thức đó như thế nào.
Kiến trúc
Khi bạn xây dựng hệ thống phức tạp, thì bạn không thể liên tục thêm các tính năng mà không cần bản thiết kế chi tiết. Nếu không có bản thiết kế, thì có khả năng bạn sẽ phải làm lại những gì đã làm. Cho dù bạn gọi nó là thiết kế chi tiết, mô hình hoặc kiến trúc, nó đều cung cấp một nền tảng vững chắc mà ở đó quy trình vòng lặp được bắt đầu.
Kiến trúc có thể hữu ích trong các dự án có nhóm 50 thành viên hoặc ít hơn, nhưng khi bạn phát triển vượt quá kích thước này, bạn chắc chắn phải có công đoạn làm sẵn trước này để hiểu cách chia thành phần, tái sử dụng và sự biến đổi. Sự phân tích sẵn trước này cho phép bạn chia thành các nhóm nhưng vẫn có thể kết họp lại để đưa ra sản phẩm. Điều này cũng đúng khi bạn có các nhà phát triển phần mềm và phần cứng làm việc cùng nhau, vì bạn làm cho các hệ thống phức tạp với phần mềm nhúng.
Mô phỏng
Bằng cách nắm bắt kiến trúc trong mô hình mô phỏng, nhóm phát triển có thể thấy cách hệ thống sẽ đáp ứng với các đầu vào khác nhau. Hình thức kiểm thử sớm này cho phép xác nhận rằng hệ thống thực hiện như dự định, do vậy nó đáp ứng các yêu cầu. Nó cũng cho phép nhà thiết kế hình dung bất kỳ hậu quả không lường trước nào của thiết kế. Những hậu quả không lường trước rất khó thấy khi xem xét mã dưới dạng văn bản. Chúng trở nên rõ ràng hơn khi xem mô hình của hệ thống và thậm chí còn rõ ràng hơn khi hệ thống đó đang hoạt động.
Bằng cách này, việc mô hình hóa và mô phỏng cho phép bắt đầu kiểm thử và tích hợp ngay sau khi công việc thiết kế bắt đầu, điều này loại bỏ sự chậm trễ có thể gặp phải nếu phần cứng nhúng chưa có sẵn. Nó có thể tiết kiệm khoản đầu tư đáng kể trong việc tạo sản phẩm mẫu sớm không cần thiết với kiến trúc không khả thi. Ngay cả khi bạn có sẵn phần cứng, tích hợp liên tục đòi hỏi phải xây dựng liên tục.
Nếu bạn mong muốn xem kết quả càng sớm, thì môi trường xây dựng của bạn càng trở nên đắt. Bởi vì mục đích chính của tích hợp liên tục là cung cấp kết quả càng nhanh càng tốt, việc mô phỏng cho phép bạn kiểm thử mà không cần chi phí phần cứng quá cao. Nó cũng cung cấp một cách dễ dàng hơn để trao đổi thông tin về chức năng của thành phần, cách này chính là pair programming (lập trình theo cặp đôi) và "code review (rà soát mã)", rất phổ biến trong phát triển agile.
Tự động hóa quá trình build
Tích hợp liên tục đòi hỏi phải tự động hóa quá trình build, tức là khả năng phần mềm được tự động biên dịch và liên kết thành tệp thực thi. Tốc độ là quan trọng bởi vì quá trình build một ứng dụng lớn có thể mất một thời gian dài. Nếu không có công cụ build lớn, nhanh chóng, đáng tin cậy, thì bạn sẽ thiếu những thông tin cần thiết để giải quyết các vấn đề tích hợp phát sinh. Khi build, nếu có các xung đột hay lỗi thì trình build sẽ tự động thông báo. Vì vậy, nếu phát hiện vấn đề thì các nhà phát triển cùng làm việc để giải quyết xung đột thông qua việc kiểm tra bản build trước đó trên một mô phỏng phần cứng mà không làm trì hoãn các nhà phát triển khác. Nhưng để đạt được hiệu quả này, việc xây dựng tích hợp phải diễn ra liên tục, phải tạo ra bản build mới ngay sau khi kết thúc bản build trước đó. Điều này rất khác với cách build hàng ngày hoặc hàng tuần mà các quá trình khác sử dụng.
Tất nhiên, phương pháp này đòi hỏi tự động hóa quá trình build, bởi vì sẽ là không thực tế khi giao cho ai đó chỉ với một nhiệm vụ là ngồi build suốt cả ngày. Hơn nữa, quá trình build cần được thực hiện một cách nhanh chóng, điều này đòi hỏi phải chạy đa luồng (multithreaded). Quá trình multithreaded build chính là cách build nhiều thành phần song song cùng lúc, giúp giảm bớt thời gian build. Nó đòi hỏi nhiều phần cứng hơn và kịch bản phức tạp hơn. Kịch bản càng trở nên phức tạp, thì công cụ quản lý việc xây dựng càng trở nên giá trị hơn.
Quản lý công việc
Khái niệm agile là việc phân chia công việc thành những phần công việc nhỏ, dễ quản lý. Đây cũng là tiền đề cơ bản đằng sau phương pháp tích hợp liên tục: để sửa các lỗi của bạn ngay từ ban đầu. Điều này sẽ ngăn không cho chúng kết hợp thành các vấn đề lớn hơn, khó giải quyết hơn sau này.
Một trong những điều mà kỹ thuật này mang lại là khả năng cung cấp các bản phát hành nhỏ, hoạt động được, đã được xây dựng và kiểm thử nhiều ngày theo tiến độ của dự án. Mỗi bản phát hành giúp giảm rủi ro của dự án bằng cách xác thực kiến trúc, các yêu cầu và ước tính lịch trình của nhóm. Theo phương pháp agile, những công việc cần phải được hoàn thành được gọi là tồn đọng (backlog). Khi bạn bắt đầu chia công việc thành các phần nhỏ hơn, gọi là các chặng (sprints), công việc được phân bổ cho một sprint được gọi là sprint backlog. Phần công việc còn lại được phân bổ cho các sprint trong tương lai được gọi là project backlog. Mục tiêu là nhóm các hạng mục công việc thành một sprint để có thể hoàn thành được trong khoảng thời gian xác định của sprint.
Quy trình này phụ thuộc nhiều vào việc thu thập số liệu để đội có thể dự đoán chính xác lượng thời gian mà nhiệm vụ sẽ đòi hỏi và, do đó số lượng tác vụ có thể phù hợp với một sprint. Tuy nhiên, dù cho những số liệu này là bao nhiêu, thì việc thu thập dữ liệu là rất mệt mỏi ngay cả đối với nhóm nhỏ. Vì các nhóm nhỏ được gom lại với nhau để tạo ra sản phẩm phức tạp hơn, nên các tác vụ khó hoàn thành theo cách thủ công.
Có rất nhiều sản phẩm trên thị trường giúp tổ chức công việc, theo dõi hoàn thành công việc và thống kê các số liệu liên quan đến công việc đó như: công việc đã thực hiện được bao nhiêu, nhanh đến đâu, tốt đến mức nào vv... Khi theo đuổi phương pháp tích hợp liên tục, thì các lỗi về tích hợp được đánh dấu là high-priority (mức độ ưu tiên cao) và được thêm vào backlog (danh sách các công việc tồn đọng). Về mặt này, những sản phẩm tốt nhất trên thị trường cung cấp một số mức độ tích hợp giữa các hạng mục công việc mới và hệ thống quản lý quá trình build, do đó lỗi được xác định sau mỗi lần build có thể được sửa một cách nhanh chóng và tích hợp với các hạng mục công việc đang có, tăng dần theo mức ưu tiên và được chuyển đến nhóm phù hợp.
Quản lý chất lượng
Quản lý chất lượng là phương pháp phát triển vòng đời để đảm bảo rằng tất cả các yêu cầu cho sản phẩm của bạn đã được kiểm tra. Nỗ lực này cần được tổ chức và hiểu đúng để các bài kiểm thử chính xác có thể được cập nhật khi các yêu cầu thay đổi. Quản lý chất lượng giúp các nhà quản lý dự án trả lời những câu hỏi sau:
- Nếu sản phẩm của tôi phải được phát hành vào tuần tới, phần nào sẽ có nguy cơ cao nhất?
- Chúng ta có thể phát hành mà không có yêu cầu ở mức thấp hơn?
- Đây có phải là bản phát hành có chất lượng cao hay không?
Trong khi đối mặt với áp lực thị trường rằng phải đáp ứng nhanh và tăng tốc chu kỳ sản phẩm, những câu hỏi này có thể giúp doanh nghiệp tự tin phát hành sản phẩm ra thị trường. Các nhà quản lý hiểu rõ sẽ biết cách bổ sung các tài nguyên nào, tính năng nào nên bỏ đi và thương lượng lại ngày giao hàng để đạt lợi thế tối đa nhất.
Với phương pháp phát triển theo hướng kiểm thử, việc kiểm thử trở thành vấn đề trung tâm hơn với các nỗ lực phát triển. Theo phương pháp phát triển theo hướng kiểm thử, bạn viết bài kiểm thử dựa trên yêu cầu, và sau đó bạn phát triển mã cho đến khi nó vượt qua bài kiểm thử đó. Điều này đảm bảo rằng không có chức năng bổ sung nào được tạo ra, đó sẽ là thứ mà nhóm phát triển gọi là "mạ vàng (gold plating)". Thậm chí nếu bạn có một ý tưởng về một tính năng hay chức năng mới cho sản phẩm nhưng những điều này không có trong yêu cầu thì việc thêm vào sẽ làm mất thời gian và có thể bị trễ dự án. Đồng thời khiến cho khách hàng không hài lòng.
Tự động hóa kiểm thử
Khi bạn thực hiện quá trình build nhiều lần, thì nhóm phát triển được yêu cầu kiểm thử lại các chức năng đã làm việc trong các phiên bản trước. Quá trình kiểm thử lại này, trước đây được biết đến là "mã tốt (good code)", thì nay được gọi là kiểm thử truy hồi (regression testing). Nó đảm bảo rằng những đoạn mã trước đây sẽ không bị lỗi khi bạn thêm vào một tính năng mới nào đó. Với phương pháp tích hợp liên tục, kiểm thử truy hồi tự động được viết thành kịch bản lệnh để chạy ở bước cuối cùng của mỗi lần build. Điều này cho phép các nhà phát triển có được các thông tin phản hồi ngay lập tức về các lỗi được tìm thấy trong lần build mới. Đó là những cảnh báo cho nhà phát triển biết rằng mã mới mà họ đã tạo ra có làm việc (hoặc không làm việc) như yêu cầu hay không. Nếu không có kiểm thử truy hồi, các nhà phát triển sẽ chỉ biết rằng họ đã build thành công. Bởi vì dù sao thì cũng phải thực hiện các bài kiểm thử, cho nên nếu ban đầu bạn sử dụng phương pháp phát triển theo hướng kiểm thử thì sẽ không phát sinh thêm công việc này. Nó đơn giản chỉ là đảo ngược trật tự của công việc bằng cách trước tiên tạo ra các bài kiểm thử, sau đó mới tạo mã.
Dự án phát triển theo quy trình nước truyền thống có thể sống sót mà không thực hiện bất kỳ việc kiểm thử tự động nào. Dự án có thể được mô tả, xây dựng và sau đó được kiểm thử không ngừng bởi rất nhiều người. Nhưng khi bạn phát hành sản phẩm một cách thường xuyên thì lúc này mới phát sinh vấn đề. Đó là không thể kiểm thử thủ công các hệ thống đang được build nhiều lần trong một ngày.
Sự cộng tác
Tổ chức phần mềm IBM Rational từ lâu đã là một người ủng hộ sự cộng tác như là yếu tố quan trọng cho sự phát triển và phân phối thành công hệ thống. Nhưng trong phương pháp tích hợp liên tục, nơi mà cả hai nhóm phần mềm và phần cứng đều tham gia, sự cộng tác không chỉ là việc kết hợp nhuần nhuyễn sản phẩm của các đội, mà còn là sự hiểu biết đầy đủ về các yêu cầu, tính năng và thời hạn.
Đối với những kiến trúc tốt thì cho phép kiểu cộng tác này một phần vì mọi người có thể hiểu tốt hơn các phụ thuộc giữa các thành phần khác nhau mà họ đang xây dựng. Với việc quản lý danh mục dự án, bạn có thể hiểu các tính năng, việc tái sử dụng và phân bổ tài nguyên. Nhưng trong các dự án mà phần cứng và phần mềm cùng phát triển, đó cũng là điều quan trọng để quản lý các yêu cầu và đưa ra quyết định thông minh khi nào những yêu cầu có thể thay đổi và khi nào chúng không được thay đổi.
Các dự án như vậy thường dính líu đến nhiều bên liên quan ở nhiều cấp độ của việc ra quyết định. Cộng tác tốt sẽ giúp làm thỏa mãn các bên liên quan. Nó đảm bảo rằng sản phẩm tốt phải được tạo ra và rằng các sai lệch so với các mục tiêu rộng lớn hơn được xác định một cách nhanh chóng. Điều này tạo ra một sản phẩm thỏa mãn tốt hơn nhu cầu của khách hàng.
Tóm tắt
Từ góc độ kỹ thuật, tích hợp liên tục (Continuous Integration - CI) giúp các nhóm làm việc hiệu quả hơn. Các nhóm này có thể có chức năng liên quan nhau, tạo ra phần cứng và phần mềm làm việc cùng nhau. Họ có thể làm việc ở những nơi khác nhau, bởi vì công việc tích hợp không ngừng sẽ đảm bảo rằng bạn không đi lệch các thiết kế. Mọi người có thể làm việc trong các nhóm lớn, bởi vì các thành phần khác nhau của hệ thống phức tạp sẽ làm việc cùng nhau đảm bảo hơn. Nó giải quyết nhiều vấn đề sớm mà các nhóm phát triển theo phương pháp agile có thể đã trải qua nếu không tích hợp liên tục. Việc phối hợp phương pháp tích hợp liên tục với phương pháp phát triển theo hướng kiểm thử đã bổ trợ cho phương pháp agile, bởi vì nó cho phép phương pháp agile làm việc hiệu quả hơn.
Từ góc độ kinh doanh, phương pháp tích hợp liên tục cung cấp các kết quả nghiệp vụ tốt hơn bằng cách cho phép cho các nhóm đều tham gia. Nghĩa là, họ có thể đưa sản phẩm ra thị trường nhanh hơn, bằng cách tìm ra các vấn đề khi chúng còn mới và nhỏ, không phải chờ đợi cho đến khi chúng trở nên lớn và khó sửa chữa. Họ cũng có thể đáp ứng tốt hơn yêu cầu đưa thêm tính năng mới vào sản phẩm trong lúc đang phát triển. Điều này tạo ra một sản phẩm tốt hơn cho khách hàng, đó là hứa hẹn thực sự của sự linh hoạt.
Tài nguyên
Học tập
- Nghe bản tin Đến thời kỳ của phương pháp Tích hợp liên tục (CI). Bạn vui lòng tìm bản tin số #204.
- Xem bản tin Áp dụng phương pháp Tích hợp liên tục trong quy trình agile để phát triển phần mềm nhúng.
- Để biết thêm thông tin về quản lý chất lượng:
- Hãy xem bài viết của Moshe Cohen, Quản lý chất lượng thông minh hơn: Cách nhanh nhất để tạo ưu thế cạnh tranh (Đây là tài liệu White Paper về những tư tưởng lãnh đạo của IBM Software, định dạng PDF được phát hành tháng 6 năm 2011).
- Hãy tìm hiểu trang web Quản lý chất lượng và kiểm thử của IBM.
- Để biết thêm thông tin về phương pháp Tích hợp liên tục, hãy xem Các thực tiễn về phương pháp Tích hợp liên tục trên trang web của Martin Fowler.
- Hãy truy cập Trang phần mềm Rational trên developerWorks để có các tài nguyên kỹ thuật và thực hành tốt nhất cho các sản phẩm Software Delivery Platform của Rational.
- Đăng ký nhận bản tin developerWorks hàng tuần qua email, và chọn chủ đề để theo dõi.
- Theo dõi các sự kiện kỹ thuật và các bản tin trên developerWorks về các sản phẩm của IBM và các chủ đề ngành công nghệ thông tin.
- Tham dự các lớp học miễn phí trên developerWorks để nhanh chóng tiếp cận các sản phẩm và công cụ của IBM, cũng như xu hướng của ngành công nghệ thông tin.
- Xem các bài demo theo yêu cầu trên trang developerWorks, từ việc cài đặt sản phẩm và hướng dẫn thiết lập cho người mới bắt đầu đến các chức năng cao cấp hơn cho các nhà phát triển có kinh nghiệm.
Lấy sản phẩm và công nghệ
- Tải về phiên bản dùng thử miễn phí của phần mềm Rational.
- So sánh và đánh giá các sản phẩm phần mềm của IBM theo cách riêng của bạn: Bạn có thể tải về để dùng thử, dùng thử trực tuyến, sử dụng trong môi trường đám mây, hoặc dành một vài giờ với SOA Sandbox để học cách triển khai một kiến trúc hướng dịch vụ hiệu quả.
Thảo luận
- Tham gia diễn đàn về phần mềm Rational để đặt câu hỏi và thảo luận.
- Tham gia thảo luận và nâng cao chuyên môn của bạn bằng cách vào các diễn đàn của Rational, cafés và thư viện wikis.
- Tham gia cộng đồng Rational để chia sẻ kinh nghiệm của bạn về phần mềm Rational và được kết nối tới các đồng nghiệp.
- Hãy dành ít thời gian để cùng đánh giá và xem xét phần mềm Rational.
Bình luận
-
Vùng dữ liệu trên developerWorks
Khám phá các bài viết xoay quanh lĩnh vực dữ liệu, Quản lý hệ thống thông tin
-
Vùng mã nguồn mở trên developerWorks
Xem các bài viết về HTML, CSS, JavaScript,...
-
Điện toán đám mây
Tìm hiểu về điện toán đám mây

markdown:
Từ hơn một thập kỷ nay, các nhóm phần mềm đã được hưởng những lợi ích từ các phương pháp phát triển agile. Họ đã kế tục các phương pháp phát triển tăng cường và theo vòng lặp, ở đó các giải pháp được hình thành và phát triển thông qua những sự hợp tác. Các phương pháp tiếp cận truyền thống không linh hoạt thường tạo ra phần mềm bằng cách phát triển tuần tự theo từng phân đoạn. Ví dụ như quy trình thác nước (waterfall process), trong đó từng hoạt động như phân tích yêu cầu, thiết kế, phát triển và kiểm thử được thực hiện một cách tuần tự.
Mặc dù trước đây, quy trình phát triển thác nước là tiêu chuẩn để phát triển các hệ thống lớn, phức tạp trong nhiều năm, nó cũng có những hạn chế đáng lưu ý. Đầu tiên là nó khiến lãng phí công việc khi phải cố gắng hoàn thiện các tài liệu trước khi thiết kế và hoàn thiện các thiết kế trước khi viết mã, mặc dù ta đã biết rõ rằng các yêu cầu sẽ thay đổi theo thời gian. Hơn nữa, khi để quá trình kiểm thử và triển khai tích hợp đến phân khúc cuối cùng thì các vấn đề thường được phát hiện quá muộn để có thể được giải quyết mà không làm trễ dự án. Nếu mà chúng ta đang sống trong một thế giới mà ở đó mọi thứ đều di chuyển chậm chạp thì có thể bỏ qua 2 bước đó được. Nhưng trước áp lực phải tăng cường tạo ra các hệ thống mang tính sáng tạo thì các tổ chức lại giảm đi nhu cầu sử dụng phương pháp này.
Mặc dù chúng được phổ biến rộng rãi trong các nhóm phát triển hệ thống công nghệ thông tin, các phương pháp agile cũng có thể áp dụng tốt để phát triển sản phẩm phần cứng, điện tử và phần mềm. Phát triển phần mềm nhúng khác với việc phát triển các ứng dụng công nghệ thông tin chủ yếu ở chỗ nó bị hạn chế khi triển khai ở các thiết bị cuối cùng, chẳng hạn như hiệu năng bộ xử lý và bộ nhớ. Phần mềm nhúng thường thực hiện các hoạt động thời gian thực phức tạp trong những điều kiện ràng buộc. Hãy suy nghĩ về hệ thống điều khiển bằng máy tính giống như một túi khí bảo vệ chứa trong xe hơi. Chúng cần phải đáp ứng ngay lập tức (những khi gặp tai nạn), và cũng cần phải hoạt động một cách đáng tin cậy. Các phương pháp agile ban đầu được thiết kế cho các đội dự án nhỏ, ở cùng một chỗ, trong các ngành công nghiệp không chính quy. Cần phải mất nhiều năm phát triển để phương pháp agile có thể tiếp nhận được các dự án lớn và phức tạp hơn.
Khi được dùng như một phần của phương pháp tiếp cận dựa trên kiến trúc, sự tích hợp liên tục (Continuous Integration - CI) và phát triển theo hướng kiểm thử ( Test-Driven Development - TDD) mở rộng phương pháp agile cơ bản đủ để cung cấp cả chất lượng cao lẫn tính linh hoạt của dự án. Bài viết này tìm hiểu cách phương pháp agile, CI và TDD có thể được sử dụng như thế nào trong việc phát triển phần mềm nhúng. Bài viết cũng mô tả những lợi ích của sự kết hợp này.
## Bằng cách nào mà sự tích hợp liên tục và phát triển theo hướng kiểm thử phù hợp với phương pháp agile
Giờ dây hầu hết mọi người đã nghe qua về phương pháp agile. Các khái niệm mà chúng mang đến cho việc phát triển phần mềm đã thay đổi cách thức mà các đội nhóm tổ chức công việc của họ, cách thích ứng với các yêu cầu luôn thay đổi và cách thức phát hành phần mềm. Tích hợp liên tục (CI) được tạo ra cho quy trình phát triển agile, vì vậy cách tiếp cận phương pháp này là chủ đề cho bất kỳ cuộc thảo luận nào về tích hợp liên tục. Nó tổ chức việc phát triển theo các nhóm chức năng của người dùng. Những nhóm chức năng này được chia thành các nhóm hay các chặng công việc nhỏ.
Ý tưởng là không cố gắng giải quyết tất cả vấn đề ngay từ ban đầu, mà tập trung vào những gì bạn đã biết. Vì vậy, nhóm nghiên cứu thiết kế, xây dựng, và kiểm thử những gì họ biết về các chức năng mong muốn. Điều này tạo ra một sản phẩm làm việc dựa trên tập hợp con các yêu cầu của sản phẩm hoàn chỉnh. Sau đó, cả nhóm sẽ làm việc tiếp với các yêu cầu có độ ưu tiên cao tiếp theo và cứ thế quá trình được lặp lại. Tất nhiên, nhìn thì thấy rất đơn giản, và quy trình này cũng có nhiều biến thể khác nhau, nhưng có một điều cốt lõi là: Từng bước xây dựng sản phẩm và dần dần cải thiện mọi thứ trong quá trình xây dựng đó.
Theo Martin Fowler của công ty tư vấn ThoughtWorks,
*tích hợp liên tục (IC)* là phương
pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường
xuyên. Mỗi ngày, các thành viên đều phải theo dõi và phát triển công việc của họ ít
nhất một lần. Việc này sẽ được một nhóm khác kiểm tra tự động, nhóm này sẽ tiến hành
kiểm thử truy hồi để phát hiện lỗi nhanh nhất có thể. Cả nhóm thấy rằng phương pháp
tiếp cận này giúp giảm bớt vấn đề về tích hợp hơn và cho phép phát triển phần mềm
gắn kết nhanh hơn.
Điều này dẫn đến thành công của quá trình tích hợp liên tục. Nếu ý tưởng tích hợp liên tục là để tìm ra các vấn đề một cách nhanh chóng thì nó mang lại cho nhà phát triển các thông tin phản hồi về công việc của mình, sau đó sử dụng một phương pháp đánh giá công việc nhanh chóng. phát triển theo hướng kiểm thử lấp đầy khoảng cách đó. Với phương pháp phát triển theo hướng kiểm thử, bạn xây dựng bài kiểm thử và sau đó phát triển chức năng cho đến khi mã vượt qua được bài kiểm tra đó. Khi có những bổ sung, bài kiểm thử cho đoạn mã đó có thể được thêm vào khi bạn cố gắng build đoạn mã đó. Điều này đảm bảo rằng những bổ sung mới không phá vỡ công việc đã hoạt động trước đó, và những đoạn mã nào "mang tính nguy hiểm" sẽ được cảnh báo ngay. Sự kết hợp điển hình của tích hợp liên tục và sự phát triển theo hướng kiểm thử được minh họa trong hình 1.
##### Hình 1. Phương pháp agile sử dụng tích hợp liên tục và phát triển theo hướng kiểm thử
![ Hình 1. Thực hành linh lợi bằng cách sử dụng tích hợp liên tục và phát triển hướng kiểm thử](image001.gif)
## Các loại dự án được hưởng lợi từ tích hợp liên tục
Các nhóm phát triển có ít hơn 50 người làm việc trên các dự án có độ phức tạp không cao thì phù hợp với phương pháp phát triển agile lẫn tích hợp liên tục. Tuy nhiên, vì các sản phẩm ngày càng "thông minh hơn", nên chúng cũng ngày càng phức tạp hơn.
Ngày càng nhiều các sản phẩm có sử dụng phần mềm nhúng. Bạn thấy những chiếc xe mới bây giờ được tiếp thị về mã lực của nó thì ít mà về công nghệ phần mềm nhúng thì nhiều (Ví dụ: Tự vào chỗ đỗ xe, các cảnh báo an toàn tiên tiến, hiệu quả sử dụng nhiên liệu và hệ thống thông tin giải trí). Số lượng các dòng mã được viết để tạo ra một chiếc xe mới nhiều hơn so với số lượng các dòng mã được viết cho một máy bay phản lực chiến đấu F16.
Với nhu cầu gia tăng độ phức tạp đồng thời các sản phẩm phải được sản xuất nhanh để đáp ứng cho thị trường. Và việc thịnh hành của các phần mềm nhúng kết hợp với yêu cầu thời gian chặt chẽ hơn đã mang lại sự lựa chọn cho các nhà phát triển về các phương pháp agile và tích hợp liên tục (IC).
## Sử dụng các phương pháp agile để phát triển các hệ thống nhúng
Phương pháp agile cho phép các nhóm làm phần mềm và hệ thống đáp ứng sự thay đổi một cách nhanh chóng. Cách tiếp cận linh hoạt này giúp giảm nguy cơ trễ dự án, điều mà trước đây đã gắn liền với quy trình phát triển phần mềm truyền thống, trong đó việc tích hợp từng thành phần lại với nhau được coi là nỗ lực ở giai đoạn cuối cùng. Giai đoạn này thường là nguyên nhân gây nhầm lẫn so với đặc tả thiết kế ban đầu nhưng lại được phát hiện quá muộn để có thể sửa chữa cho kịp thời hạn.
Tuy nhiên, đối với các nhóm phát triển hệ thống, họ là những người phải tạo ra nhiều thứ hơn là phần mềm, thì lại hoài nghi về một số điểm ở phương pháp agile này. Họ nói rằng nếu bỏ qua quá nhiều yếu tố khi lên kế hoạch từ ban đầu, thì cuối cùng bạn sẽ có những phần mềm kém chất lượng và không tương thích với phần cứng. Nếu không tiến hành checkpoint (kiểm tra) sớm và thường xuyên để xác nhận tiến độ so với kế hoạch chi tiết về kiến trúc, thì nhóm dự án có thể thất bại, không thể sản xuất ra thành phần hoạt động được trong các hệ thống lớn. Hơn nữa, đối với các nhà phát triển hệ thống phức tạp, những người đang tìm kiếm khả năng tái sử dụng của thiết kế hoặc khả năng mở rộng cho các yêu cầu của dự án lớn hơn thì các phương pháp agile lại tỏ ra hạn chế.
Những lo ngại này cũng dễ hiểu, bởi vì mô hình hóa và kiến trúc không phải là điểm trọng tâm của các kỹ thuật agile. Nhưng cách tiếp cận tích hợp liên tục đối với quá trình phát triển hệ thống cung cấp một số cải tiến so với những phương pháp agile thuần túy. Sự tích hợp liên tục giúp các nhóm phát triển hệ thống linh hoạt và đáp ứng với những thay đổi nghiệp vụ nhanh chóng, đồng thời cũng đảm bảo rằng các phần cứng và phần mềm thực tế được phát triển đồng bộ liên tục. Sự tích hợp liên tục cho phép các thành viên trong nhóm làm việc hiệu quả trong lĩnh vực của mình, tập trung vào các nhiệm vụ mà họ đang hoàn thành một cách tốt nhất. Vào cuối mỗi ngày, họ biết rằng những đóng góp của họ được tích hợp vào dự án và các bộ phận thành phần làm việc với nhau. Và nếu có gì đó không được tích hợp thì nó sẽ nhanh chóng được phát hiện.
Hãy xem xét một số các thành phần thiết yếu trong phát triển và phân phối hệ thống phức tạp và khám phá việc tích hợp liên tục (CI) giúp đáp ứng những thách thức đó như thế nào.
### Kiến trúc
Khi bạn xây dựng hệ thống phức tạp, thì bạn không thể liên tục thêm các tính năng mà không cần bản thiết kế chi tiết. Nếu không có bản thiết kế, thì có khả năng bạn sẽ phải làm lại những gì đã làm. Cho dù bạn gọi nó là thiết kế chi tiết, mô hình hoặc kiến trúc, nó đều cung cấp một nền tảng vững chắc mà ở đó quy trình vòng lặp được bắt đầu.
Kiến trúc có thể hữu ích trong các dự án có nhóm 50 thành viên hoặc ít hơn, nhưng khi bạn phát triển vượt quá kích thước này, bạn chắc chắn phải có công đoạn làm sẵn trước này để hiểu cách chia thành phần, tái sử dụng và sự biến đổi. Sự phân tích sẵn trước này cho phép bạn chia thành các nhóm nhưng vẫn có thể kết họp lại để đưa ra sản phẩm. Điều này cũng đúng khi bạn có các nhà phát triển phần mềm và phần cứng làm việc cùng nhau, vì bạn làm cho các hệ thống phức tạp với phần mềm nhúng.
**Mô phỏng**
Bằng cách nắm bắt kiến trúc trong mô hình mô phỏng, nhóm phát triển có thể thấy cách hệ thống sẽ đáp ứng với các đầu vào khác nhau. Hình thức kiểm thử sớm này cho phép xác nhận rằng hệ thống thực hiện như dự định, do vậy nó đáp ứng các yêu cầu. Nó cũng cho phép nhà thiết kế hình dung bất kỳ hậu quả không lường trước nào của thiết kế. Những hậu quả không lường trước rất khó thấy khi xem xét mã dưới dạng văn bản. Chúng trở nên rõ ràng hơn khi xem mô hình của hệ thống và thậm chí còn rõ ràng hơn khi hệ thống đó đang hoạt động.
Bằng cách này, việc mô hình hóa và mô phỏng cho phép bắt đầu kiểm thử và tích hợp ngay sau khi công việc thiết kế bắt đầu, điều này loại bỏ sự chậm trễ có thể gặp phải nếu phần cứng nhúng chưa có sẵn. Nó có thể tiết kiệm khoản đầu tư đáng kể trong việc tạo sản phẩm mẫu sớm không cần thiết với kiến trúc không khả thi. Ngay cả khi bạn có sẵn phần cứng, tích hợp liên tục đòi hỏi phải xây dựng liên tục.
Nếu bạn mong muốn xem kết quả càng sớm, thì môi trường xây dựng của bạn càng trở nên đắt. Bởi vì mục đích chính của tích hợp liên tục là cung cấp kết quả càng nhanh càng tốt, việc mô phỏng cho phép bạn kiểm thử mà không cần chi phí phần cứng quá cao. Nó cũng cung cấp một cách dễ dàng hơn để trao đổi thông tin về chức năng của thành phần, cách này chính là pair programming (lập trình theo cặp đôi) và "code review (rà soát mã)", rất phổ biến trong phát triển agile.
### Tự động hóa quá trình build
Tích hợp liên tục đòi hỏi phải tự động hóa quá trình build, tức là khả năng phần mềm được tự động biên dịch và liên kết thành tệp thực thi. Tốc độ là quan trọng bởi vì quá trình build một ứng dụng lớn có thể mất một thời gian dài. Nếu không có công cụ build lớn, nhanh chóng, đáng tin cậy, thì bạn sẽ thiếu những thông tin cần thiết để giải quyết các vấn đề tích hợp phát sinh. Khi build, nếu có các xung đột hay lỗi thì trình build sẽ tự động thông báo. Vì vậy, nếu phát hiện vấn đề thì các nhà phát triển cùng làm việc để giải quyết xung đột thông qua việc kiểm tra bản build trước đó trên một mô phỏng phần cứng mà không làm trì hoãn các nhà phát triển khác. Nhưng để đạt được hiệu quả này, việc xây dựng tích hợp phải diễn ra liên tục, phải tạo ra bản build mới ngay sau khi kết thúc bản build trước đó. Điều này rất khác với cách build hàng ngày hoặc hàng tuần mà các quá trình khác sử dụng.
Tất nhiên, phương pháp này đòi hỏi tự động hóa quá trình build, bởi vì sẽ là không thực tế khi giao cho ai đó chỉ với một nhiệm vụ là ngồi build suốt cả ngày. Hơn nữa, quá trình build cần được thực hiện một cách nhanh chóng, điều này đòi hỏi phải chạy đa luồng (multithreaded). Quá trình multithreaded build chính là cách build nhiều thành phần song song cùng lúc, giúp giảm bớt thời gian build. Nó đòi hỏi nhiều phần cứng hơn và kịch bản phức tạp hơn. Kịch bản càng trở nên phức tạp, thì công cụ quản lý việc xây dựng càng trở nên giá trị hơn.
**Quản lý ** **công việc **
Khái niệm agile là việc phân chia công việc thành những phần công việc nhỏ, dễ quản lý. Đây cũng là tiền đề cơ bản đằng sau phương pháp tích hợp liên tục: để sửa các lỗi của bạn ngay từ ban đầu. Điều này sẽ ngăn không cho chúng kết hợp thành các vấn đề lớn hơn, khó giải quyết hơn sau này.
Một trong những điều mà kỹ thuật này mang lại là khả năng cung cấp các bản phát hành nhỏ, hoạt
động được, đã được xây dựng và kiểm thử nhiều ngày theo tiến độ của dự án. Mỗi bản
phát hành giúp giảm rủi ro của dự án bằng cách xác thực kiến trúc, các yêu cầu và
ước tính lịch trình của nhóm. Theo phương pháp agile, những công việc cần phải được
hoàn thành được gọi là
*tồn đọng (backlog)*. Khi bạn bắt đầu chia công việc
thành các phần nhỏ hơn, gọi là *các chặng (sprints)*, công việc được phân bổ
cho một sprint được gọi là *sprint backlog*. Phần công việc còn lại được phân
bổ cho các sprint trong tương lai được gọi là *project backlog*. Mục tiêu là
nhóm các hạng mục công việc thành một sprint để có thể hoàn thành được trong khoảng
thời gian xác định của sprint.
Quy trình này phụ thuộc nhiều vào việc thu thập số liệu để đội có thể dự đoán chính xác lượng thời gian mà nhiệm vụ sẽ đòi hỏi và, do đó số lượng tác vụ có thể phù hợp với một sprint. Tuy nhiên, dù cho những số liệu này là bao nhiêu, thì việc thu thập dữ liệu là rất mệt mỏi ngay cả đối với nhóm nhỏ. Vì các nhóm nhỏ được gom lại với nhau để tạo ra sản phẩm phức tạp hơn, nên các tác vụ khó hoàn thành theo cách thủ công.
Có rất nhiều sản phẩm trên thị trường giúp tổ chức công việc, theo dõi hoàn thành công việc và thống kê các số liệu liên quan đến công việc đó như: công việc đã thực hiện được bao nhiêu, nhanh đến đâu, tốt đến mức nào vv... Khi theo đuổi phương pháp tích hợp liên tục, thì các lỗi về tích hợp được đánh dấu là high-priority (mức độ ưu tiên cao) và được thêm vào backlog (danh sách các công việc tồn đọng). Về mặt này, những sản phẩm tốt nhất trên thị trường cung cấp một số mức độ tích hợp giữa các hạng mục công việc mới và hệ thống quản lý quá trình build, do đó lỗi được xác định sau mỗi lần build có thể được sửa một cách nhanh chóng và tích hợp với các hạng mục công việc đang có, tăng dần theo mức ưu tiên và được chuyển đến nhóm phù hợp.
### Quản lý chất lượng
Quản lý chất lượng là phương pháp phát triển vòng đời để đảm bảo rằng tất cả các yêu cầu cho sản phẩm của bạn đã được kiểm tra. Nỗ lực này cần được tổ chức và hiểu đúng để các bài kiểm thử chính xác có thể được cập nhật khi các yêu cầu thay đổi. Quản lý chất lượng giúp các nhà quản lý dự án trả lời những câu hỏi sau:
- Nếu sản phẩm của tôi phải được phát hành vào tuần tới, phần nào sẽ có nguy cơ cao nhất?
- Chúng ta có thể phát hành mà không có yêu cầu ở mức thấp hơn?
- Đây có phải là bản phát hành có chất lượng cao hay không?
Trong khi đối mặt với áp lực thị trường rằng phải đáp ứng nhanh và tăng tốc chu kỳ sản phẩm, những câu hỏi này có thể giúp doanh nghiệp tự tin phát hành sản phẩm ra thị trường. Các nhà quản lý hiểu rõ sẽ biết cách bổ sung các tài nguyên nào, tính năng nào nên bỏ đi và thương lượng lại ngày giao hàng để đạt lợi thế tối đa nhất.
Với phương pháp phát triển theo hướng kiểm thử, việc kiểm thử trở thành vấn đề trung tâm hơn với các nỗ lực phát triển. Theo phương pháp phát triển theo hướng kiểm thử, bạn viết bài kiểm thử dựa trên yêu cầu, và sau đó bạn phát triển mã cho đến khi nó vượt qua bài kiểm thử đó. Điều này đảm bảo rằng không có chức năng bổ sung nào được tạo ra, đó sẽ là thứ mà nhóm phát triển gọi là "mạ vàng (gold plating)". Thậm chí nếu bạn có một ý tưởng về một tính năng hay chức năng mới cho sản phẩm nhưng những điều này không có trong yêu cầu thì việc thêm vào sẽ làm mất thời gian và có thể bị trễ dự án. Đồng thời khiến cho khách hàng không hài lòng.
**Tự động hóa kiểm thử**
Khi bạn thực hiện quá trình build nhiều lần, thì nhóm phát triển được yêu cầu kiểm thử lại các
chức năng đã làm việc trong các phiên bản trước. Quá trình kiểm thử lại này, trước
đây được biết đến là "mã tốt (good code)", thì nay được gọi là
*kiểm thử truy hồi
(regression testing)*. Nó đảm bảo rằng những đoạn mã trước đây sẽ không bị
lỗi khi bạn thêm vào một tính năng mới nào đó. Với phương pháp tích hợp liên tục,
kiểm thử truy hồi tự động được viết thành kịch bản lệnh để chạy ở bước cuối cùng của
mỗi lần build. Điều này cho phép các nhà phát triển có được các thông tin phản hồi
ngay lập tức về các lỗi được tìm thấy trong lần build mới. Đó là những cảnh báo cho
nhà phát triển biết rằng mã mới mà họ đã tạo ra có làm việc (hoặc không làm việc)
như yêu cầu hay không. Nếu không có kiểm thử truy hồi, các nhà phát triển sẽ chỉ
biết rằng họ đã build thành công. Bởi vì dù sao thì cũng phải thực hiện các bài kiểm
thử, cho nên nếu ban đầu bạn sử dụng phương pháp phát triển theo hướng kiểm thử thì
sẽ không phát sinh thêm công việc này. Nó đơn giản chỉ là đảo ngược trật tự của công
việc bằng cách trước tiên tạo ra các bài kiểm thử, sau đó mới tạo mã.
Dự án phát triển theo quy trình nước truyền thống có thể sống sót mà không thực hiện bất kỳ việc kiểm thử tự động nào. Dự án có thể được mô tả, xây dựng và sau đó được kiểm thử không ngừng bởi rất nhiều người. Nhưng khi bạn phát hành sản phẩm một cách thường xuyên thì lúc này mới phát sinh vấn đề. Đó là không thể kiểm thử thủ công các hệ thống đang được build nhiều lần trong một ngày.
### Sự cộng tác
Tổ chức phần mềm IBM Rational từ lâu đã là một người ủng hộ sự cộng tác như là yếu tố quan trọng cho sự phát triển và phân phối thành công hệ thống. Nhưng trong phương pháp tích hợp liên tục, nơi mà cả hai nhóm phần mềm và phần cứng đều tham gia, sự cộng tác không chỉ là việc kết hợp nhuần nhuyễn sản phẩm của các đội, mà còn là sự hiểu biết đầy đủ về các yêu cầu, tính năng và thời hạn.
Đối với những kiến trúc tốt thì cho phép kiểu cộng tác này một phần vì mọi người có thể hiểu tốt hơn các phụ thuộc giữa các thành phần khác nhau mà họ đang xây dựng. Với việc quản lý danh mục dự án, bạn có thể hiểu các tính năng, việc tái sử dụng và phân bổ tài nguyên. Nhưng trong các dự án mà phần cứng và phần mềm cùng phát triển, đó cũng là điều quan trọng để quản lý các yêu cầu và đưa ra quyết định thông minh khi nào những yêu cầu có thể thay đổi và khi nào chúng không được thay đổi.
Các dự án như vậy thường dính líu đến nhiều bên liên quan ở nhiều cấp độ của việc ra quyết định. Cộng tác tốt sẽ giúp làm thỏa mãn các bên liên quan. Nó đảm bảo rằng sản phẩm tốt phải được tạo ra và rằng các sai lệch so với các mục tiêu rộng lớn hơn được xác định một cách nhanh chóng. Điều này tạo ra một sản phẩm thỏa mãn tốt hơn nhu cầu của khách hàng.
## Tóm tắt
Từ góc độ kỹ thuật, tích hợp liên tục (Continuous Integration - CI) giúp các nhóm làm việc hiệu quả hơn. Các nhóm này có thể có chức năng liên quan nhau, tạo ra phần cứng và phần mềm làm việc cùng nhau. Họ có thể làm việc ở những nơi khác nhau, bởi vì công việc tích hợp không ngừng sẽ đảm bảo rằng bạn không đi lệch các thiết kế. Mọi người có thể làm việc trong các nhóm lớn, bởi vì các thành phần khác nhau của hệ thống phức tạp sẽ làm việc cùng nhau đảm bảo hơn. Nó giải quyết nhiều vấn đề sớm mà các nhóm phát triển theo phương pháp agile có thể đã trải qua nếu không tích hợp liên tục. Việc phối hợp phương pháp tích hợp liên tục với phương pháp phát triển theo hướng kiểm thử đã bổ trợ cho phương pháp agile, bởi vì nó cho phép phương pháp agile làm việc hiệu quả hơn.
Từ góc độ kinh doanh, phương pháp tích hợp liên tục cung cấp các kết quả nghiệp vụ tốt hơn bằng cách cho phép cho các nhóm đều tham gia. Nghĩa là, họ có thể đưa sản phẩm ra thị trường nhanh hơn, bằng cách tìm ra các vấn đề khi chúng còn mới và nhỏ, không phải chờ đợi cho đến khi chúng trở nên lớn và khó sửa chữa. Họ cũng có thể đáp ứng tốt hơn yêu cầu đưa thêm tính năng mới vào sản phẩm trong lúc đang phát triển. Điều này tạo ra một sản phẩm tốt hơn cho khách hàng, đó là hứa hẹn thực sự của sự linh hoạt.
## Tài nguyên
### Học tập
- Nghe bản tin
[Đến thời kỳ của phương pháp Tích hợp liên tục (CI)](http://www-01.ibm.com/software/rational/podcasts/2012/). Bạn vui lòng tìm bản tin số #204.
- Xem bản tin
[Áp dụng phương pháp Tích hợp liên tục trong quy trình agile để phát triển phần mềm nhúng](https://event.on24.com/eventRegistration/EventLobbyServlet?target=registration.jsp&eventid=406798&sessionid=1&key=4E749C0C178785C81FC51731CC6F20C3&sourcepage=register).
- Để biết thêm thông tin về quản lý chất lượng:
- Hãy xem bài viết của Moshe Cohen,
[Quản lý chất lượng thông minh hơn: Cách nhanh nhất để tạo ưu thế cạnh tranh](http://www.ibm.com/common/ssi/cgi-bin/ssialias?subtype=WH&infotype=SA&appname=SWGE_RA_QM_USEN&htmlfid=RAW14273USEN&attachment=RAW14273USEN.PDF)(Đây là tài liệu White Paper về những tư tưởng lãnh đạo của IBM Software, định dạng PDF được phát hành tháng 6 năm 2011).
- Hãy tìm hiểu trang web
[Quản lý chất lượng và kiểm thử của IBM](http://www.ibm.com/software/products/us/en/category/SW730).
- Hãy xem bài viết của Moshe Cohen,
- Để biết thêm thông tin về phương pháp Tích hợp liên tục, hãy
xem
[Các thực tiễn về phương pháp Tích hợp liên tục](http://martinfowler.com/articles/continuousIntegration.html#PracticesOfContinuousIntegration)trên trang web của Martin Fowler.
- Hãy truy cập
[Trang phần mềm Rational trên developerWorks](http://www.ibm.com/developerworks/rational/?S_TACT=105AGY75)để có các tài nguyên kỹ thuật và thực hành tốt nhất cho các sản phẩm Software Delivery Platform của Rational.
- Đăng ký
[nhận bản tin developerWorks hàng tuần qua email](https://www.ibm.com/developerworks/newsletter/?S_TACT=105AGY75), và chọn chủ đề để theo dõi.
- Theo dõi
[các sự kiện kỹ thuật và các bản tin trên developerWorks](http://www.ibm.com/developerworks/offers/techbriefings/events.html?S_TACT=105AGY75)về các sản phẩm của IBM và các chủ đề ngành công nghệ thông tin.
- Tham dự
[các lớp học miễn phí trên developerWorks](http://www.ibm.com/developerworks/offers/techbriefings/?S_TACT=105AGY75)để nhanh chóng tiếp cận các sản phẩm và công cụ của IBM, cũng như xu hướng của ngành công nghệ thông tin.
- Xem
[các bài demo theo yêu cầu trên trang developerWorks](http://www.ibm.com/developerworks/offers/lp/demos/?S_TACT=105AGY75), từ việc cài đặt sản phẩm và hướng dẫn thiết lập cho người mới bắt đầu đến các chức năng cao cấp hơn cho các nhà phát triển có kinh nghiệm.
### Lấy sản phẩm và công nghệ
- Tải về
[phiên bản dùng thử miễn phí](http://www.ibm.com/developerworks/rational/downloads/?S_TACT=105AGY75)của phần mềm Rational. [So sánh và đánh giá các sản phẩm phần mềm của IBM](http://www.ibm.com/developerworks/downloads/?S_TACT=105AGY75)theo cách riêng của bạn: Bạn có thể tải về để dùng thử, dùng thử trực tuyến, sử dụng trong môi trường đám mây, hoặc dành một vài giờ với [SOA Sandbox](http://www.ibm.com/developerworks/downloads/soasandbox/index.html?S_TACT=105AGY75)để học cách triển khai một kiến trúc hướng dịch vụ hiệu quả.
### Thảo luận
- Tham gia
[diễn đàn về phần mềm Rational](http://www.ibm.com/developerworks/forums/dw_rforums.jspa?S_TACT=105AGY75)để đặt câu hỏi và thảo luận.
- Tham gia thảo luận và nâng cao chuyên môn của bạn bằng cách
vào
[các diễn đàn của Rational](http://www.ibm.com/developerworks/forums/dw_rforums.jspa?S_TACT=105AGY75), [cafés](http://www.ibm.com/developerworks/rational/community/cafe/?S_TACT=105AGY75)và [thư viện wikis](https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?lang=en_US#/wiki/Rational%20Wiki%20Central/page/Rational%20Wiki).
- Tham gia
[cộng đồng Rational](http://ibm.co/rationalcommunity)để chia sẻ kinh nghiệm của bạn về phần mềm Rational và được kết nối tới các đồng nghiệp.
- Hãy dành ít thời gian để
[cùng đánh giá và xem xét](http://www-01.ibm.com/software/rational/review/?S_CMP=HIVIS&ca=dti-hivisratraterank&ca=dth-rJoin)phần mềm Rational.
## Bình luận
[Vùng dữ liệu trên developerWorks](http://www.ibm.com/developerworks/vn/views/data/libraryview.jsp)
Khám phá các bài viết xoay quanh lĩnh vực dữ liệu, Quản lý hệ thống thông tin
[Vùng mã nguồn mở trên developerWorks](http://www.ibm.com/developerworks/vn/views/opensource/libraryview.jsp)
Xem các bài viết về HTML, CSS, JavaScript,...
[Điện toán đám mây](http://www.ibm.com/developerworks/vn/views/cloud/libraryview.jsp)
Tìm hiểu về điện toán đám mây

WARC-Type: response

Content-Type: application/http; msgtype=response

Content-Language: en-US

Connection: close

Vary: Accept-Encoding

Content-Type: text/html; charset=UTF-8


text:
Hôm nay :
Trang chủ
Dịch vụ
CÔNG TY KỸ THUẬT KHO LẠNH BÁCH KHOA
Tất cả sản phẩm
Giới Thiệu
Liên Hệ Mua Hàng
Tin Tức
Hôm nay:
Chào mừng quý khách đến với website của chúng tôi. Chúng tôi luôn mong muốn đem đến sự hài lòng cho quý khách hàng.
Danh Mục Sản Phẩm
KHO LẠNH
MÁY LÀM LẠNH NƯỚC CÔNG NGHIỆP (WATER CHILLER)
CỬA KHO LẠNH
VỎ KHO LẠNH
TỦ ĐIỆN KHO LẠNH
KHÁC
CỤM MÁY NÉN DÀN NGƯNG
Cụm máy dàn ngưng TECUMSEH
Cụm máy dàn ngưng BITZER
Cụm máy dàn ngưng EMERSON-COPELAND
Cụm máy dàn ngưng SANYO
Cụm máy dàn ngưng MITSUBISHI
Cụm máy dàn ngưng MANEUROP
DÀN LẠNH CÔNG NGHIỆP
Dàn lạnh ECO
Dàn lạnh KUBA
Dàn lạnh TRUNG QUỐC
Dàn lạnh GUNTNER
Dàn lạnh Bohn
Dàn lạnh Meluck
Sản phẩm xem nhiều
Máy Làm Lạnh Nước Công nghiệp (water chiller)
KHO LẠNH Y TẾ
HỆ THỐNG VÀ THIẾT BỊ KHO LẠNH BẢO QUẢN
Cửa Kho Lạnh
KHO LẠNH TRỮ HẠT GIỐNG
KHO LẠNH THỦY HẢI SẢN
KHO LẠNH BẢO QUẢN KEM
KHO LẠNH CHỨA ĐÁ VIÊN
Cụm máy nén dàn ngưng EMERSON-COPELAND
Hỗ Trợ Trực Tuyến
Phòng kỹ thuật
0917.846.495
Phòng kinh doanh
0936.500.501
Sản phẩm xem nhiều
Máy Làm Lạnh Nước Công nghiệp (water chiller)
KHO LẠNH Y TẾ
HỆ THỐNG VÀ THIẾT BỊ KHO LẠNH BẢO QUẢN
Cửa Kho Lạnh
KHO LẠNH TRỮ HẠT GIỐNG
KHO LẠNH THỦY HẢI SẢN
Từ khóa
dan-lanh
kho-lanh
may-nen-dan-ngung
san-pham
tat-ca-san-pham
tin-tuc
vo-kho-lanh
Thông tin giỏ hàng của bạn
Ðóng
name
thumb
Quantity
Increment
Decrement
Total
Số lượng:
0
Giá tiền:
VND00,00
Tổng cộng:
VND00,00
Xóa hết
[giaban][/giaban]
[tomtat]
[/tomtat]
[giaban][/giaban]
[tomtat]
[/tomtat]
[giaban][/giaban]
[tomtat]
[/tomtat]
[giaban][/giaban]
[tomtat]
[/tomtat]
[giaban][/giaban]
[tomtat]
[/tomtat]
[giaban][/giaban]
[tomtat]
[/tomtat]
[giaban][/giaban]
[tomtat]
[/tomtat]
Bài đăng cũ hơn »
Trang chủ
Bài Đăng Mới Nhất
Sản phẩm - Dịch Vụ
Xem tất cả »
Cụm Máy Nén Dàn Ngưng
Xem tất cả »
Dàn Lạnh Công Nghiêp
Xem tất cả »
Tin tức - Sự kiện
Xem tất cả »
Dịch Vụ
Xem tất cả »
Trang chủ
Thông tin
cách mua hàng
quy định chung
tuyển cộng tác viên
liên hệ mua hàng
sitemap
bản đồ
Thông tin
About Me
Mua hàng
Liên hệ
Tin tức
Quảng cáo
Hướng dẫn
Thông tin
About Me
Mua hàng
Liên hệ
Tin tức
Quảng cáo
Hướng dẫn
Kết nối với chúng tôi
Liên hệ mua hàng
0936.500.501
CÔNG TY TNHH KỸ THUẬT LẠNH BÁCH KHOA
787/8, Trường Chinh, P.Tây Thạnh, Q.Tân Phú, TP.HCM
Copyright © Website
CÔNG TY KỸ THUẬT KHO LẠNH BÁCH KHOA
BACK TO TOP

X-XSS-Protection: 1; mode=block

Server: GSE

Cache-Control: private, max-age=0

X-Content-Type-Options: nosniff


text: Kinh nghiệm mua chung cư đẹp nhất One 18 Long Biên Tọa lạc trên trục đường Ngọc Lâm sầm uất của quận Long Biên, sở hữu phong cách thiết kế hiện đại và ...


text:
Trang chủ
Chung cư cao cấp
Căn hộ cao cấp mặt tiền đường Nguyễn Duy Trinh Q.2
Tên người nhận
Email người nhận
Tin nhắn
Về MuaBanNhaDat | Nhận bản tin | FAQ | Điều khoản thỏa thuận | Bản quyền | Quy chế Sàn GDTMĐT | Tuyên bố từ chối bảo đảm | Liên hệ | Tuyển dụng | Bảng giá dịch vụ | Sitemap
MuaBanNhaDat © 2007 - 2016. Ghi rõ nguồn "MuaBanNhaDat.vn" khi phát hành lại thông tin từ website này.
Giấy phép số: 40/GP-TTDT, do Sở Thông tin và Truyền Thông TP. Hồ Chí Minh cấp ngày 22/04/2015
Giấy Chứng Nhận Đầu Tư Số: 411022000534; Ngày cấp: 20/01/2014 do Sở Kế Hoạch và Đầu Tư Tp.HCM cấp
Địa chỉ: Lầu 3 Tòa nhà Copac, Số 12, Tôn Đản, Phường 13, Quận 4, TP.HCM
Follow us on Facebook Linkedin Google+
Technology powered by - Copyright ©2016 by Ringier Vietnam

Cache-Control: private

Content-Type: text/html; charset=utf-8

Server: MBND's Server

X-Frame-Options: SAMEORIGIN


text:
Trang chủ
Chung cư cao cấp
Sở hữu căn hộ Hà Đô quận 10 thanh toán 300tr
Tên người nhận
Email người nhận
Tin nhắn
Về MuaBanNhaDat | Nhận bản tin | FAQ | Điều khoản thỏa thuận | Bản quyền | Quy chế Sàn GDTMĐT | Tuyên bố từ chối bảo đảm | Liên hệ | Tuyển dụng | Bảng giá dịch vụ | Sitemap
MuaBanNhaDat © 2007 - 2016. Ghi rõ nguồn "MuaBanNhaDat.vn" khi phát hành lại thông tin từ website này.
Giấy phép số: 40/GP-TTDT, do Sở Thông tin và Truyền Thông TP. Hồ Chí Minh cấp ngày 22/04/2015
Giấy Chứng Nhận Đầu Tư Số: 411022000534; Ngày cấp: 20/01/2014 do Sở Kế Hoạch và Đầu Tư Tp.HCM cấp
Địa chỉ: Lầu 3 Tòa nhà Copac, Số 12, Tôn Đản, Phường 13, Quận 4, TP.HCM
Follow us on Facebook Linkedin Google+
Technology powered by - Copyright ©2016 by Ringier Vietnam


text:
- Bạn đang xem tin rao mã số: 3883801
- Mọi thông tin liên quan tới tin rao này là do người đăng tin đăng tải và chịu trách nhiệm.
- Nếu quý vị phát hiện có sai sót hay vấn đề gì như "Tin rao quá hạn, Tin rao không đúng sự thật, Không liên lạc được người rao tin, Lý do khác, ..." xin hãy thông báo cho Nhaban.com.
Đường 3, Thị Trấn Ba Hàng, Phổ Yên, Thái Nguyên
Điện thoại: 0904619024,
Tìm nhà đất theo giấy tờ Quận Ba Đình
Tìm nhà đất theo vị trí Quận Ba Đình
Tìm nhà đất theo hướng Quận Ba Đình

markdown:
|Địa chỉ||Khoảng cách||Xem đường đi|
- Bạn đang xem tin rao mã số: 3883801
- Mọi thông tin liên quan tới tin rao này là do người đăng tin đăng tải và chịu trách nhiệm.
- Nếu quý vị phát hiện có sai sót hay vấn đề gì như "Tin rao quá hạn, Tin rao không đúng sự thật, Không liên lạc được người rao tin, Lý do khác, ..." xin hãy thông báo cho Nhaban.com.
Đường 3, Thị Trấn Ba Hàng, Phổ Yên, Thái Nguyên
**Điện thoại:** 0904619024,
Tìm nhà đất theo giấy tờ Quận Ba Đình
Tìm nhà đất theo vị trí Quận Ba Đình
Tìm nhà đất theo hướng Quận Ba Đình

WARC-Truncated: length

Pragma: no-cache

Cache-Control: max-age=3600, public

Vary: Accept-Encoding,User-Agent


text:
- Hoạt động cuối:
- 2/3/12
- Tham gia ngày:
- 2/3/12
- Số km:
- 0
- Được đổ xăng:
- 0
- Mã lực:
- 0
- Xăng dự trữ:
- 273 lít xăng
Chia sẻ trang này
Cáp Thị Quỳnh Đông
Tài xế O-H
- Cáp Thị Quỳnh Đông được nhìn thấy lần cuối:
- 2/3/12
-
- Đang tải...
- Đang tải...
-
Tương tác

markdown:
![ Cáp Thị Quỳnh Đông](http://www.oto-hui.com/styles/xenith/xenforo/avatars/avatar_l.png)
- Hoạt động cuối:
- 2/3/12
- Tham gia ngày:
- 2/3/12
- Số km:
- 0
- Được đổ xăng:
- 0
- Mã lực:
[0](members/cap-thi-quynh-dong.122295/trophies)
- Xăng dự trữ:
-
[273 lít xăng](bank/transfer?to=C%C3%A1p+Th%E1%BB%8B+Qu%E1%BB%B3nh+%C4%90%C3%B4ng&rtn=ref) [$273.00](credits/transfer?receiver=C%C3%A1p+Th%E1%BB%8B+Qu%E1%BB%B3nh+%C4%90%C3%B4ng)
### Chia sẻ trang này
# Cáp Thị Quỳnh Đông
Tài xế O-H
- Cáp Thị Quỳnh Đông được nhìn thấy lần cuối:
- 2/3/12
-
- Đang tải...
- Đang tải...
-
### Tương tác


text:
- Hoạt động cuối:
- 23/12/11
- Tham gia ngày:
- 12/12/11
- Số km:
- 0
- Được đổ xăng:
- 0
- Mã lực:
- 0
- Xăng dự trữ:
- 311 lít xăng
Chia sẻ trang này
UTC_SO.SAD
Tài xế O-H
- UTC_SO.SAD được nhìn thấy lần cuối:
- 23/12/11
-
- Đang tải...
- Đang tải...
-
Tương tác
Tài xế O-H

markdown:
![ UTC_SO.SAD](http://www.oto-hui.com/styles/xenith/xenforo/avatars/avatar_l.png)
- Hoạt động cuối:
- 23/12/11
- Tham gia ngày:
- 12/12/11
- Số km:
- 0
- Được đổ xăng:
- 0
- Mã lực:
[0](members/utc_so-sad.110778/trophies)
- Xăng dự trữ:
-
[311 lít xăng](bank/transfer?to=UTC_SO.SAD&rtn=ref) [$311.00](credits/transfer?receiver=UTC_SO.SAD)
### Chia sẻ trang này
# UTC_SO.SAD
Tài xế O-H
- UTC_SO.SAD được nhìn thấy lần cuối:
- 23/12/11
-
- Đang tải...
- Đang tải...
-
### Tương tác


text: mình mới tốt nghiệp cao đẳng khoa cơ khí động lực trường cao dẳng công thương tpHCM.sau khi ra trường mình đã làm ở garage 3 tháng về oto tải mình cũng bít làm sơ về gầm, xin các bác biết chỗ nào cần thợ phụ việc xe du lich thì chỉ mình với mình rất thích sửa xe du lich nhưng ko biết chỗ nào.sdt của mình 0974810461.


text: Chiếc xe của công nghệ - Niềm tự hào của BMW đã được định giá 10.950 bảng (khoảng 16.000 USD), và phiên bản ‘Sport’ có mức giá 12.235 bảng (hơn 18.000 USD). BMW mới thông báo giá cho S1000RR ở Anh. Phiên bản tiêu chuẩn có giá cạnh tranh 10.950 bảng (khoảng 16.000 USD), và phiên bản ‘Sport’ có mức giá 12.235 bảng (hơn 18.000 USD). Chiếc S1000RR Sport sử dụng hệ thống phanh chống bó cứng phanh ABS, chức năng kiểm soát lực kéo tự động và hỗ trợ người lái sang số. Khách hàng lựa chọn phiên bản tiêu chuẩn cũng có thể trang bị thêm phụ kiện cho xe, như: hệ thống phanh chống bó cứng ABS dành cho xe đua, chức năng kiểm soát lực kéo, hỗ trợ sang số, thiết bị báo chống trộm và lớp màu BMW Motorrad Motorsport. Ian Furse giám đốc kinh doanh của BMW Motorrad trụ sở Anh đã nói: “Ở Anh, chúng tôi đã nỗ lực để giới thiệu S1000RR ra thị trường siêu xe thể thao với giá thực tế và vừa túi tiền của người mua xe”. BMW S1000RR có trọng lượng khô 183 kg và trọng lượng đầy đủ khi vận hành trên đường là 206.5 kg. Xe trang bị động cơ 4 xy lanh thẳng hàng sản sinh công suất 193 mã lực ở vòng tua máy 13.000 vòng/ phút và mômen xoắn 112Nm tại tốc độ vòng tua 9.750 vòng/phút. Chỉ bằng động tác ấn một nút điều khiển, chủ nhân của chiếc S1000RR có thể lựa chọn 4 chế độ lái. Những chế độ này được thiết kế để vận hành S1000RR một cách tối ưu trên những bề mặt ướt, đường thường và đặc biệt với chế độ dành cho đường đua. BMW tự hào vì S1000RR là siêu xe thể thao duy nhất kết hợp hệ thống chống bó cứng phanh ABS, chức năng kiểm soát lực kéo DTC và hệ quản lý 4 chế độ lái ưu việt. Ngoài ra, tính năng hỗ trợ sang số giúp người lái thay đổi tốc độ thông qua bộ truyền động mà không cần sử dụng khớp ly hợp, mômen xoắn và lực kéo không đổi. Đơn đặt hàng sẽ được đáp ứng từ tháng 1 năm 2010. Theo AuTopro


text:
Phim nói về tương lai người ngoài hành tinh đã xâm nhập vào Trái Đất. Những con người cảm thấy mình đang sống dưới sự cai trị của người ngoài hành tinh. Những con người sợ tính mạng, sự tự do sẽ mất và những điều kỳ lạ sẽ làm tổn thương đến họ. Và cuối cũng điều... [Xem thêm]
Tips: Đăng nhập để giảm thiểu quảng cáo trên website

markdown:
Phim nói về tương lai người ngoài hành tinh đã xâm nhập vào Trái Đất. Những con người cảm thấy mình đang sống dưới sự cai trị của người ngoài hành tinh. Những con người sợ tính mạng, sự tự do sẽ mất và những điều kỳ lạ sẽ làm tổn thương đến họ. Và cuối cũng điều... [
[Xem thêm](http://www.phimle.tv/phim/ket-thuc-tuoi-tho-phan-1-8088/)]
Tips: Đăng nhập để giảm thiểu quảng cáo trên website

Server: cloudflare-nginx

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0


text:
NHL Detroit Red Wings Rubber Duckie with Squeak Noise Effect -PACK OF 3
Sản phẩm này được bán tại www.amazon.com
Thương hiệu: JF Sports Canada
Ngay sau khi quý khách đặt hàng và thanh toán, ShipTo.vn sẽ mua sản phẩm từ Mỹ và vận chuyển về Việt Nam
Thời gian giao hàng dự kiến từ 10 – 20 ngày làm việc kể từ khi thanh toán
Size: 3 Pack
- 3 Pack
Color: Detroit Red Wings
- Detroit Red Wings
Chọn số lượng:Xem chi tiết sản phẩm tại www.amazon.com
-
Giá giảm 10-50%
so với hàng xách tay
-
100% sản phẩm thật
được mua trực tiếp từ Mỹ
-
Hoàn tiền 100%
nếu hàng bị thất lạc hư hỏng
-
Miễn phí dịch vụ
nếu giao hàng trễ
Product Features
Decorated with the team logo
Each one makes a squeak noise
Officially licensed
Made in China
Product Description
Product information
Mua hàng theo yêu cầu
-
1.Đặt mua
Đặt mua những sản phẩm được ShipTo.vn tuyển chọn, hoặc gửi link của sản phẩm muốn mua để nhận báo giá.
-
2.Thanh toán
Thanh toán cho ShipTo.vn (tiền mặt, chuyển khoản, hoặc thẻ tín dụng).
-
3.Vận chuyển
ShipTo.vn mua hàng từ nước ngoài, chuyển về Việt Nam, và lo tất cả thủ tục hải quan.
-
4. Giao hàng
ShipTo.vn giao hàng tận nơi miễn phí trong vòng 10-20 ngày làm việc kể từ ngày thanh toán.
Vận chuyển theo yêu cầu
-
1.Đăng ký địa chỉ Mỹ
Đăng ký tài khoản ShipTo.vn có ngay địa chỉ riêng tại Mỹ.
-
2.Tự mua hàng
Tự mua tại bất kỳ website nào và chuyển hàng tới địa chỉ Mỹ của bạn.
-
3.Vận chuyển
ShipTo.vn nhận hàng, kiểm hàng và chuyển quốc tế.
-
4. Giao hàng
ShipTo.vn thông quan, giao hàng tận tay và thu tiền dịch vụ.
ĐĂNG KÝ EMAIL ĐỂ BẮT ĐẦU

markdown:
[0](/mua-hang/gio-hang)
# NHL Detroit Red Wings Rubber Duckie with Squeak Noise Effect -PACK OF 3
Sản phẩm này được bán tại
[www.amazon.com](http://www.amazon.com/Detroit-Rubber-Duckie-Squeak-Effect/dp/B0043AEWF2)
Thương hiệu:
[JF Sports Canada](/thuong-hieu/jf-sports-canada_th1820)
Ngay sau khi quý khách đặt hàng và thanh toán, ShipTo.vn sẽ mua sản phẩm từ Mỹ và vận chuyển về Việt Nam
Thời gian giao hàng dự kiến từ 10 – 20 ngày làm việc kể từ khi thanh toán
**Size:**
3 Pack
- 3 Pack
**Color:**
Detroit Red Wings
- Detroit Red Wings
Chọn số lượng:
[Xem chi tiết sản phẩm tại www.amazon.com](http://www.amazon.com/Detroit-Rubber-Duckie-Squeak-Effect/dp/B0043AEWF2)
-
Giá giảm 10-50%
so với hàng xách tay
-
100% sản phẩm thật
được mua trực tiếp từ Mỹ
-
Hoàn tiền 100%
nếu hàng bị thất lạc hư hỏng
-
Miễn phí dịch vụ
nếu giao hàng trễ
#### Product Features
Decorated with the team logo
Each one makes a squeak noise
Officially licensed
Made in China
#### Product Description
#### Product information
|Product Dimensions||8.3 x 4.1 x 4.1 inches|
|Shipping Weight||0.2 pounds|
|ASIN||B0043AEWF2|
|Item model number||REDDUC|
#### Mua hàng theo yêu cầu
-
1.Đặt mua
Đặt mua những sản phẩm được ShipTo.vn tuyển chọn, hoặc gửi link của sản phẩm muốn mua để nhận báo giá.
-
2.Thanh toán
Thanh toán cho ShipTo.vn (tiền mặt, chuyển khoản, hoặc thẻ tín dụng).
-
3.Vận chuyển
ShipTo.vn mua hàng từ nước ngoài, chuyển về Việt Nam, và lo tất cả thủ tục hải quan.
-
4. Giao hàng
ShipTo.vn giao hàng tận nơi miễn phí trong vòng 10-20 ngày làm việc kể từ ngày thanh toán.
#### Vận chuyển theo yêu cầu
-
1.Đăng ký địa chỉ Mỹ
Đăng ký tài khoản ShipTo.vn có ngay địa chỉ riêng tại Mỹ.
-
2.Tự mua hàng
Tự mua tại bất kỳ website nào và chuyển hàng tới địa chỉ Mỹ của bạn.
-
3.Vận chuyển
ShipTo.vn nhận hàng, kiểm hàng và chuyển quốc tế.
-
4. Giao hàng
ShipTo.vn thông quan, giao hàng tận tay và thu tiền dịch vụ.
[ Mở rộng](javascript:void(0);) [ Thu gọn](javascript:void(0);)
ĐĂNG KÝ EMAIL ĐỂ BẮT ĐẦU

Cache-Control: private, no-cache="Set-Cookie"

Set-Cookie: website_id=1; expires=Sun, 03-Dec-2017 17:00:00 GMT; path=/


text:
Trang chủ
Giới thiệu
Sản phẩm
Tin tức
Liên hệ FAQ
Cty Vĩnh Xuân TNHH In Quảng Cáo & Thương Mại.
Danh mục
Thời tiết
Hà Nội
Đà Nẵng
TP Hồ Chí Minh
Sản phẩm mới nhất
Sản phẩm xem nhiều nhất
Sản phẩm khuyến mại
Hỗ trợ
Tin tức
Thống kê
Số lượt xem:
240
Tổng số sản phẩm:
0
Gửi tin nhắn
Cty Vĩnh Xuân TNHH In Quảng Cáo & Thương Mại.
490 Trần Khát Chân, Q. Hai Bà Trưng,
- vinhxuanprint@newsvn.com
Bản quyền của
www.ThitruongOTC.com.vn

Content-Type: application/xhtml+xml; charset=utf-8