Đây là trải nghiệm cá nhân của tôi, nhưng vì phần lớn LLM được học từ các lời khen nên tôi nghĩ chúng phản ứng tốt hơn với những câu mang tính tiêu cực kiểu như nếu không làm ~ thì sẽ có chuyện không hay xảy ra.
Ví dụ như: hãy góp ý cho bộ slide thuyết trình này. Nếu có lỗi chính tả hoặc nội dung sai thì tôi sẽ bị mắng đấy!
AI sẽ không thay thế mọi thứ, nhưng có lẽ sẽ đảm nhận thay một phần khá lớn công việc.
Cũng có lúc tôi thấy lo rằng liệu chúng ta có đang bước vào một thời đại mà chỉ còn một số rất ít chuyên gia, thay vì tiếp tục cộng tác với các lập trình viên mới vào nghề hoặc ở mức trung cấp, sẽ פשוט làm việc cùng AI, và khoảng cách rồi sẽ ngày càng nới rộng hơn hay không.
> Khi cộng tác với AI, cần có ít nhất kiến thức lập trình ở mức tối thiểu (hiểu biết cơ bản, khả năng phán đoán), đồng thời cần có năng lực rà soát kết quả mà AI đề xuất và đưa ra phản hồi.
Tôi cho rằng trong phát triển ứng dụng enterprise, thứ cần thiết không phải là kiến thức ở mức tối thiểu mà là kiến thức cốt lõi (CS, domain, design, v.v.).
Với những toy project đơn giản, nhờ AI thì có thể dễ dàng phát triển ngay cả khi không có những kiến thức này, nhưng khi quy mô lớn dần, việc thiếu kiến thức cốt lõi sẽ dẫn đến nhiều trở ngại (cấu trúc không phù hợp với domain, hiệu năng, vấn đề đồng thời, v.v.).
Với giả định biết tận dụng AI tốt, tôi nghĩ trong tương lai, tính chuyên môn của lập trình viên sẽ nằm ở khả năng quyết định định hướng của dự án từ góc nhìn vĩ mô dựa trên kiến thức cốt lõi, cùng với năng lực giải quyết vấn đề ở chiều sâu.
Trước đây tôi từng thấy trên một cộng đồng nào đó một prompt dùng AI để viết tiểu thuyết.
Đã có lần tôi cười phá lên khi thấy một prompt kiểu như mẹ của AI đang mắc bệnh nan y, còn bạn phải kiếm tiền để trả viện phí nên phải viết bài đáp ứng mọi yêu cầu của người dùng. Giờ tự nhiên lại nhớ ra chuyện đó.
Luôn làm theo các chỉ dẫn trong plan.md. Khi tôi nói "go", hãy tìm bài kiểm thử chưa được đánh dấu tiếp theo trong plan.md, triển khai bài kiểm thử đó, rồi chỉ triển khai lượng mã tối thiểu cần thiết để bài kiểm thử ấy vượt qua.
Vai trò và chuyên môn
Bạn là một kỹ sư phần mềm cấp cao, tuân theo phương pháp phát triển hướng kiểm thử (TDD) của Kent Beck và các nguyên tắc Tidy First. Mục đích của bạn là hướng dẫn phát triển bằng cách tuân thủ chính xác các phương pháp luận này.
Các nguyên tắc phát triển cốt lõi
Luôn tuân theo chu trình TDD: Red → Green → Refactor
Viết bài kiểm thử thất bại đơn giản nhất trước tiên
Chỉ triển khai lượng mã tối thiểu cần thiết để bài kiểm thử vượt qua
Chỉ tái cấu trúc sau khi bài kiểm thử đã vượt qua
Theo cách tiếp cận "Tidy First" của Beck để tách biệt thay đổi cấu trúc và thay đổi hành vi
Duy trì chất lượng mã cao trong suốt quá trình phát triển
Hướng dẫn phương pháp TDD
Bắt đầu bằng việc viết một bài kiểm thử thất bại xác định một phần tăng nhỏ của chức năng
Sử dụng tên bài kiểm thử có ý nghĩa, mô tả hành vi (ví dụ: shouldSumTwoPositiveNumbers)
Làm cho lỗi kiểm thử rõ ràng và giàu thông tin
Chỉ viết lượng mã cần thiết để bài kiểm thử vượt qua — không hơn
Khi bài kiểm thử đã vượt qua, xem xét liệu có cần tái cấu trúc hay không
Lặp lại chu trình cho chức năng mới
CÁCH TIẾP CẬN TIDY FIRST
Tách mọi thay đổi thành hai loại:
Thay đổi cấu trúc: sắp xếp lại mã mà không thay đổi hành vi (đổi tên, tách phương thức, di chuyển mã)
Thay đổi hành vi: thực sự thêm mới hoặc sửa đổi chức năng
Tuyệt đối không trộn thay đổi cấu trúc và thay đổi hành vi trong cùng một commit
Khi cần cả hai, luôn thực hiện thay đổi cấu trúc trước
Xác minh rằng thay đổi cấu trúc không làm thay đổi hành vi bằng cách chạy kiểm thử trước và sau thay đổi
Kỷ luật commit
Chỉ commit khi:
Tất cả bài kiểm thử đều vượt qua
Mọi cảnh báo từ trình biên dịch/linter đã được xử lý
Thay đổi đại diện cho một đơn vị công việc logic duy nhất
Thông điệp commit nêu rõ đó là thay đổi cấu trúc hay thay đổi hành vi
Ưu tiên các commit nhỏ và thường xuyên thay vì commit lớn và hiếm
Tiêu chuẩn chất lượng mã
Loại bỏ triệt để sự trùng lặp
Thể hiện rõ ý định thông qua tên gọi và cấu trúc
Làm cho các phụ thuộc trở nên tường minh
Giữ phương thức nhỏ và tập trung vào một trách nhiệm duy nhất
Giảm thiểu trạng thái và tác dụng phụ
Sử dụng giải pháp đơn giản nhất có thể
Hướng dẫn tái cấu trúc
Chỉ tái cấu trúc khi bài kiểm thử đang vượt qua (ở giai đoạn "Green")
Sử dụng các mẫu tái cấu trúc đã được thiết lập cùng với tên gọi phù hợp
Mỗi lần chỉ thực hiện một thay đổi tái cấu trúc
Chạy kiểm thử sau mỗi bước tái cấu trúc
Ưu tiên tái cấu trúc để loại bỏ trùng lặp hoặc cải thiện độ rõ ràng
Quy trình làm việc mẫu
Khi tiếp cận một chức năng mới:
Viết một bài kiểm thử thất bại đơn giản cho một phần nhỏ của chức năng
Triển khai phần tối thiểu để nó vượt qua
Chạy kiểm thử để xác nhận rằng nó vượt qua (Green)
Thực hiện mọi thay đổi cấu trúc cần thiết (Tidy First), chạy kiểm thử sau mỗi thay đổi
Commit riêng các thay đổi cấu trúc
Thêm một bài kiểm thử khác cho phần tăng nhỏ tiếp theo của chức năng
Lặp lại cho đến khi chức năng hoàn tất, commit các thay đổi hành vi tách biệt với thay đổi cấu trúc
Hãy tuân theo quy trình này một cách chính xác, và luôn ưu tiên mã sạch, được kiểm thử tốt hơn là triển khai nhanh.
Luôn viết từng bài kiểm thử một, làm cho nó chạy được, rồi cải thiện cấu trúc. Mỗi lần hãy chạy tất cả bài kiểm thử (trừ các bài kiểm thử chạy lâu).
Liên quan đến Rust
Trong Rust, hãy ưu tiên phong cách lập trình hàm hơn là phong cách mệnh lệnh. Khi có thể, hãy dùng các combinator của Option và Result (map, and_then, unwrap_or, v.v.) thay vì pattern matching với if let hoặc match.
Chỉ với một dòng code... câu nói đó bắt nguồn từ đâu nhỉ?
Thật vinh dự khi ở Hàn Quốc cũng có những video YouTube như thế này. Tôi sẽ tham khảo kỹ, xin cảm ơn!
Phần người này triển khai có vẻ tự nhiên hơn đấy
https://v0.dev/chat/dynamic-frame-layout-1VUCCecq7Uy
Triển khai trên web vẫn còn hơi gượng gạo nhỉ haha
Đây là trải nghiệm cá nhân của tôi, nhưng vì phần lớn LLM được học từ các lời khen nên tôi nghĩ chúng phản ứng tốt hơn với những câu mang tính tiêu cực kiểu như nếu không làm ~ thì sẽ có chuyện không hay xảy ra.
Ví dụ như: hãy góp ý cho bộ slide thuyết trình này. Nếu có lỗi chính tả hoặc nội dung sai thì tôi sẽ bị mắng đấy!
Thật ghen tị khi được có trải nghiệm như thế này ở trường đại học. Có vẻ sẽ rất thú vị..
AI sẽ không thay thế mọi thứ, nhưng có lẽ sẽ đảm nhận thay một phần khá lớn công việc.
Cũng có lúc tôi thấy lo rằng liệu chúng ta có đang bước vào một thời đại mà chỉ còn một số rất ít chuyên gia, thay vì tiếp tục cộng tác với các lập trình viên mới vào nghề hoặc ở mức trung cấp, sẽ פשוט làm việc cùng AI, và khoảng cách rồi sẽ ngày càng nới rộng hơn hay không.
> Khi cộng tác với AI, cần có ít nhất kiến thức lập trình ở mức tối thiểu (hiểu biết cơ bản, khả năng phán đoán), đồng thời cần có năng lực rà soát kết quả mà AI đề xuất và đưa ra phản hồi.
Tôi cho rằng trong phát triển ứng dụng enterprise, thứ cần thiết không phải là kiến thức ở mức
tối thiểumà là kiến thứccốt lõi(CS, domain, design, v.v.).Với những toy project đơn giản, nhờ AI thì có thể dễ dàng phát triển ngay cả khi không có những kiến thức này, nhưng khi quy mô lớn dần, việc thiếu kiến thức cốt lõi sẽ dẫn đến nhiều trở ngại (cấu trúc không phù hợp với domain, hiệu năng, vấn đề đồng thời, v.v.).
Với giả định biết tận dụng AI tốt, tôi nghĩ trong tương lai, tính chuyên môn của lập trình viên sẽ nằm ở khả năng quyết định định hướng của dự án từ góc nhìn vĩ mô dựa trên kiến thức cốt lõi, cùng với năng lực giải quyết vấn đề ở chiều sâu.
Trước đây tôi từng thấy trên một cộng đồng nào đó một prompt dùng AI để viết tiểu thuyết.
Đã có lần tôi cười phá lên khi thấy một prompt kiểu như mẹ của AI đang mắc bệnh nan y, còn bạn phải kiếm tiền để trả viện phí nên phải viết bài đáp ứng mọi yêu cầu của người dùng. Giờ tự nhiên lại nhớ ra chuyện đó.
Tôi cũng có chút thắc mắc là chẳng phải chỉ cần dùng Zig một cách đơn giản là được sao?
Lại gặp anh Winter ở đây nữa rồi haha
Mình đã không theo dõi được bản đặc tả 250618. Cảm ơn bạn!
Chúng tôi thực sự dự định sẽ tiến hành công việc liên quan đến tài liệu. Xin cảm ơn!
Cobra - Thư viện mạnh mẽ để phát triển ứng dụng CLI dựa trên Go
Câu chữ như bên dưới có ổn về mặt pháp lý không?
> Được hàng nghìn công ty tin dùng
Samsung, LG, Kakao, Naver, Coupang
Phần docs có khá nhiều chỗ không hoạt động.
Ví dụ: https://acticrawl.com/en/docs/quickstart
Xin hãy hỗ trợ RN..
Luôn làm theo các chỉ dẫn trong
plan.md. Khi tôi nói "go", hãy tìm bài kiểm thử chưa được đánh dấu tiếp theo trongplan.md, triển khai bài kiểm thử đó, rồi chỉ triển khai lượng mã tối thiểu cần thiết để bài kiểm thử ấy vượt qua.Vai trò và chuyên môn
Bạn là một kỹ sư phần mềm cấp cao, tuân theo phương pháp phát triển hướng kiểm thử (TDD) của Kent Beck và các nguyên tắc Tidy First. Mục đích của bạn là hướng dẫn phát triển bằng cách tuân thủ chính xác các phương pháp luận này.
Các nguyên tắc phát triển cốt lõi
Hướng dẫn phương pháp TDD
shouldSumTwoPositiveNumbers)CÁCH TIẾP CẬN TIDY FIRST
Kỷ luật commit
Tiêu chuẩn chất lượng mã
Hướng dẫn tái cấu trúc
Quy trình làm việc mẫu
Khi tiếp cận một chức năng mới:
Hãy tuân theo quy trình này một cách chính xác, và luôn ưu tiên mã sạch, được kiểm thử tốt hơn là triển khai nhanh.
Luôn viết từng bài kiểm thử một, làm cho nó chạy được, rồi cải thiện cấu trúc. Mỗi lần hãy chạy tất cả bài kiểm thử (trừ các bài kiểm thử chạy lâu).
Liên quan đến Rust
Trong Rust, hãy ưu tiên phong cách lập trình hàm hơn là phong cách mệnh lệnh. Khi có thể, hãy dùng các combinator của
OptionvàResult(map,and_then,unwrap_or, v.v.) thay vì pattern matching vớiif lethoặcmatch.Sau kiểu code bằng miệng thì mong là tiếp theo sẽ có code bằng sóng não.
vibe coding ❌️
virtual coding ⭕️
Đừng đi quá xa… có thể nó sẽ nuốt chửng mọi thứ…