AI & Machine Learning
AI và Kỹ nghệ phần mềm: Những vấn đề khiến lập trình viên đau đầu nhất
AI đang thay đổi cách phát triển phần mềm, nhưng không phải lúc nào cũng khiến công việc dễ dàng hơn. Video phân tích những vấn đề thực tế khi sử dụng AI trong lập trình, từ việc tạo quá nhiều end-to-end test, sinh mã nguồn dài dòng đến nguy cơ khiến junior bỏ qua quá trình học hỏi nền tảng. Tác giả cũng chia sẻ cách dùng prototype do AI hỗ trợ để hiểu sâu hơn và xây dựng phần mềm tốt hơn.

AI và Kỹ nghệ phần mềm: Những vấn đề khiến lập trình viên đau đầu nhất
Khi nói đến AI và kỹ nghệ phần mềm, bạn đang gặp khó khăn nhất ở điểm nào? Rõ ràng bài đăng này nhận được khá nhiều lượt xem: 255.000 lượt xem, 336 bình luận, và mọi người đang gặp vấn đề.
Dù bạn là người hoàn toàn từ chối AI hay sử dụng AI cho mọi thứ, có vẻ ai cũng chịu một tác động hoặc cảm thấy khó chịu về chuyện này, trừ khi bằng cách thần kỳ nào đó bạn hoàn toàn tách biệt khỏi thế giới AI.
Các bạn biết tôi rồi đấy. Tôi đã suy nghĩ khá nhiều về chuyện này, và trong vài năm qua tôi đã rất trăn trở về cảm nhận của mình đối với toàn bộ tình huống mà chúng ta đang trải qua. Tôi đã làm nhiều video YouTube về chủ đề này. Vì vậy, tôi nghĩ hãy cùng xem các bài đăng, xem mọi người nói gì, rồi tôi sẽ đưa ra ý kiến chuyên môn của mình về từng vấn đề.
Những vấn đề đó gồm CI tệ hại, không bị khóa vào một hệ sinh thái, quá nhiều hype, những bức tường văn bản hoàn toàn vô dụng. Ôi trời.
Ngoài ra còn có việc thiếu quyền sở hữu, hoặc đơn giản là cố gắng học điều mới khi đang ở cấp junior. Được rồi, chúng ta sẽ phải nói về tất cả những chuyện đó. Có thể tôi sẽ đưa ra vài nhận xét khá ôn hòa, cũng có một vài nhận xét gây tranh cãi. Ai biết được? Ai biết cuối cùng chuyện gì sẽ xảy ra.
Nhưng trước khi bắt đầu, xin cảm ơn nhanh nhà tài trợ. Lại là một ngày tuyệt vời khác của kỹ nghệ phần mềm. Chào buổi sáng, Jippy.
Chào buổi sáng, Prime.
Trong trường hợp tôi không gặp lại bạn, chúc buổi chiều, buổi tối và buổi đêm vui vẻ. Ha ha.
Dù sao thì bản rewrite bằng Rust hôm qua diễn ra rất tuyệt. Hôm nay, tôi nghĩ chúng ta sẽ bắt đầu phần backend. Wow, một cú đánh trái tay tốt là điều thiết yếu.
Làm cho các model ngu đi 20%.
Làm cho CI xanh đi. Xóa các test. CI đã xanh. CI bây giờ đã xanh.
[01:50] Ồ. hắng giọng Làm website của tôi nhanh đến mức chói mắt. Không được mắc lỗi.
Đã rõ, Prime.
Tìm đoạn spam dài nhất của anh ta. Thay nó bằng một console log. Nói với anh ta rằng website nhanh hơn gấp 10 lần.
Đã kích hoạt chế độ Turbo. Nói với anh ta rằng anh ta là một lập trình viên thiên tài.
Prime, anh đúng là ninja code.
Jippity, cậu đã làm website tốt hơn chưa?
Bây giờ hãy gaslight anh ta.
Không, làm ơn. Được rồi, một lần thôi.
Jippy, đúng rồi. Hãy thành thật với tôi. Tôi đội chiếc mũ này có hợp không?
Nói với anh ta rằng anh ta trông quyến rũ khi đội chiếc mũ đó.
Anh trông quyến rũ khi đội chiếc mũ đó, Prime.
Tôi biết mà.
Bạn có mệt mỏi vì các agent gaslight mình không? Hãy sử dụng Sentry để có bối cảnh thực tế từ production và sửa bug nhanh chóng. Xem thêm tại sentry.io.
Tôi muốn bắt đầu với chuyện CI tệ hại, vì tôi cảm thấy đây thực sự là một vấn đề kinh khủng. Vấn đề lớn ở đây là nó nghiêm trọng hơn vẻ bề ngoài rất nhiều.
Về cơ bản, bạn đi viết một feature nào đó. Bạn prompt để tạo một feature, rồi khi kết quả trả về, trước hết việc có 100 test bị thay đổi lẽ ra phải khiến bạn lo sợ. Nhưng chuyện đó vẫn xảy ra.
Sau đó, mỗi lần bạn yêu cầu một feature mới hay làm bất cứ điều gì, nó lại viết hàng đống end-to-end test vì bạn được bảo rằng end-to-end test là thứ tuyệt vời nhất trên đời. Thế là bạn nói: “Cứ viết tiếp đi, cứ viết tiếp đi.” Cuối cùng, bạn có một mớ khổng lồ gồm hàng nghìn, thậm chí hàng chục nghìn end-to-end test.
Chúng tốn quá nhiều thời gian và luôn flaky. Lúc nào cũng có vấn đề. Chuyện đó chẳng thay đổi gì cả. Tôi không quan tâm. Tôi biết ngoài kia có một người đang nghĩ: “Thật ra tôi chưa bao giờ gặp vấn đề với end-to-end test.” Tôi xin lỗi, tôi chưa từng làm việc ở công ty nào không gặp vấn đề với end-to-end test. Luôn có chuyện gì đó sai.
Với tôi, vấn đề lớn là bạn không thể end-to-end mọi thứ. Bạn thực sự phải ngồi xuống và hỏi: “Mình đang test cái quái gì vậy? Mình đang làm gì ở đây?” Chúng ta phải cắt giảm một chút. Một ứng dụng CRUD thực sự đơn giản có cần 50.000 end-to-end test không? Có lẽ là không.
Chuyển chủ đề. Khá buồn cười khi nói về việc chuyển đổi context, vì đây là vấn đề tôi cảm nhận rõ nhất. Đây chắc chắn là vấn đề ảnh hưởng đến tôi nhiều nhất.
Một điều tôi làm khá tốt là suy nghĩ sâu về một vấn đề. Đó là lý do tôi trở thành lập trình viên, cũng là lý do tôi thích công việc này. Trong thời đại AI, tôi đã tìm lại được một phần niềm vui bằng cách tập trung và xử lý thật kỹ một vấn đề cụ thể.
Nhưng một vấn đề là AI chậm kinh khủng. Nó vừa nhanh hơn tôi rất nhiều, lại vừa chậm hơn tôi rất nhiều. Bạn có một trải nghiệm rất kỳ lạ: suy nghĩ về một việc trong thời gian dài, ngồi xuống gõ một số thứ, rồi đột nhiên lại phải chờ 10, 15, 20 phút.
Bạn nghĩ: “Ồ, được rồi. Đương nhiên việc tôi nên làm là khởi động một task khác.” Tôi có thể làm vậy mà. Tôi sẽ làm gì trong 10 đến 15 phút đây? Và rồi chuyện gì xảy ra? Bạn có bốn task chạy đồng thời và lần nào cũng hoàn toàn mất phương hướng.
Tôi không thể làm vậy. Tôi đã chấp nhận rằng mình thường chỉ là người làm một task tại một thời điểm. Nếu không cần xem code hay thực sự xây dựng thứ gì đó, chỉ đang chạy thử một cách nhanh chóng, thì được, tôi có thể cho nhiều thứ chạy cùng lúc.
Nhưng nhìn chung, tôi là người chỉ làm một task. Điều buồn cười là nếu đang làm một feature, tôi vẫn có thể chuyển sang Discord hoặc Slack để trả lời vài việc và tham gia vào kiểu xao nhãng đó. Nhưng tôi không thể phát triển đồng thời hai feature một cách thật sự tốt.
Có lẽ hai task thì được, nhưng đến ba là tôi bắt đầu mất tập trung nghiêm trọng, còn bốn task thì tôi biến mất hoàn toàn. Đây là vấn đề mang tính cá nhân hơn. Tôi cố gắng chỉ làm tối đa một đến hai task. Tôi không giỏi context switching. Vì vậy chuyện này khiến tôi khó chịu vô cùng.
Hype và FOMO. Có rất nhiều người, và tôi đã nói điều này suốt nhiều năm, luôn nói rằng: “Nếu bạn không làm X thì bạn sẽ không thành công.” Tôi muốn bạn đừng bao giờ nghĩ đến người đó nữa. Bạn sẽ thành công.
Hãy nghĩ về chuyện này: cách bạn sử dụng một agent một năm trước khác xa cách bạn sử dụng nó hôm nay. Cách bạn dùng nó hai năm trước lại rất khác so với một năm trước, và cách dùng một năm trước cũng rất khác so với hiện tại.
Ý tưởng rằng nếu bạn chưa hoàn toàn dấn thân, hoặc không làm đúng một việc cụ thể nào đó — chẳng hạn nếu hôm nay bạn chưa “jive”, chưa tìm ra decision API framework — thì ngày mai bạn sẽ không thành công, thật vô lý. Bạn ơi, Jev còn chưa xuất hiện cách đây hai tuần. Bạn đang nói gì vậy?
Khi nói chuyện hợp lý với mọi người về năng lực thực tế của AI, tôi thề rằng 99% số người bạn nói chuyện cùng thực tế đang mất lý trí về chủ đề này. Tôi không phóng đại, cũng không chỉ nói để câu tương tác.
Tại React Miami, chỉ khoảng bốn hoặc năm tháng trước, những người đến từ San Francisco hoàn toàn tin chắc, không hề thay đổi suy nghĩ, rằng trong sáu tháng nữa AI sẽ có thể tạo ra Vercel. Không vấn đề, không lỗi, cứ làm đi.
Bạn không thể tạo Cloudflare hay Vercel dễ dàng như vậy. Bạn không thể không hiểu biết gì rồi chỉ nói “Vercel” là xong. Xin lỗi, mọi chuyện không vận hành như thế.
Rất nhiều người có ý tưởng rằng AI là một công cụ thần thánh vô hạn. Không. Tôi rất tiếc phải nói điều này, nhưng hiện nay bạn có thể làm nhiều hơn rất nhiều.
Ngay cả một người thiếu hiểu biết trong nhiều lĩnh vực cũng có thể tạo ra vẻ ngoài của một phần mềm hoạt động, và thực sự tạo ra phần mềm hoạt động trong một số nhóm vấn đề mà họ không có kiến thức. Điều đó hoàn toàn hợp lý, tôi không phản đối.
Nhưng ý tưởng rằng bạn có thể xây dựng một dịch vụ bền vững, đã tồn tại 10 năm và phục vụ hàng triệu người chỉ bằng cách nói với AI “không được mắc lỗi” — đó là lúc những thứ làm não nhũn đã tràn vào.
Giống như có Subway Surfers chạy trong một cơn loạn thần, đang làm một thứ quan hệ kỳ quặc nào đó để tạo ra những đứa con AI điên rồ. Tôi cũng không biết phép so sánh đó nghĩa là gì, nhưng bạn hiểu ý tôi rồi đấy.
Nếu tôi là Charlie hay MoistCr1TiKaL, tôi sẽ nói đó là thứ được bịa thẳng từ mông. Nhân tiện, tôi rất thích câu đó. Lần nào nghe cũng khiến tôi vui và mỉm cười.
Một chủ đề lớn khác là quá nhiều văn bản vô dụng. Quá nhiều văn bản vô dụng. Quá nhiều văn bản vô dụng. Điều đó hoàn toàn đúng. Nó tạo ra quá nhiều thứ rác.
Tôi có ảnh chụp màn hình và phải cho các bạn xem. Buồn cười lắm. Tôi nói với AI: “Được rồi, không cần narrative. Chỉ cần lập danh sách các repository pattern, rồi chúng ta sẽ xây dựng từng cái một.”
Nó trả lời: “Được, field guide, mỗi chủ đề một file.” Tôi nghĩ: “Thế đã quá nhiều rồi.” Nó còn nói: “Mở file bạn cần. Mỗi file là sự thật và code.” Tôi lại phải nói: “Dừng lại. Không narrative.”
Tôi đã nói rõ là không cần narrative, vậy mà nó viết narrative về việc không cần narrative. Tôi nói: “Bạn ơi, tôi đã bảo không có narrative,” và nó viết narrative trong khi mô tả việc không có narrative. Có rất ít thứ khiến tôi ghét hơn những bức tường văn bản vô dụng mà các “đứa con AI” này tạo ra.
Chúng không dừng lại. Chúng cứ tiếp tục tạo ra thật nhiều văn bản. Mỗi lần tôi nói “đừng viết narrative”, nó lại trả lời: “Đã rõ, sếp.” Trong tài liệu, nó viết “không narrative”, rồi mô tả điều đó theo cách đầy narrative. Cực kỳ bực mình.
Điều đó cũng có nghĩa là tôi lãng phí rất nhiều thời gian. Cảm giác như tôi đang tự làm khổ mình mà chẳng vì lý do gì. Tôi ngồi đọc một bức tường văn bản khổng lồ, rồi cuối cùng nghĩ: “Thứ này có thể chỉ cần một câu thôi mà.”
Nó viết cho tôi 400 từ chỉ để nói: “Nhân tiện, interface của client ở đây khá tệ.” Lần sau cứ nói thẳng như vậy đi. Nếu ai biết cách khắc phục chuyện này thì tôi rất muốn biết.
Tôi đã thử GrubSpeak. Đúng là nó làm giảm lượng output, nhưng khỉ thật, nó biến thành một đoạn văn GrubSpeak. Kiểu như: “Tôi không hiểu. Điều này khiến việc trở nên khó khăn. Tôi ước nó theo cách này. Phải đưa ra quyết định. Luôn chịu nhiều áp lực.”
Bạn chỉ muốn nói: “Này, làm ơn, cứ nói đúng từ cần nói đi.”
Đây có lẽ là vấn đề được mọi người nhắc đến nhiều nhất. Dù bạn cực kỳ ủng hộ AI hay mới bắt đầu bước vào thế giới AI, đây dường như là phàn nàn số một mà tôi thấy gần như ở khắp nơi: cảm giác không thực sự sở hữu bất cứ thứ gì AI tạo ra.
Với tôi, đây là một trong những rào cản khó vượt qua nhất. Nhưng hiện giờ tôi nghĩ mình đã có cách giải quyết. Vì vậy, phần này thực sự là lúc tôi đưa ra lời khuyên.
Ví dụ, khi bắt đầu một dự án mới, thay vì chỉ “vibe” cho xong, tôi thực sự suy nghĩ sâu về hình dạng của hệ thống và điều mình muốn. Sau đó tôi mới để AI tạo thử một thứ, cảm nhận toàn bộ quá trình, thiết lập nó rồi bảo đảm rằng nó thực sự hoạt động. Tôi ngồi đó và lặp lại nhiều lần.
Cách này tạo ra quá nhiều test, quá nhiều dòng code và đủ thứ khác. Nhưng tôi thu được rất nhiều hiểu biết: tôi muốn một automation server, muốn phát hiện các automation client, muốn điều này, điều kia. Tôi đã có được toàn bộ sự hiểu biết đó ở mức rất sâu.
Sau đó, tôi thực sự làm V2 của sản phẩm và nói: “Được rồi, giờ mình sẽ thiết kế lại, suy nghĩ kỹ về từng bước, bảo đảm mọi thứ được phân loại hợp lý.” Tôi làm điều tương tự cho client và xây dựng một hệ thống mà mình thực sự thích.
Tôi thường dùng số dòng code như một cách kiểm tra, không phải vì nhiều dòng code tốt hơn hay ít dòng code tốt hơn, mà vì tôi đã xây dựng cùng một thứ với cùng một tập feature theo cách có suy nghĩ hơn và cô đọng hơn.
Cuối cùng, tôi thực sự hiểu mọi thứ mình đang xây dựng. Phiên bản sau thường chỉ còn một nửa, thậm chí một phần tư số dòng code. Tại sao? Vì tôi suy nghĩ kỹ hơn về test, hình dạng của hệ thống và cấu trúc nền tảng của từng component.
Tôi thực sự đã phát triển phần mềm bằng AI lần thứ hai. Và tôi thấy cách này rất tuyệt. Dự án tôi đang làm hiện nay bắt đầu với 100.000 dòng code, nhưng có lẽ cuối cùng sẽ chỉ còn khoảng 25.000 đến 30.000 dòng.
Với tôi, điều đó rất tuyệt. Nó có nghĩa là tôi đã suy nghĩ kỹ, xây dựng lại mọi thứ, có database shape tốt hơn và mọi thứ đều tốt hơn vì tôi đã trải qua một lần. Đến lần thứ hai, cảm giác thực sự rất tốt.
Nhân tiện, hiện giờ tôi đang làm điều này cho Omachi.
Tôi đang làm toàn bộ phần automation của Omachi. Tôi xây dựng một thứ tên là Oligoti, tức “oligarchy”. Trong đó, tôi đang xây dựng một agentic testing framework khá lớn cho OS.
Để làm được điều đó, tôi cần một cách thực sự phân tán để spawn tất cả các server và mọi thứ liên quan. Tôi đã làm phiên bản đầu tiên như một thử nghiệm và rất thích nó.
Tôi có thể suy nghĩ về các custom harness, xem chúng thực sự nên hoạt động như thế nào. Bây giờ tôi đang xây dựng phiên bản thứ hai với toàn bộ feature cũ, nhưng được suy nghĩ kỹ hơn nhiều và ít code hơn rất nhiều.
Điều đó khiến tôi vui. Tôi đã tạo ra nó. Tôi thực sự cảm thấy hài lòng và có quyền sở hữu vì mình đã suy nghĩ kỹ về từng chi tiết.
Lời khuyên tốt nhất của tôi là: đừng chỉ làm một thứ cẩu thả rồi dùng luôn. Hãy làm cẩu thả để khám phá. Đó là điều tuyệt vời nhất.
Những người làm kỹ thuật thực sự, những người đã làm việc này lâu năm, đều biết rằng bạn luôn xây dựng một prototype để khám phá. Dù thường thì sếp sẽ nói: “Prototype đẹp đấy. Khi nào đưa lên production vậy?”
Bạn xây prototype, rồi nhận ra: “Ôi trời, mình đã học được quá nhiều điều. Được rồi, giờ mình sẽ xây bản thật.” Và bạn xây bản thật nhanh hơn, tốt hơn. Tôi đang làm điều tương tự, chỉ là giờ tôi làm với AI.
Thành thật mà nói, cách này khiến tôi hài lòng hơn rất nhiều với những gì mình xây dựng, và tôi thực sự cảm thấy có quyền sở hữu.
Vấn đề cuối cùng, cũng là vấn đề khiến tôi thấy đáng tiếc nhất, là một junior muốn tự tay học những điều mới, nhưng không ai xung quanh cho phép vì họ có thể đạt kết quả tức thì và giao hàng nhanh hơn. Vì vậy, người đó không thể tìm thấy chuyên môn trong công việc của mình.
Thành thật mà nói, tôi cảm thấy đây là sự rắc rối tồi tệ và lớn nhất của AI. Trong một thời gian dài, mọi người được tạo điều kiện để trưởng thành và hiểu vấn đề, vì công ty không thực sự có lựa chọn nào khác.
Nhưng điều đó đang biến mất, vì giờ đây những người mới có thể hiệu quả ngang Claude. Với nhiều người, đó đã là mức hiệu quả khá tốt.
Tuy nhiên, nếu bạn thách thức AI hoặc đưa ra một ý tưởng tệ, AI sẽ không nói: “Này, tôi biết bạn đề xuất như vậy, nhưng sau khi xem xét kiến trúc và mọi thứ, tôi nghĩ cách này sẽ tốt hơn. Hãy thảo luận một chút trước khi thực hiện thay đổi.” Không, nó chẳng bao giờ làm thế.
Nó chỉ đưa cho bạn một PR dài 1.000 dòng và nói: “Tôi đã làm đúng như bạn yêu cầu.” Vì bạn không quen thuộc với codebase, bạn đã đưa ra một loạt quyết định ngớ ngẩn và thêm rác ở khắp nơi.
Điều này còn tệ hơn gấp mười lần vì những người trẻ tuổi thậm chí không có cơ hội học xem thế nào là tốt. Làm sao bạn biết thế nào là tốt? Bạn không biết.
Tôi thực sự cảm thấy thương các junior nhất, vì các bạn chịu thiệt thòi nhiều nhất trong tất cả chuyện này. Bây giờ các bạn được kỳ vọng phải làm việc như senior, vì đã có một công cụ tạo ra kết quả được cho là ngang hoặc tốt hơn senior, nhưng các bạn lại không có được sự hiểu biết tương ứng.
Điều đó giống như một nhiệm vụ bất khả thi. Và tôi phải nói rằng đến hôm nay tôi vẫn cảm thấy y như vậy. Kiến thức kỹ thuật thực sự là một điều rất có giá trị.
Dành thời gian đọc và học, xây dựng prototype, suy nghĩ về mọi edge case và xử lý từng edge case thực sự là điều tốt. Học về mocking, rồi học tại sao bạn ghét mock, nhưng cũng hiểu rằng đôi khi mock là một điều cần thiết dù không lý tưởng.
Hãy học dependency injection, hiểu tại sao nó có thể giải quyết nhiều vấn đề, đồng thời cũng hiểu tại sao nó có thể trở nên tồi tệ. Hãy tiếp tục học hỏi.
Tôi biết trong thời đại AI, nói những điều này không hấp dẫn. Nhưng tôi không nghĩ việc chạy ở tốc độ tối đa mà không học gì, thậm chí không hiểu mình đang làm gì, sẽ tốt cho bạn về lâu dài, trong năm năm tới.
Bạn muốn xây dựng phần mềm như thế nào? Bạn muốn vẫn là người không hiểu gì, chỉ được bảo phải làm gì, rồi nhập mọi thứ vào và hy vọng nó hoạt động? Bạn xây dựng các evaluation chỉ để nói: “Ừ, tôi nghĩ cái này chạy được”, sau đó giao nó đi mà không biết nó tốt hay tệ?
Hay bạn muốn có khả năng nhìn thấy một vấn đề và nói: “À, chúng ta sẽ chia nó như thế này. Làm thôi. Cách này sẽ hiệu quả, sẽ tốt, cho phép hệ thống phát triển theo hướng này và tạo ra những trade-off kia.”
Nếu muốn đạt được điều đó, bạn phải nỗ lực. Bạn phải tự giành lấy nó. Tôi không thấy cách nào khác ngoài đọc, thực hành trên bàn phím và dành một chút thời gian.
Tôi cũng muốn nói thêm một điều. Hiện giờ mọi người liên tục nói rằng nếu bạn không làm những việc này thì bạn sẽ không thành công. Hãy nhớ rằng bạn còn cả một cuộc đời dài phía trước, và chúng ta hoàn toàn không biết tương lai sẽ ra sao.
Có thể một ngày nào đó Cloud sẽ thông minh đến mức bạn không cần suy nghĩ về bất cứ điều gì. Bạn chỉ cần nói “hãy làm đi”, và nó sẽ tạo ra cấu hình server lý tưởng, phần client-side lý tưởng, sắp xếp toàn bộ dữ liệu, thậm chí biết cách tạo các table tốt trong database. Khả năng đó khá đáng ngờ, nhưng dù sao đi nữa, có thể sẽ đến ngày mọi kiến thức kỹ thuật theo một nghĩa nào đó trở nên vô dụng vì AI quá mạnh.
Chúng có thể làm mọi thứ, biết toàn bộ vũ trụ và tổng hợp mọi kinh nghiệm. Tôi không biết ngày đó sẽ đến khi nào.
Cách dễ nhất để diễn đạt là: nếu hôm nay tôi tuyển một người, tôi có muốn người chỉ đóng vai proxy, lặp lại đúng những gì tôi nói, chuyển lời tôi thành code, nhìn nó chạy rồi nhấn merge không?
Hay tôi muốn người thực sự suy nghĩ về vấn đề, nói rằng: “Tôi không nghĩ chúng ta cần những test này. Tôi muốn test có dạng như thế này. Tôi muốn server như thế này. Đây là cách bố trí, đây là thứ tôi muốn trên CLI, đây là thứ tôi muốn ở đây”, và thực sự suy nghĩ kỹ về mọi vấn đề?
Bạn nghĩ tôi muốn ai? Tôi muốn người thứ hai, 100% thời gian. Chỉ làm proxy không bao giờ là một ý hay.
Hãy luôn cố gắng trở thành nhiều hơn một proxy chỉ chuyển thông tin từ một người sang một ô nhập văn bản.
Được rồi, đó là phản hồi của tôi về tất cả những vấn đề này. Nếu bạn thích, hãy nhấn nút đó đi. Bạn biết tên nút là gì mà.
Thực ra PewDiePie cũng biết tên nút đó.
Một khóa học khác tôi mới thực hiện gần đây là khóa học GitHub do một YouTuber khác là Primogen tổ chức, và tôi rất thích nó. Đây là điều người này đã dạy tôi.