TDD là một trong những giáo lý được đề cao nhất trong phương pháp phát triển phần mềm Agile. Khó mà nói rằng bạn đã Agile, nếu bạn không viết nhiều test tự động, và không viết trước khi thực sự viết chương trình.

Nhưng theo kỷ luật của Agile, phải viết đến hai loại test tự động. Unit test: viết do lập trình viên, vì lập trình viên, bằng ngôn ngữ lập trình. Acceptance test: viết do bộ phận kinh doanh (và QA), vì bộ phận kinh doanh, bằng ngôn ngữ cấp cao (như FitNesse).

Vấn đề là, đối với lập trình viên ý nghĩa của hai loại test này là gì? Qui trình thế nào? Nên viết unit test và chương trình trước, rồi sửa chương trình để pass acceptance test? Hay viết chương trình để pass acceptance test rồi mới đến unit test?

Ngoài ra, sao lại cần hai loại test? Không thừa hay sao?

Nhân vật ấn tượng nhất trong tuyệt tác Tiếu Ngạo Giang Hồ có lẽ ai cũng đồng ý là Lệnh Hồ công tử. Kim Dung tiên sinh đã kể rất nhiều tình tiết trong đó Hồ công tử lâm vào tình huống bi đát (như mất hết công lực) khi đối địch nhưng rốt cuộc vẫn chiến thắng. Lí do bởi công tử hiểu rõ được yếu quyết nguồn gốc của các chiêu thức, nên có thể vận dụng vào kiếm chiêu của mình và hoá giải tình huống đối thủ đặt ra một cách dễ dàng.

Nếu như võ công chỉ có vài môn phái chiếm đa số như kiếm tông, khí tông thì lập trình cũng vậy, chỉ có vài paradigm chiếm thế thượng phong như lập trình thủ tục, lập trình hướng đối tượng. Học là học cái tinh thần, thỉnh thoảng đâu đó ta nghe nói dùng PHP4 cũng có thể lập trình hướng đối tượng như PHP5, ngôn ngữ Ruby hướng đối tượng viết bằng ngôn ngữ C không hướng đối tượng là vì vậy.

Bài viết này trình bày vài nét phác thảo cách viết C theo tinh thần hướng đối tượng.

Đã gọi là cộng đồng mạng, thì hoạt động chủ yếu đều diễn ra trên web. Hầu hết các trang web đều tổ chức theo mô hình forum. Ngay từ cái tên đã "chết" từ forum: Diễn đàn điện tử, Diễn đàn tin học...! Hệ quả không hay là hầu hết người Việt đều ngộ nhận trang web của các cộng đồng mạng đều là forum tuốt. Ngay như trang web này đề chữ "Blog cộng đồng về CNTT" to uỳnh, nhưng nhiều người vẫn còn nhầm đây là forum

Bài viết này phân tích vấn đề của mô hình forum, rồi đề ra giải pháp khắc phục.

Làm project ở công ty thì chắc chắn không là giải trí rồi. Vậy còn làm open source project thì sao? Xin nhái "Cử nhân khoa học máy tính không là kĩ sư phần mềm" để đặt tên cho chủ đề này.

Project ở công ty chịu nhiều ràng buộc (thời hạn, tài chính, nhân sự...) nên việc chúng thất bại là điều thường thấy. Thế còn open source project thì sao? Liệu chúng có thất bại không? Nếu thất bại thì thường vì nguyên nhân gì?

Hỏi

Đây là câu thường được hỏi. Tình huống thế này: Tôi vừa thảo luận với sếp, công ty chuyên làm web bằng Rails. Ông hoài nghi việc dùng BDD cho tất cả project, thường dùng câu "Còn tuỳ project nữa" để chống chế. "Project ngắn quá, nếu bỏ thời gian cho test thì không bù được chi phí". Ông nhấn mạnh viết test sẽ tốn thêm tiền vì phải viết 2 lần: viết test trước, rồi mới viết code.

Theo kinh nghiệm thực tế thì có thật thế không? BDD có đắt hơn không? Biết nhiều người sẽ trả lời "Không, vì test sẽ giúp đỡ nhức đầu về sau", nên xin nhấn mạnh câu hỏi là BDD với RSpec có làm project tốn kém thêm ở giai đoạn thực hiện, và có bao nhiêu phần đúng trong câu nói BDD không dành cho tất cả project?

Tôi làm việc trong ngày ngành phát triển phần mềm vì nó hứng thú và vì tôi yêu thích nó. Chứ không phải là bởi vì kiếm được nhiều tiền hay chỉ để san lấp thời gian từ bây giờ cho đến khi tôi chết. Tôi rất thích bài viết của Ron Jeffries về những hứng khởi ban đầu của Extreme Programming.

Tôi nghĩ rằng, tại thời điểm này, hầu hết những hứng khởi ấy đã gần như cạn kiệt. Extreme Programming đã trở thành một ngành công nghiệp, với đội ngũ tư vấn hùng hậu, cũng như rất nhiều sách được xuất bản hàng tháng. Mặt khác nó cũng đã đông cứng. Có thể nói như sau: cái mà xuất hiện với mục đích tìm ra chân lý với nhiều ý tưởng tốt hoặc không tốt nay đã trở thành một cái cứng nhắc yêu cầu nhiều sự rèn luyện, có cả tốt và rất không tốt. Ngày nay, nhiều lập trình viên tự cho rằng mình đang làm Extreme Programming bằng cách cho nó là 1 danh sách các đề nghị hấp dẫn. Họ lấy từ danh sách ấy những thứ họ thích (không có documentation) và bỏ qua những thứ họ không thích (phát triển test-driven, lập trình đôi). Điều này dẫn đến cái gọi là "Shoot From The Hip Programming" mà ai cũng biết rằng sẽ không hoạt động.

Nói cho cùng thì vẫn tốt để nhớ về một thời đẹp đẽ, một mùa xuân của sự đổi mới. Tôi kính trọng Ron vì đã bắt được những cảm xúc hứng khởi và niềm đam mê trong lập trình. Ed

Brian Marick, trong một bài blog rất hay, chỉ đến một mục rất sáng tạo về group think, German philosophy, and the old Saturday Night Live gang. Nó làm cho tôi suy nghĩ về Extreme Programming và phương pháp Agile. Gần đây tôi có nghĩ đến sự đam mê không nhỉ?

Bài viết này dành cho các bạn đang làm việc có yêu cầu phải trao đổi với khách hàng, ví dụ BSE (bò điên - Bridge Software Engineering). Bởi vì không ít bạn đã và đang đối xử rất tệ với khách hàng của công ty cả trong tư tưởng và lời lẽ.

Tôi biết đến Rands lần đầu khi có lần quá bận không thể viết blog. Vài độc giả bắt đầu bàn tán xem nên đọc cái gì, và blog Rands in Repose được khen. Tôi đọc liền. Ngay cả khi bận quá không có thời gian viết, tôi không bao giờ bận quá không dành thời gian đọc mọi bài viết do ai đó post.

Tôi đã đọc, và chắc chắn sau khi đọc xong bài dưới đây, bạn sẽ mò vào blog của Rands để đọc mọi bài viết ở đó.

Khi chương trình tiến hoá, sẽ cần suy tính lại những quyết định cũ và bắt tay sửa lại chương trình. Việc sửa lại, cấu trúc lại chương trình mà giữ nguyên tính năng gọi là refactor. Việc này trên lí thuyết hoàn toàn tự nhiên, nhưng thực tế lại rất phức tạp. Cấp quản lí bảo:

• Ê, chương trình chạy được sao lại phải sửa?
• Này, sửa lại sẽ mất thời gian, thay vì mất thời gian sửa chẳng thêm được tí tính năng nào, hãy tập trung thêm tính năng mới
• ĐM, người mới cứ sửa mã của người cũ thế này thì loạn

[SVVN số 29/2008] Theo GS làm thế nào để đào tạo được những sinh viên - là lực lượng lao động có thể đáp ứng được thực tế rất bất trắc, rất dễ thay đổi, chẳng hạn như thay đổi về ngành nghề hiện nay?

[Hòang Tụy] Rõ ràng trong thế giới bây giờ càng ngày càng phải chuyên sâu, mỗi người cần phải chuyên sâu vào nghề của anh thì anh mới có thể cạnh tranh được với những người khác, nhưng đồng thời lại có một xu hướng ngược lại anh phải có văn hóa phổ quát, chúng ta nói là văn hóa chung cũng được. Cho nên bây giờ tôi thấy Tổng thống Pháp Sarkozy nói một câu rất sâu sắc: Thế giới càng nhiều tri thức thì càng đòi hỏi phải có càng nhiều văn hóa phổ quát, văn hóa phổ quát càng tốt thì càng dễ thành công trong từng lĩnh vực chuyên môn. Bởi vì muốn làm tốt bất cứ một nghề gì cũng phải có hiểu biết về ngành lân cận, nhiều khi là cả những ngành rất xa nữa. Thứ hai là trong thời đại bây giờ, ngành nghề thay đổi rất nhanh, có nghề ngày hôm nay có đấy, ngày mai đã mất. Có nghề hôm nay chưa có ngày mai lại xuất hiện. Nếu chọn một nghề nào đó mà sau đó nó mất đi, nếu không có một văn hóa phổ quát thì không thể chuyển nghề được dễ dàng, không thể thích nghi với sự thay đổi rất nhanh chóng ngày nay. Cho nên hai cái đấy nhìn nhìn có vẻ mâu thuẫn, nhưng thực chất thì nó không mâu thuẫn. Thực chất nếu anh giải quyết tốt thì cái nọ sẽ bổ sung cho cái kia. Chính vì quan niệm như vậy cho nên cách đào tạo của ta hiện nay có nhiều điều không thích hợp.

Về mặt nghề nghiệp, kiến thức và kinh nghiệm là tài sản quan trọng nhất. Nhưng rất tiếc, chúng là tài sản càng để lâu càng mất giá. Kiến thức trở nên lỗi thời khi các kĩ thuật, ngôn ngữ, môi trường mới ra đời. Động lực của thị trường thay đổi hàng ngày có thể biến kinh nghiệm của bạn thành vô dụng hoặc không còn thích hợp. Với tốc độ phát triển của web hiện nay, điều này có thể xảy đến khá nhanh.

Khi giá trị của kiến thức của bạn giảm, giá trị của bạn trong mắt công ty hoặc khách hàng cũng giảm. Chúng ta muốn ngăn điều này xảy ra.