Video học lập trình mỗi ngày

Bài viết này được đưa vào Series: No Code: Ở đây không có code

Tuần đầu tiên của năm 2025. Xin chào năm mới!

Và tôi muốn nói điều này, khi anh em chúng tôi đã trải qua những câu chuyện về kỳ lân, về cổ tức và 3 năm reset một lần (các công ty lớn luôn như vậy...) or chuyển qua một dự án không hề có kinh nghiệm, vì vậy: Kỳ vọng là gốc rễ của phần lớn thất vọng. Kỳ vọng càng cứng, thất vọng càng sắc. Nó đâm không trật phát nào.

Mục tiêu của 2024 đã được gạch bỏ cho dù nó chưa hoàn thành so với mục tiêu đưa ra. Thật ra không cần phải chồng chất những mục tiêu dài hạn từ năm này qua năm khác mà hãy tập trung vào mục tiêu ngắn hạn mỗi năm và tôi nghĩ khi qua thời điểm đó, tốt nhất hãy gạch bỏ nó. Và lúc này những mục tiêu mới được đề ra, tôi thích cách tiếp cận như thế này với suy nghĩ hiện tại.

Năm 2024 tôi đặt mục tiêu cho mình 3 mục tiêu, trong đó có một mục tiêu phát triển kênh youtube lên 70k Subscribes, nhưng mục tiêu đó chưa đạt được và chỉ đạt 50K Subscribes. Ok lần này tôi sẽ gia hạn mục tiêu này thay vì từ bỏ nó. Và có thể năm sau hơi khó khăn có thể tôi sẽ điều chỉnh giảm kỳ vọng lại có thể 60 - 70k thì tuyệt vời, đúng không?

Tôi đã nghĩ nhiều về AI - một assistant của những cao thủ. Thật ra tôi không sợ nó, mà chỉ sợ những người vốn dĩ nội lực đã mạnh, giờ lại thêm một con Pet luôn theo push mana như phái Nga My thì quả là đáng sợ. Trên con đường họ đi, tôi nghĩ sẽ loại bỏ rất nhiều kẻ yếu đuối. Và layoff không thể tránh khỏi...

Nhưng cũng may mắn với tôi, thời gian qua tôi đã gặp rất nhiều người đồng hành trong và ngoài nước, cũng như trong ngành và ngoài ngành. Tất cả những người bước qua ta đều đáng phải gặp đúng không?

Và để xem năm nay tôi sẽ vinh dự đón tiếp những ai và trên con đường tôi đi có những vị nào sẽ cùng đồng hành với mình. Tôi nghĩ ở Trạm dừng chân tiếp theo có rất nhiều vị khách rất BỰ đang chờ đón...

Chúc anh chị một năm mới với nhiều mục tiêu được thiết lập cho mình và cho gia đình của chính mình. Cố gắng gạch bỏ nó một cách dễ dàng hơn tôi.

Và hôm nay câu chuyện là gì? Đó chính là VẬT CỰC TẤT PHẢN..

Chuyện cuối tuần - Vật cực tất phản

Hôm nay tôi muốn đề cập đến một khái niệm mà tôi đọc qua trong cuộc sống là đúng, nhưng trong lập trình cấp độ ngôn ngữ thì tôi thấy nó chưa đúng, nhưng lạ thay với cấp độ doanh nghiệp thì nó lại đúng.

Khái niệm được đề cập như sau: "Diminishing Returns" tôi nghe giang hồ bảo là một khái niệm trong kinh tế học.

Ái chà, trước giờ tôi có biết kinh tế học là gì đâu? Nhưng nếu dịch ra theo kiểu giang hồ nôm na gọi là "Vật cực tất phản" ở trong reddit có mục về cum từ này.

Hiểu theo cách nhìn nhận của tôi nó là "Cái gì đạt tới đỉnh thì ắt sẽ đổi chiều". Trong cuộc sống được mô tả rất nhiều như khi xe lên dốc, và tới đỉnh của dốc thì bắt đầu sẽ xuống dốc, cứ như vậy dốc làm gì có dốc mãi.

Nước tận cùng thành thác đổ, người tận cùng là hồi sinh. Triết lý câu này rất hay trong cuộc sống.

Con người cũng vậy đạt tới đỉnh của tiền bạc thì lại có những phẩm chất xuống dốc. Tôi muốn dừng ở đây, vì tôi không đủ khả năng phân tích thêm.

Vật cực tất phản - Code - Business

Nếu áp dụng "Vật cực tất phản" trong Business có lẽ nó 99% là đúng vì hãy xem một số gã khổng lồ thời của tôi như Nokia, Yahoo!, ToShiba... Họ đã tới đỉnh của con dốc chưa, có lẽ là đến, họ chạm đáy của dốc chưa, có lẽ là chạm, và liệu họ sẽ hồi sinh?

Còn nếu áp dụng trong cấp độ lập trình các ngôn ngữ như JAVA, Go, Nodej, Python thì tôi thấy chưa đúng với câu nói trên. Vì sao? Tôi kể cho các bạn nghe nhanh về câu chuyện "không đúng lắm" tối ưu về Lập trình đồng thời. Tôi lấy JAVA làm ví dụ.

Lập trình đồng thời (Concurrency)

Nếu như các anh chị có học về JAVA thì có lẽ ví dụ này anh chị sẽ dễ hình dung hơn (tốt hơn hết là hiểu về Stream trong JAVA), tôi sẽ đưa ra ví dụ từ lúc sơ khai java 5 đến giờ.

• Lập trình đồng thời (Concurrency) KHÔNG phải là "làm nhiều hơn để có kết quả tốt hơn"

"Diminishing Returns" ngụ ý rằng việc tăng đầu vào (ví dụ: thêm luồng) đến một mức độ nào đó sẽ không mang lại thêm lợi ích, thậm chí gây phản tác dụng.

Nhưng mục tiêu của lập trình đồng thời (với Future, CompletableFuture) không chỉ đơn thuần là "làm nhiều hơn" mà là "làm thông minh hơn", "tận dụng tốt hơn" tài nguyên (CPU) để giảm thời gian chờ đợi, tăng hiệu suất ứng dụng.

Khái niệm "vượt quá giới hạn" trong lập trình đồng thời không chỉ nằm ở số luồng, mà còn ở cách quản lý luồng, xử lý đồng bộ hóa, thiết kế kiến trúc...

• Future, CompletableFuture - Cải tiến, KHÔNG phải "vật cực"

Sự ra đời của Future (Java 5) rồi CompletableFuture (Java 8) là những bước cải tiến trong lập trình đồng thời, không phải là "vật cực" dẫn đến "tất phản".

Trước Future: Lập trình đa luồng (multi-threading) truyền thống khá phức tạp, khó quản lý, dễ xảy ra lỗi (race condition, deadlock).

Future (Java 5): Cung cấp một cách trừu tượng hơn để xử lý kết quả của tác vụ bất đồng bộ, nhưng vẫn còn hạn chế (ví dụ: phải block bằng get(), khó kết hợp các Future).

CompletableFuture (Java 8): Khắc phục những hạn chế của Future, cho phép lập trình bất đồng bộ linh hoạt, dễ dàng kết hợp các tác vụ, xử lý lỗi tốt hơn, nâng cao hiệu suất chứ không phải "làm cho mọi thứ tệ hơn".

Không thể nói: "Dùng CompletableFuture là 'vật cực tất phản' so với Future" vì CompletableFuture rõ ràng là tốt hơn, mạnh mẽ hơn.

• "Quá nhiều luồng" - Vấn đề nằm ở "quản lý", không phải "số lượng"

Đúng là việc tạo ra quá nhiều luồng có thể gây lãng phí tài nguyên, giảm hiệu suất. Nhưng đây là vấn đề về quản lý tài nguyên (resource management), không phải bản chất của lập trình đồng thời hay Future/CompletableFuture.

"Giới hạn" ở đây là khả năng của hệ thống, cách thức sử dụng luồng, chứ không phải là một con số cố định.

Các công cụ như ExecutorService với thread pool giúp quản lý luồng hiệu quả, tránh tạo ra quá nhiều luồng không cần thiết.

Hiểu về Lập trình đồng thời

"Vật cực tất phản" hay "Diminishing Returns" không phản ánh chính xác sự phát triển và cải tiến trong lập trình đồng thời, đặc biệt là với Future và CompletableFuture.

Future và CompletableFuture là những công cụ giúp lập trình viên tận dụng tốt hơn tài nguyên hệ thống, nâng cao hiệu suất ứng dụng, chứ không phải là "làm nhiều hơn để rồi nhận lại ít hơn".

Vấn đề "quá tải" luồng nằm ở cách quản lý, thiết kế chứ không phải ở bản thân các công cụ lập trình đồng thời.

Thay vì "vật cực tất phản", ta nên nói thế này: Lập trình đồng thời cần sự hiểu biết thấu đáo về cách thức hoạt động của các công cụ, kỹ năng thiết kế tốt để tránh các lỗi tiềm ẩn và tối ưu hóa hiệu suất.

Vàd đây chính là những khái niệm tiếp theo tôi sẽ giới thiệu đến anh chị cho những phần tiếp theo đó là Future và CompletableFuture những công cụ mạnh mẽ, giúp đơn giản hóa và nâng cao hiệu quả lập trình bất đồng bộ khi được sử dụng đúng cách.

Xin chào!