Tôi không hiểu vì sao mọi người lại xem phương pháp luận như kinh thánh. Tôi nghĩ ngay cả tác giả gốc cũng chỉ khác về định hướng, còn về tính giáo điều thì cũng chẳng khác là bao.
Ngay từ thời điểm chọn SQLite cho máy chủ production, bạn sẽ phải liên tục suy nghĩ xem khi nào nên chuyển sang hệ khác.
Ngày xưa, bản thân chi phí của DB (chi phí mua máy chủ, IDC, chi phí giấy phép, v.v.) khá đắt nên còn đáng để cân nhắc,
nhưng ngày nay, khi thứ gọi là triển khai chỉ bằng một cú nhấp đã khả thi, liệu có thực sự cần phải băn khoăn nữa không?
Chỉ riêng việc phá bỏ cơ chế ra quyết định theo chiều dọc và cải tiến lặp lại theo các chu kỳ ngắn cũng đã để lại cho chúng ta một thông điệp lớn rồi (đương nhiên các kỹ thuật/công cụ quản lý dự án cũng vậy).
Có vẻ kết luận rằng 'bản thân Agile đã không thể mang lại những góc nhìn mới, đồng thời quy chụp toàn bộ những người ủng hộ Agile thành các fan cuồng Agile một cách mù quáng' là hơi cực đoan.
Tôi đã đọc rất kỹ. Cả nội dung anh/chị viết trên blog nữa. Tôi không chắc phép so sánh này có phù hợp không, nhưng tôi nghĩ lý do tutorial đầu tiên của các ngôn ngữ luôn là Hello World!, và việc trước đây khi học phát triển web chúng ta làm ra forum, trang thương mại điện tử trong lúc học, rốt cuộc cũng đi cùng một quỹ đạo với điều anh/chị đã nói. Trước đây tôi từng nghĩ thế này: nếu có kỹ thuật đủ để làm được forum và trang thương mại điện tử, thì có thể hiện thực hóa được phần lớn các website. Và xét đến cùng, rốt cuộc lập trình chỉ đơn giản là có Input và Output mà thôi.
Có vẻ kết luận hơi quá đà. Việc thương mại hóa hay hình thức hóa có thể là vấn đề, nhưng không phải những công cụ như sprint hay backlog đã trở nên vô dụng. Chúng cũng đã giúp hình thành văn hóa họp hành mang tính ngang hàng và tập trung vào mục tiêu. Đúng là SDD đã trở nên quan trọng hơn, nhưng chính đặc tả đó vẫn có thể được viết nhanh theo cách cộng tác với AI, nên về bản chất vẫn là agile. Chỉ là sprint kéo dài 2 tuần đã được rút ngắn xuống còn vài giờ, còn bản chất của việc mài giũa lặp đi lặp lại thì vẫn y nguyên.
Đúng là một bài viết ngớ ngẩn. Cốt lõi là ngay cả spec cũng phải được viết theo cách agile... Agile là phản ứng nhanh trước những thay đổi trong yêu cầu của khách hàng và thích nghi với chúng.
Chính vì những người có sự hiểu lầm sai lệch và những tưởng tượng hời hợt về agile như thế này mà cả agile lẫn văn hóa phát triển đều đang đi sai hướng.
Theo một số tiêu chí thì ai cũng đều agile cả. Có lẽ chưa từng có thời đại nào như bây giờ, khi chúng ta triển khai nhanh và nhận phản hồi nhanh đến vậy.
Vì không phải là không có lúc cần đọc code, nên ở góc độ này câu nói "code hơn tài liệu" có vẻ vẫn đúng; còn vì tài liệu với vai trò là chỉ thị thì phải được LLM, chủ thể triển khai, đọc hiểu, nên ở góc độ đó tôi cũng đồng ý. Vì vậy, kết luận có lẽ là cả hai đều quan trọng cùng lúc phải không.
Vấn đề của các sản phẩm do LLM tạo ra hiện nay là khoản nợ tích lũy ở giai đoạn vận hành. Để vận hành liên tục thì lập trình viên vẫn phải can dự vào code, và để làm được điều đó, tôi nghĩ rằng cho đến hiện tại code vẫn phải có khả năng thay thế cho tài liệu.
Dạo gần đây tôi thấy những trường hợp như thế này thường xuyên hơn.
Dù chưa hiểu chính xác, nhưng đại khái tôi cảm thấy mình cũng nắm được ý.
Cảm ơn bạn.
Tôi không hiểu vì sao mọi người lại xem phương pháp luận như kinh thánh. Tôi nghĩ ngay cả tác giả gốc cũng chỉ khác về định hướng, còn về tính giáo điều thì cũng chẳng khác là bao.
Ngay từ thời điểm chọn SQLite cho máy chủ production, bạn sẽ phải liên tục suy nghĩ xem khi nào nên chuyển sang hệ khác.
Ngày xưa, bản thân chi phí của DB (chi phí mua máy chủ, IDC, chi phí giấy phép, v.v.) khá đắt nên còn đáng để cân nhắc,
nhưng ngày nay, khi thứ gọi là triển khai chỉ bằng một cú nhấp đã khả thi, liệu có thực sự cần phải băn khoăn nữa không?
Bản thân bài viết này đã không hề agile!
Tôi đồng ý.
Chỉ riêng việc phá bỏ cơ chế ra quyết định theo chiều dọc và cải tiến lặp lại theo các chu kỳ ngắn cũng đã để lại cho chúng ta một thông điệp lớn rồi (đương nhiên các kỹ thuật/công cụ quản lý dự án cũng vậy).
Có vẻ kết luận rằng 'bản thân Agile đã không thể mang lại những góc nhìn mới, đồng thời quy chụp toàn bộ những người ủng hộ Agile thành các fan cuồng Agile một cách mù quáng' là hơi cực đoan.
Ước gì codex cũng hỗ trợ token OAuth giống như Claude.
Tôi đã đọc rất kỹ. Cả nội dung anh/chị viết trên blog nữa. Tôi không chắc phép so sánh này có phù hợp không, nhưng tôi nghĩ lý do tutorial đầu tiên của các ngôn ngữ luôn là Hello World!, và việc trước đây khi học phát triển web chúng ta làm ra forum, trang thương mại điện tử trong lúc học, rốt cuộc cũng đi cùng một quỹ đạo với điều anh/chị đã nói. Trước đây tôi từng nghĩ thế này: nếu có kỹ thuật đủ để làm được forum và trang thương mại điện tử, thì có thể hiện thực hóa được phần lớn các website. Và xét đến cùng, rốt cuộc lập trình chỉ đơn giản là có Input và Output mà thôi.
Có vẻ kết luận hơi quá đà. Việc thương mại hóa hay hình thức hóa có thể là vấn đề, nhưng không phải những công cụ như sprint hay backlog đã trở nên vô dụng. Chúng cũng đã giúp hình thành văn hóa họp hành mang tính ngang hàng và tập trung vào mục tiêu. Đúng là SDD đã trở nên quan trọng hơn, nhưng chính đặc tả đó vẫn có thể được viết nhanh theo cách cộng tác với AI, nên về bản chất vẫn là agile. Chỉ là sprint kéo dài 2 tuần đã được rút ngắn xuống còn vài giờ, còn bản chất của việc mài giũa lặp đi lặp lại thì vẫn y nguyên.
Đúng là một bài viết ngớ ngẩn. Cốt lõi là ngay cả
speccũng phải được viết theo cách agile... Agile là phản ứng nhanh trước những thay đổi trong yêu cầu của khách hàng và thích nghi với chúng.Chính vì những người có sự hiểu lầm sai lệch và những tưởng tượng hời hợt về agile như thế này mà cả agile lẫn văn hóa phát triển đều đang đi sai hướng.
Đây là cái quái gì vậy
Cứ tưởng người ta dùng DB là vì hiệu năng à
Có vẻ liên kết đang bị trỏ nhầm sang tên miền
.com.Đây là liên kết thông báo liên quan.
[Thông báo] 04/16 (Thứ Năm) phát sinh sự cố truy cập dịch vụ ▶ Đã xử lý xong
Vẫn có thể sống mà không cần tủ lạnh, nhưng sẽ có những bất tiện.
Nếu đã có thể dùng tủ lạnh thì không có lý do gì để không dùng.
Đúng vậy, không phải Apache 2.0.
Cảm ơn rất nhiều!!
Cái này có vẻ khác giấy phép với gemma4 bản gốc nhỉ
Thật kinh khủng là đây dường như là thứ tôi thấy thường xuyên nhất...
Theo một số tiêu chí thì ai cũng đều agile cả. Có lẽ chưa từng có thời đại nào như bây giờ, khi chúng ta triển khai nhanh và nhận phản hồi nhanh đến vậy.
Vì không phải là không có lúc cần đọc code, nên ở góc độ này câu nói "code hơn tài liệu" có vẻ vẫn đúng; còn vì tài liệu với vai trò là chỉ thị thì phải được LLM, chủ thể triển khai, đọc hiểu, nên ở góc độ đó tôi cũng đồng ý. Vì vậy, kết luận có lẽ là cả hai đều quan trọng cùng lúc phải không.
Vấn đề của các sản phẩm do LLM tạo ra hiện nay là khoản nợ tích lũy ở giai đoạn vận hành. Để vận hành liên tục thì lập trình viên vẫn phải can dự vào code, và để làm được điều đó, tôi nghĩ rằng cho đến hiện tại code vẫn phải có khả năng thay thế cho tài liệu.
Nếu chu kỳ waterfall chỉ diễn ra trong một ngày thì sao?