0:00 Xin chào mọi người. Hội nghị đến giờ có ổn chứ? Vâng, các bạn còn đang thấy hội nghị ổn cho đến giờ chứ? Tuyệt lắm. Tôi có một thông điệp mong là sẽ một thông điệp an ủi cho những người tin rằng kỹ năng của họ giờ chẳng còn giá trị trong thời đại mới này. Mà tôi tin là nền tảng phần mềm giờ quan trọng hơn bao giờ hết hơn bất cứ thời điểm nào trước đây. Tôi là một giảng viên và gần đây đang dạy một khóa học có tên CL Code Foran Engineer. Ngẩu và gây suy nghĩ. Và trong quá trình xây dựng khóa học này, tôi phải thiết kế chương trình về lập trình AI. Điều này khá là ác mộng vì mọi thứ thay đổi liên tục. Đúng, ai là một hệ quy
0:46 chiếu hoàn toàn mới. Chắc chắn ta cần vứt bỏ hết các quy tắc cũ để nhét vào mờ cái mới. Và có một trào lưu nảy sinh xung quanh chuyện này, đó là phòng trào Spect Code. Và phòng trảo Spect Code nói rằng ok, bạn có thể viết một mô tả cách một ứng dụng phải hoạt động rồi bạn dùng AI để biến nó thành code. Nếu ứng dụng gặp vấn đề, bạn quay lại chỉnh Spect không cần nhìn vào code, chỉ sửa spec rồi chạy compiler lại và bạn sẽ có thêm code. Giơ tay nếu bạn đã nghe về chuyện đó. Chữ tay giơ nếu bạn đã thử làm vậy. Ok, tôi cũng đã thử rồi. Bây giờ hạ tay xuống được rồi. Và điều tôi nhận ra là tôi chạy nó và cố không nhìn vào code.
1:33 Nhưng rồi vẫn lén xem và nhận ra tôi có cốt đầu ra. Đầu tiên nhìn rồi mới chạy nó. Mã càng ngày càng tệ hơn. Tôi lại làm lần nữa. Lần nữa thì tệ hơn nữa. Rồi lại chạy tiếp. Tôi cứ liên tục chạy coner. Tiếp tục chạy compiler thôi. Cuối cùng chỉ nhận được ra. Giơ tay nếu chuyện đó từng xảy ra với bạn. Vâng, tôi nghĩ cách này không ổn. Ý tưởng rằng ta có thể bỏ qua code và để code tự lo. Để nó tự quản lý thực ra chỉ là lập trình nhưng đổi tên. Và hồi đó tôi không tin như vậy. Tôi nghĩ ok. Làm sao tôi chở được công ty L? Làm sao để nó không cứ tạo ra mã xấu mỗi lần hoặc thậm chí tệ hơn. Nên tôi nghĩ được thôi. Tôi cần giải thích với LLM bằng tiếng Anh. Một cơ sở mã tốt trông như thế nào? Để tôi lôi ra một cuốn sách cũ yêu thích là
2:20 Philosophy of Software Design của John Utho lên Amazon mà mua đi. Và ông ấy có định nghĩa về mã tệ trông ra sao. Ông gọi đó là complex code. Complexity là mọi thứ liên quan đến cấu trúc của hệ thống phần mềm làm cho hệ thống khó hiểu và khó chỉnh sửa. Đúng không? Vì vậy, một code base tệ là code base khó thay đổi. Nếu bạn không thể thay đổi code base mà không gây bu thì đó là code bay tệ, cod tốt thì dễ thay đổi. Tôi nghĩ c ý hay thử cuốn khác xem. Thử cho Pragmatic Programmer lên Amazon mà mua. Họ có cả một chương về thứ gọi là software và đây chính xác là điều tôi đang thấy. Entropy là ý tưởng rằng mọi thứ có xu hướng ngầm hướng đến thảm họa tách rời
3:06 nhau và sụp đổ. Và đây cũng chính xác là cách hầu hết hệ thống phần mềm mỗi lần bạn thay đổi một code base. Nếu bạn chỉ nghĩ về cái thay đổi đó, không nghĩ đến thiết kế toàn bộ hệ thống, codeb của bạn sẽ ngày càng tệ đi. Và đó là những gì tôi đã chứng kiến. Mọi thứ trong ý tưởng từ SP thành code rằng bạn cứ chạy compiler đi chạy lại đang tạo ra mã tệ hơn. Bây giờ có một ý tưởng thúc đẩy phong trào Spect to COD đó là code thì rẻ. Giơ tay nếu bạn từng nghe câu code thì rẻ. Nhưng tôi không nghĩ điều đó đúng. Thực ra tôi nghĩ code không hề rẻ. Mã tệ hiện nay đất đỏ hơn bao giờ hết. Bởi vì nếu bạn có một code bay khó thay đổi, bạn sẽ không thể tận dụng hết lợi
3:53 ích mà AI mang lại vì AI trong một code BOS thực sự hoạt động rất hiệu quả. Và điều này nghĩa là code bas càng trở nên quan trọng hơn bao giờ. Tức là các nền tảng phần mềm càng có ý nghĩa hơn bao giờ hết. Đó là luận điểm của buổi nói chuyện này. Vậy hãy đi vào phần thực tế. Tôi muốn nói về các chế độ lỗi khác nhau mà bạn có thể đã gặp hoặc có thể chưa gặp với AI và cách tránh chúng bằng cách quay lại đọc các cuốn sách cũ và áp dụng các thực hành phần mềm nghe có vẻ hợp lý. Điều đầu tiên là ai không làm theo ý tôi. Bạn biết đấy tôi nghĩ mình có một ý tưởng hay trong đầu nhưng ai lại là một thứ hoàn toàn khác hoặc nó làm kiểu ầm như các fake mà tôi bạn biết đấy. Nó tạo ra thứ tôi không muốn. Giơ tay nếu bạn từng rơi vào trạng thái này. Tuyệt ổn.
4:40 Điều này họ nói trong cuốn Pragnetic là không ai biết chính xác mình muốn gì. Chằng giữa bạn và AI có một giào cản giao tiếp đúng không? Và khi bạn nói chuyện với AI thì giống như AI đang thu thập yêu cầu, nó cơ bản là đang xác định từ bạn xem bạn cần gì. Và tôi nhận ra còn một cuốn sách khác Federic BR tác giả The Th design of Design và ông ấy nói với ý tưởng gọi là Design Concept. Đặc chi bạn có nhiều hơn một người cùng thiết kế cái gì đó sẽ có một ý tưởng lơ lửng giữa các bạn. một ý niệm phù du về thứ bạn đang xây dựng và thứ bạn đang xây dựng ấy hoặc ý tưởng về nó gọi là design concept. Nó không phải là một không thể bỏ vào file MDO được. Nó là lý thuyết vô hình về cái
5:25 bạn đang xây. Vậy nên tôi nghĩ ổn. Đó là chuyện xảy ra. Tôi và AI không chia sẻ design concept. Vì vậy tôi nghĩ ra một kill. Kill này cực kỳ đơn giản. Nó gọi là grume và trông thế này. Phỏng vấn tôi không ngừng về mọi chía cạnh của kế hoạch này. Cho đến khi chúng tôi đạt được sự hiểu biết chủng đi lần lượt xuống mỗi nhánh của cây thiết kế. Điều này cũng là một ý của Fredrick Group giải quyết phụ thuộc giữa các quyết định từng cái một. Q này kiểu như Ro chứa Q này được tầm 13.000 tạ hay gì đó. Kiểu nó bùng phát vai dầu luôn. Mọi người rất thích cái này. Vai dòng này nghĩa là AI sẽ hỏi bạn chừng 40 câu. 80 câu. Tôi đã để nó hỏi người ta 100
6:11 câu trước khi thấy hài lòng. Họ đã đạt được sự hiểu biết chung và điều đó biến AI thành một dạng đối thủ. Nơi nó liên tục vình bạn các ý tưởng và cố gắng đạt được sự hiểu biết chung. Và điều đó có nghĩa cuộc hội thoại bạn tạo ra sau đó. Bạn có thể lấy cái đó và chuyển thành tài liệu yêu cầu sản phẩm hoặc gì đó hoặc nếu là thay đổi nhỏ thì bạn chỉ cần âm làm ừm chuyển thẳng thành ISU và rồi Agent C của bạn sẽ nhặt nó lên đừng ném thính vào mình về chuyện này nhưng cá nhân mình tính cách này tốt hơn chế độ plan mặc định trong công cụ mình dùng là clo code. Chế độ plan rất háo hức tạo ra một nó chỉ muốn tạo plan rồi bắt đầu làm ngay.
6:57 Trong khi mình nghĩ tốt hơn là nên đạt được khái niệm thiết kế chung trước. Vậy đó là nghẹo số một. Bây giờ lỗi thứ hai là AI nói dài dòng quá mức. Giống như bạn và AI đang nói lệch mục đích với nhau. Giơ tay lên nếu bạn ửng. Cảm thấy như vậy khi từng gặp lỗi kiểu đó đúng kiểu như AI đang nói. Dùng quá nhiều từ để cố truyền đạt nó đang làm gì. không phải là bạn đang nói ẩm dung cùng một ngôn ngữ và điều này với mình rất rất quen thuộc đúng không? Nếu bạn đã làm đi lớp lâu và từng làm việc với, ví dụ các chuyên gia lĩnh vươi đang xây ứng dụng, giả sử chuyên gia muốn bạn xây cái gì đó trên, mình không biết vi mạch, bạn hoàn toàn không biết vi mạch là gì, bạn cần
7:42 thiết lập một ngôn ngữ chung nào đó đúng không? Vì nếu không họ sẽ dùng thuật ngữ bạn không hiểu, bạn sẽ phải dịch điều đó thành mã mà có thể bạn còn chưa hiểu và chắc chuyên gia lĩnh vực cũng không. Vì vậy có một khoảng cách ngôn ngữ giữa bạn và chuyên gia lĩnh vực. Và mình quay lại với domain Driven Design. Đây là thứ mình vẫn đang trong giai đoạn khám phá nhưng mọi thứ mình đọc về Tết đều như âm nhạc với mình. Mình thật sự thích nó và đề có khái niệm ngôn ngữ phổ quát. về ngôn ngữ phổ quan, các cuộc trao đổi giữa đề và biểu đạt trong code và các cuộc trao đổi với chuyên gia lĩnh bắt nguồn từ cùng một domain màu đen vì cơ bản nó là một file chứa danh sách thuật ngữ mà bạn và AI cùng dùng và bạn cần
8:30 tập trung vào những thuật ngữ đó và đảm bảo chúng thực sự thống nhất với ý nghĩa thật sự của chúng và bạn dùng chúng thường xuyên trong code. Khi bạn nói về mã nguồn, khi bạn đang trò chuyện với các chuyên gia miền hoặc trong trường hợp của chúng tôi, khi bạn đang nói chuyện với AI. Vì vậy tôi đã tạo một skill. Skill này là Ubikitos language, ngôn ngữ trùng. Về cơ bản chỉ quét toàn bộ code bay của bạn, tìm kiếm các thuật ngữ rồi sau đó tạo một file ma. Cụ thể là file UB language Mackdown. Một loạt bảng maow chứa tất cả thuật ngữ. Sau đó tôi đưa nó cho AI và đồng thời tôi cũng có thể đọc được. Và thực tế tôi luôn mở nó khi tôi đang trao đổi sâu với AI và lên kế hoạch. Điều tôi nhận ra khi đọc các dấu vết suy nghĩ của AI không chỉ cải thiện việc lập kế hoạch mà còn giúp AI suy nghĩ xúc tích hơn
9:17 và thực tế khiến phần triển khai khớp hơn với những gì bạn thực sự đã lên kế hoạch nên đây thực sự đã trở thành một công cụ mạnh mẽ nó hiệu quả đến mức khó tin. Vậy mẹo số hai là tạo một ngôn ngữ chung với AI. Thấy ổn hãy tưởng tượng bạn đã đồng bộ với AI. Bạn biết chính xác thứ mình phải xây dựng. Đã tạo ra đúng cái bạn cần nhưng nó không hoạt động. Giơ tay nếu điều đó đã từng xảy ra với bạn. Đúng vậy, đơn giản là không chạy. Chà có một điều rõ ràng chúng ta có thể làm để cải thiện tình hình đó là sử dụng các feedback loop. Chúng ta có thể dùng kiểu tĩnh sa tích tài đó nếu bạn chưa dùng t cre thì hơi điệt. Ồ nếu bạn không dùng, nếu bạn đám xây up frontend và bạn cung cấp cho lờm quyền truy cập vào trình duyệt để nó có thể nhìn xung quanh thì nhất định phải có.
10:04 Và rõ ràng bạn cũng cần automat. Và có một điều mà tôi nhận thấy ở đây là ngay cả với các feedback loop ấy thì LM vẫn không tận dụng chúng tốt lắm. Nó không tận dụng tối đà các feedback loop theo cách mà một kỳ cựu sẽ làm. Và vì vậy nó thường làm quá nhiều thứ cùng lúc. nó sẽ sinh ra lượng cốt lớn rồi sau đó nghĩ rằng mình n có lẽ nên tao check cái đó thực ra hoặc mình nét ở đúng có thể chạy test cho phần đó hoặc làm gì đại loại vậy và điều này trong cuốn Pragmetic program họ mô tả lá out tuning do hết ly vì cơ bản là lái quá nhanh bởi vì tốc độ nhận phản hồi chính là giới hạn tốc độ của bạn tốc độ phản hồi là giới hạn tốc độ của bạn điều đó có nghĩa là bạn nên kiểm thử
10:51 ngay trong lúc phát triển thực hiện từng bước nhỏ có chú ý và AI theo mặc định thực sự không giỏi việc đó. Vì vậy kỹ năng số ba là TD. Bạn nên áp dụng phát triển theo kiểm thử TD bởi vì TD buộc LLM phải tiến từng bước nhỏ thực sự. Bạn tạo bài kiểm thử trước rồi làm cho bài kiểm thử đó vượt qua. Sau đó bạn vi factor mã để nó sạch hơn, dễ đọc hơn và cân nhắc đến thiết kế. Nhưng vấn đề ở đây là kiểm thử vốn rất khó. Kiểm thử luôn luôn khó khăn. Và lý do cho điều đó là có rất nhiều quyết định khác nhau bạn phải đưa ra. Khi bạn viết một bài kiểm thử, bạn phải xác định mình muốn kiểm thử đơn vị lớn hay nhỏ. Bạn phải quyết
11:36 định cần mô cà những gì, bạn phải xác định những hành vi nào mà bạn thậm chí có muốn kiểm thử ngay từ đầu. Và tất cả các quyết định này đều phụ thuộc. Vì vậy, nếu bạn kiểm thử một đơn vị rất lớn như cả một ứng dụng khổng lồ thì nó có thể khá lắt nhắt và không ổn định. Bạn có thể không muốn kiểm thử quá nhiều hành vi. Nếu bạn chỉ kiểm thử đơn vị này thì bạn cần mơ cà các đơn vị bạn thấy đó. Mọi thứ đều liên kết với nhau. Và tôi đã suy nghĩ về chuyện này nhiều năm rồi trong suốt sự nghiệp phát triển phần mềm của mình. Và chúng tôi nhận thấy rằng C B tốt thì dễ kiểm thử phải không? Vậy là ở đây chúng ta bắt đầu quay lại ý tưởng rằng mã nguồn quan trọng càng tốt cod B của bạn. Hi vọng phản hồi càng hiệu quả vì bạn có thể như phản hồi tốt hơn cho lên nó tạo ra mã tốt hơn. Và nên tôi tự hỏi một cod
12:22 bas tốt trông như thế nào? Một cod bay dễ kiểm thử sẽ như thế nào? Một lần nữa ta quay sang John Utter House ông ấy nói về việc có các môun sầu trong code bệnh. Không phải các môun nông không phải nhiều modunle phơi bày hàng loạt hàm linh tinh. không nhiều hàm nên có tương đối ít mà là module lớn sầu với giao diện đơn giản. Ta so sánh nhanh thôi. Modun sâu nhiều chức năng ẩn đằng sau một giao diện đơn giản trên dấu độ phức tạp. Bạn có thể xem bên trong module sâu nếu muốn nhưng bạn không cần chỉ cần dùng giao diện là được. Modun nồng ít chức năng giao diện phức tạp và tôi chỉ chờ bạn chụp ảnh. Các module nông trong code bay thường trông như thế này. Nơi bạn có vô số
13:07 thành phần khác nhau. Những màu nhỏ mà AI phải do tìm và điều hướng qua. Và thực sự rất khó để AI khám phá hiệu quả. Vì vậy thường bạn sẽ thấy nếu bạn có một cod bas như thế này mà AI lại rất giỏi tạo ra những cod bas như vậy thì sẽ xảy ra tình huống nôi AI. Không hiểu code của bạn đang làm gì. Nó sẽ cố gắng thăm dò code nhưng vì bố cục tệ đầy module nóng. nên có thể không truy cập đúng module kịp thời hoặc không hiểu hết các depending. Tất cả những thứ đó khiến nó không hiểu được code của bạn. Vậy một code b đầy module sâu trông như thế nào? Nó trông như này cùng logic nhưng được tổ chức bên trong các ranh giới rõ ràng nơi bạn có các interface ở phía trên.
13:54 Vào những interface này, bạn nên nắm quyền kiểm soát cao đối với chúng và thiết kế chúng thật tốt nếu không. AI có thể làm hỏng thiết kế nhưng phần triển khai thì bạn có thể phần nào giao cho AI đảm nghiệm. Vậy làm sao biến một code bay trông thế này thành một code bay trông như kia? Mình có một kill cho việc đó. Inoc based Architecture. Hóa ra việc này không đơn giản nó khá phức tạp để thực hiện nhưng đó là một. Tập hợp các bước bạn có thể tái sử dụng nhiều lần. Bạn chỉ việc lần khảo sát code b tìm cơ hội nơi code có vẻ liên quan với nhau liên kết và đóng gói tất cả vào một de module. Và đây là một code bay có thể test được vì các danh giới quành. Đoạn code này
14:39 rất rất đơn giản. Bạn test tải interface bạn xác thực bằng interface đó và xong. Vậy là đây là code b phù hợp với TD. Nhưng còn file la mode số 6 thì sao? Đó là khi bạn kiểu như ổn. Giả sử vong phần hôi của bạn đang hoạt động. Giả sử mọi thứ bắt đầu vào bạn có thể giao nhiều cốt hơn bao giờ hết nhưng đầu óc bạn không theo kịp. Đúng không? Ẩn giơ tay nếu bạn từng cảm thấy mệt hơn bao giờ hết trong suốt sự nghiệp phát triển phần mềm của mình. Ơ mình cũng vậy. Ngịch rõ rồi. Và tôi nghĩ đây là một cơ sở mã thực tế làm cho bộ não bạn khó xử lý hơn vì bạn và cả AI đều phải giữ toàn bộ thông tin đó trong đầu. Trong khi cách này không chỉ đơn giản hơn cho bạn đọc và hiểu
15:25 mà còn cho phép bạn xem những module này nhứ. Những hộp xám Grey Box đối với các module phức tạp. Bạn có thể kiểu nói rằng được rồi, tôi sẽ chỉnh thiết kế giao diện nhưng tôi sẽ không phải lo lắng quá nhiều hoặc không phải kiểm duyệt chi tiết phần triển khai. Rõ ràng bạn có thể làm điều này thới ích quan trọng trong ứng dụng của bạn. Không thể làm thế với ông những chức năng liên quan tài chính hay tương tự. Nhưng ở nhiều module trong app của bạn, bạn không cần suy nghĩ quá sầu về phần triển khai, miễn là bạn có một biên kiểm thử được ở bên ngoài module và miễn là bạn hiểu mục đích của nó và có thể thiết kế từ bên ngoài. Tôi thấy điều này thực sự cứu bộ não tôi vì tôi chỉ cần nói được rồi AI, tôi giao cho bạn xử lý những gì bên trong khối lớn đó. Tôi chỉ sẽ kiểm thử từ bên ngoài và xác minh nó. Vậy đó
16:11 là mẹo phù nằm thiết kế giao diện ủy quyên phần triển khai. Nhưng điều này có nghĩa mỗi khi chúng ta thao tác mã, mỗi khi chúng ta lên kế hoạch, chúng ta cần nghĩ tới và nhận thức rõ các module trong ứng dụng. Chúng ta cần nắm thật rõ bản đồ đó. Nó phải là một phần của ngôn ngữ phổ dụng của đội. Chúng ta cũng cần tích hợp nó vào kỹ năng lập kế hoạch. Vì vậy, tôi viết một play bên trong. Tôi mô tả chi tiết các thay đổi module và các giao diện bên trong những module đó. Chúng được sửa đổi như thế nào? Tôi luôn suy nghĩ về chúng mọi lúc và điều này xuất phát từ Kenback. Đầu tư vào thiết kế hệ thống mỗi ngày. Và đây chính là cốt lõi đúng bởi vì độc tờ ảnh hưởng mã. Chúng ta đang không đầu tư vào thiết kế hệ thống chúng ta đang rút lui khỏi nó loại bỏ điều đó. Trong
16:57 khi tôi nghĩ điều này là then chốt và mã không rẻ. Đó là thông điệp tôi muốn bạn mang về. Mã quần trọng. Và nếu ta coi AI như một lập trình viên rở mặt trận rất giỏi. Một kiểu lập trình viên chiến thuật, một trung sĩ ở hiện trường thực hiện thay đổi mã. Bạn cần một người ở cấp trên đó bạn cần ai đó suy nghĩ ở tầm chiến lược và người đó chính là bạn. Và điều đó đòi hỏi sân mềm những kỹ năng cơ bản mà chúng ta đã sử dụng suốt 20 năm thậm chí lâu hơn. Nếu bạn quan tâm tới bất kỳ kỹ năng nào, tôi liệt kê ở đây. Chúng có trong kho Gitup McQueill. Và nếu bạn muốn biết về các khóa đào tạo tôi làm hoặc tài nguyên miễn phí, tôi có trên YouTube và thiết. Nhưng tôi cũng ở
17:43 trang AID. Ở đó tôi có bản tin bạn có thể đăng ký xem. Rất cảm ơn. Mong rằng điều này sẽ tiếp thêm tự tin cho bạn trong thời đại AI mới này. Rằng bạn thực sự có thể tạo ra tác động tích cực. Cảm ơn. H
