Tôi đã cảm nhận hiệu năng của opus 4.6 bị giảm đi, chắc là vì sắp ra mắt model mới.
Cú lừa khiến cảm giác tụt hạng một lần rồi lại làm mức độ hài lòng tăng lên đúng là ma thuật..
Là ý 3, 4. Việc viết spec thật chi tiết có độ sâu gần như vô hạn. Điều quan trọng là phải có một mức độ phù hợp với tổ chức. Nếu nhìn lại lịch sử các dịch vụ thành công đã được tạo ra như thế nào, tôi được biết rằng trong 99% trường hợp, một yếu tố chính là không dồn quá nhiều sức vào việc viết spec thật chính xác. Tức là không bị sa lầy vào đó. Chỉ cần nhìn cách những thứ như Summoners War, Dungeon & Fighter, Zigbang hay Lineage được tạo ra là hiểu.
Tôi cũng đồng ý. Đôi khi trong dịch vụ, DB được xem trọng quá mức cần thiết, và cũng có lúc người ta đầu tư quá nhiều vào thiết kế như thể chỉ cần phá vỡ chuẩn hóa là sẽ xảy ra chuyện lớn vậy.
Không phải là đừng dùng DB, mà chỉ cần xem đây như một dịp để làm mới lại suy nghĩ về việc vì sao ta dùng nó, và rốt cuộc nền tảng cốt lõi của dịch vụ là gì, như vậy thôi cũng đã đủ hay rồi.
Cuối cùng thì sự cân bằng lúc nào cũng quan trọng.
Đúng vậy. Có thể xem đây như một đề xuất rằng ở giai đoạn đầu của việc kinh doanh, khi chưa có nhiều người dùng, thay vì mua DB hay làm mọi thứ phức tạp, chỉ với file I/O cơ bản cũng có thể đi đến lúc mô hình kinh doanh ổn định.
Tôi nghĩ đây là một bài viết rất hay. Đặc biệt, những tài liệu có chứa các 'con số' như vậy thì rất quý. Đây là thời đại mà không dễ gì thấy được những lập trình viên có dù chỉ là 'cảm nhận đại khái' về việc code chúng ta tạo ra và tech stack chúng ta mang về dùng có những overhead nào, nên tôi đã đọc rất thích thú.
Tôi thấy phép ví von này khá phù hợp. Dự án của tôi thực tế cũng gần như chỉ được cấu thành từ 2 phần: Intent của con người và Snapshot.
Rốt cuộc, tôi vẫn nghĩ hướng mà dự án của mình cần đi là làm thế nào để tính toán ý định của con người (ví dụ: gõ phím, nhấp chuột) và khiến nó mang một ý nghĩa nào đó.
Ý tưởng thì hấp dẫn đấy, nhưng theo kinh nghiệm của tôi, trong những nỗ lực lý tưởng kiểu này thì hiếm khi có cái nào thực sự thành công..
Hiện tại thì có lẽ Feedly vẫn là lựa chọn an toàn nhất, cả tính năng AI cũng tốt nữa.
Đây là nội dung cơ bản xuất hiện trong hầu hết các sách về các phương pháp Agile như Extreme Programming của Kent Beck, Scrum của Jeff Sutherland, v.v. Bạn cũng có thể xem user story. Có vẻ như phần lớn mọi người không thực sự biết rằng nền tảng của Agile là các sprint ngắn và demo để nhanh chóng thích ứng với yêu cầu của khách hàng.
Tôi đồng cảm với ý kiến mà bạn đã nói.
Rõ ràng có những phần không thể thay thế bằng code.
Theo nghĩa đó, nếu giải thích hơi khác đi một chút, điều tôi muốn nói là code có tính dễ đọc cao sẽ giúp không cần phải tạo ra tài liệu.
Vì tài liệu tích tụ khi phần mềm kéo dài theo thời gian cũng tạo ra gánh nặng nhận thức cho lập trình viên.
Điểm cốt lõi là giảm bớt việc phải qua lại giữa code và tài liệu.
Tôi nghĩ không thể chỉ để lại mỗi code.
Tôi cũng cho rằng điều đó có thể khác tùy theo bối cảnh và tình huống đang đối mặt.
Cảm ơn bạn đã để lại bình luận.
Nếu cẩn trọng nêu ý kiến phản biện thì, tôi cho rằng code không thể thay thế tài liệu. Programming language vẫn chưa có được độ phong phú trong biểu đạt và khả năng truyền tải như ngôn ngữ tự nhiên, và thực tế thì ai có thể đọc hết từng ấy code chứ?
Mong muốn có được thứ code có thể thay thế tài liệu chỉ là một niềm hy vọng và ước ao, nhưng đó là một Tháp Babel không thể với tới.
Thà chăm chỉ làm OOAD còn có vẻ tốt hơn.
"Viết spec theo kiểu agile" bản thân nó nghĩa là gì vậy?
Viết spec qua loa.
Viết spec đúng theo những gì khách hàng đọc cho nghe.
Khi yêu cầu của khách hàng thay đổi thì nhờ sức mạnh của công cụ để bảo trì, sao cho có thể nhanh chóng thay đổi spec.
Viết spec theo kiểu agile.
Cốt lõi của bài viết đó ngay từ đầu là tác giả cũng không biết agile là gì. Người ta chỉ toàn nói agile có những đặc tính này, phải làm thế kia thế nọ, nhưng đến giờ tôi vẫn chưa thấy bài nào chỉ ra rằng đây là một sản phẩm được tạo ra bằng phương pháp agile. Ngay cả khi đọc Tuyên ngôn Agile tôi cũng vẫn thấy mơ hồ. Hay là thử cho xem một ví dụ đi?
Tôi đã cảm nhận hiệu năng của opus 4.6 bị giảm đi, chắc là vì sắp ra mắt model mới. Cú lừa khiến cảm giác tụt hạng một lần rồi lại làm mức độ hài lòng tăng lên đúng là ma thuật..
Là ý 3, 4. Việc viết spec thật chi tiết có độ sâu gần như vô hạn. Điều quan trọng là phải có một mức độ phù hợp với tổ chức. Nếu nhìn lại lịch sử các dịch vụ thành công đã được tạo ra như thế nào, tôi được biết rằng trong 99% trường hợp, một yếu tố chính là không dồn quá nhiều sức vào việc viết spec thật chính xác. Tức là không bị sa lầy vào đó. Chỉ cần nhìn cách những thứ như Summoners War, Dungeon & Fighter, Zigbang hay Lineage được tạo ra là hiểu.
Tôi đồng cảm. Agile vẫn còn nguyên giá trị. Có vẻ như đây là những lời nói vu vơ của những người chưa từng làm việc thực tế.
Nếu Sqlite hỏng thì coi như hết cách..
Tôi cũng đồng ý. Đôi khi trong dịch vụ, DB được xem trọng quá mức cần thiết, và cũng có lúc người ta đầu tư quá nhiều vào thiết kế như thể chỉ cần phá vỡ chuẩn hóa là sẽ xảy ra chuyện lớn vậy.
Không phải là đừng dùng DB, mà chỉ cần xem đây như một dịp để làm mới lại suy nghĩ về việc vì sao ta dùng nó, và rốt cuộc nền tảng cốt lõi của dịch vụ là gì, như vậy thôi cũng đã đủ hay rồi.
Cuối cùng thì sự cân bằng lúc nào cũng quan trọng.
Ở trong nước, Agile chẳng hơn cũng chẳng kém gì một công cụ để gây áp lực tiến độ lên các lập trình viên.
Ồ.. hay đấy. Từ trước đến giờ chưa có nên mình toàn phải tạo bằng ứng dụng Phím tắt rồi dùng thôi
Đúng vậy. Có thể xem đây như một đề xuất rằng ở giai đoạn đầu của việc kinh doanh, khi chưa có nhiều người dùng, thay vì mua DB hay làm mọi thứ phức tạp, chỉ với file I/O cơ bản cũng có thể đi đến lúc mô hình kinh doanh ổn định.
Những viên ngọc trong phần trả lời cũng chỉ là phần thêm thôi.
Tôi nghĩ đây là một bài viết rất hay. Đặc biệt, những tài liệu có chứa các 'con số' như vậy thì rất quý. Đây là thời đại mà không dễ gì thấy được những lập trình viên có dù chỉ là 'cảm nhận đại khái' về việc code chúng ta tạo ra và tech stack chúng ta mang về dùng có những overhead nào, nên tôi đã đọc rất thích thú.
Tôi thấy phép ví von này khá phù hợp. Dự án của tôi thực tế cũng gần như chỉ được cấu thành từ 2 phần: Intent của con người và Snapshot.
Rốt cuộc, tôi vẫn nghĩ hướng mà dự án của mình cần đi là làm thế nào để tính toán ý định của con người (ví dụ: gõ phím, nhấp chuột) và khiến nó mang một ý nghĩa nào đó.
Tôi định vào viết bài ngay khi thấy ra mắt, nhưng anh/chị đã đăng rồi nhỉ.
Tôi tò mò không biết hiệu năng sẽ đến mức nào.
Ý tưởng thì hấp dẫn đấy, nhưng theo kinh nghiệm của tôi, trong những nỗ lực lý tưởng kiểu này thì hiếm khi có cái nào thực sự thành công..
Hiện tại thì có lẽ Feedly vẫn là lựa chọn an toàn nhất, cả tính năng AI cũng tốt nữa.
Đây là nội dung cơ bản xuất hiện trong hầu hết các sách về các phương pháp Agile như Extreme Programming của Kent Beck, Scrum của Jeff Sutherland, v.v. Bạn cũng có thể xem user story. Có vẻ như phần lớn mọi người không thực sự biết rằng nền tảng của Agile là các sprint ngắn và demo để nhanh chóng thích ứng với yêu cầu của khách hàng.
Tôi đồng cảm với ý kiến mà bạn đã nói. Rõ ràng có những phần không thể thay thế bằng code. Theo nghĩa đó, nếu giải thích hơi khác đi một chút, điều tôi muốn nói là code có tính dễ đọc cao sẽ giúp không cần phải tạo ra tài liệu. Vì tài liệu tích tụ khi phần mềm kéo dài theo thời gian cũng tạo ra gánh nặng nhận thức cho lập trình viên. Điểm cốt lõi là giảm bớt việc phải qua lại giữa code và tài liệu. Tôi nghĩ không thể chỉ để lại mỗi code. Tôi cũng cho rằng điều đó có thể khác tùy theo bối cảnh và tình huống đang đối mặt. Cảm ơn bạn đã để lại bình luận.
Chỉ nên đọc nó như một sự thay đổi trong cách nghĩ thôi, vậy mà mọi người nhạy cảm quá.
Tôi cũng պետք է thử một lần mới được.
Cảm ơn vì thông tin hữu ích.
Nếu cẩn trọng nêu ý kiến phản biện thì, tôi cho rằng code không thể thay thế tài liệu. Programming language vẫn chưa có được độ phong phú trong biểu đạt và khả năng truyền tải như ngôn ngữ tự nhiên, và thực tế thì ai có thể đọc hết từng ấy code chứ?
Mong muốn có được thứ code có thể thay thế tài liệu chỉ là một niềm hy vọng và ước ao, nhưng đó là một Tháp Babel không thể với tới.
Thà chăm chỉ làm OOAD còn có vẻ tốt hơn.
"Viết spec theo kiểu agile" bản thân nó nghĩa là gì vậy?
Cốt lõi của bài viết đó ngay từ đầu là tác giả cũng không biết agile là gì. Người ta chỉ toàn nói agile có những đặc tính này, phải làm thế kia thế nọ, nhưng đến giờ tôi vẫn chưa thấy bài nào chỉ ra rằng đây là một sản phẩm được tạo ra bằng phương pháp agile. Ngay cả khi đọc Tuyên ngôn Agile tôi cũng vẫn thấy mơ hồ. Hay là thử cho xem một ví dụ đi?
gemini cli chỉ cần hoạt động cho tử tế là được, vậy mà lúc nào cũng treo