Đúng như bài viết nói, vì đây vốn đã là thứ được người ta tận hưởng dưới dạng một "trò chơi", nên trước đây nó cũng không phải ở mức quá khó để người bình thường tiếp cận.
Mối đe dọa xuất hiện khi bạn đăng lên những bức ảnh có thể dễ dàng bị xác định vị trí trong những tình huống mà lẽ ra không nên để lộ vị trí.
Ngay cả trước đó, như trong các bình luận trên Hacker News đã nói, việc đăng bất cứ thứ gì lên Internet công khai vốn dĩ đã là chuyện phải mặc định rằng thông tin sẽ bị lộ ra.
Chẳng phải 80% lý do khiến các công ty nhỏ cũng dùng nguyên xi những công cụ được thiết kế theo nhu cầu của các tập đoàn lớn là vì điều này sao. Người cần kiểm soát chuyện đó lẽ ra phải là CTO, nhưng cũng có trường hợp ngay cả CTO lại đang nghĩ đến chuyện chuyển việc sang một tập đoàn lớn.
Tôi rất đồng ý với nội dung ở trên!
Tuy vậy, tôi cũng cho rằng ở các công ty nhỏ, việc over-engineering đôi khi xảy ra vì những người nhắm đến các công ty lớn muốn tích lũy kinh nghiệm với những công cụ đó khi làm ở công ty nhỏ.
Tất nhiên là sếp chắc cũng không thích lắm đâu haha
Nếu không có nhiều việc để làm thì kiểu gì cũng sinh ra mấy trò vô bổ thôi haha
Cả bài toán dễ cũng phải giải cho thành khó thì mới có cái để làm màu là mình đã làm được gì đó. Nếu làm đơn giản thì cũng có nhiều người tưởng là nó vốn dễ mà.. hahahaha
Spring ở Hàn Quốc đúng hơn không phải là sự tôn sùng...
Mà là một thứ lai tạp, nơi sự bất tài của chính phủ và sự lười biếng của lập trình viên cùng tồn tại nhiều.
Cuối cùng, cần hiểu vấn đề mà các công nghệ đang cố giải quyết, cũng như bối cảnh đã dẫn tới sự ra đời của công nghệ đó. Các ví dụ trong bài gồm những trường hợp như sau.
Cassandra -> giải pháp để xử lý vấn đề scale của cơ sở dữ liệu trong dịch vụ của Facebook
Kafka -> giải pháp để xử lý vấn đề scale trong xử lý dữ liệu tại Linkedin
Tôi nghĩ cần xem xét kỹ xem vấn đề mà chúng giải quyết có thực sự phù hợp với vấn đề mà mình đang cố giải quyết hay không.
Có vẻ khá nhiều người đôi khi quên mất rằng công nghệ là công cụ chứ không phải mục tiêu.
Khoảnh khắc những thứ như “đã được kiểm chứng ở Big Tech”, “dạo này được dùng nhiều”... trở thành điều kiện chính khi lựa chọn công nghệ, thì việc chi phí tăng lên một cách không cần thiết cũng tự nhiên đi theo.
Đây đúng là vấn đề mình đã từng băn khoăn, vậy mà cái này ..
Đúng như bài viết nói, vì đây vốn đã là thứ được người ta tận hưởng dưới dạng một "trò chơi", nên trước đây nó cũng không phải ở mức quá khó để người bình thường tiếp cận.
Mối đe dọa xuất hiện khi bạn đăng lên những bức ảnh có thể dễ dàng bị xác định vị trí trong những tình huống mà lẽ ra không nên để lộ vị trí.
Ngay cả trước đó, như trong các bình luận trên Hacker News đã nói, việc đăng bất cứ thứ gì lên Internet công khai vốn dĩ đã là chuyện phải mặc định rằng thông tin sẽ bị lộ ra.
Thời gian và chi phí cần bỏ ra đã rẻ hơn hàng chục lần. Rõ ràng đây là một sự gia tăng mức độ đe dọa.
Chẳng phải 80% lý do khiến các công ty nhỏ cũng dùng nguyên xi những công cụ được thiết kế theo nhu cầu của các tập đoàn lớn là vì điều này sao. Người cần kiểm soát chuyện đó lẽ ra phải là CTO, nhưng cũng có trường hợp ngay cả CTO lại đang nghĩ đến chuyện chuyển việc sang một tập đoàn lớn.
Thực ra chỉ là máy tính làm thay phần phiền phức thôi; chẳng phải bản thân phương pháp này vốn đã tồn tại rồi sao?
Ái chà, PTSD chốn công sở lại ùa về.
Tôi rất đồng ý với nội dung ở trên!
Tuy vậy, tôi cũng cho rằng ở các công ty nhỏ, việc over-engineering đôi khi xảy ra vì những người nhắm đến các công ty lớn muốn tích lũy kinh nghiệm với những công cụ đó khi làm ở công ty nhỏ.
Tất nhiên là sếp chắc cũng không thích lắm đâu haha
Việc gọi vốn đã khó, tạo ra doanh thu đủ lớn cũng đã khó, vậy mà còn phải làm được cả hai...
Nếu không có nhiều việc để làm thì kiểu gì cũng sinh ra mấy trò vô bổ thôi haha
Cả bài toán dễ cũng phải giải cho thành khó thì mới có cái để làm màu là mình đã làm được gì đó. Nếu làm đơn giản thì cũng có nhiều người tưởng là nó vốn dễ mà.. hahahaha
Mùa xuân dễ tuyển người nên...
Có vẻ như được đặt theo tên Kermit the Frog....nhỉ?
Vì sợ sau này phải sửa một thứ được làm nhỏ thành lớn, nên có những trường hợp ngay từ đầu đã làm nó thật lớn...
Tôi nghĩ đây là bài viết cũng có thể áp dụng cho K8s. Nó làm tôi nhớ đến cuốn sách "Cách code để khó bảo trì". Haha
Spring ở Hàn Quốc đúng hơn không phải là sự tôn sùng...
Mà là một thứ lai tạp, nơi sự bất tài của chính phủ và sự lười biếng của lập trình viên cùng tồn tại nhiều.
Cuối cùng, cần hiểu vấn đề mà các công nghệ đang cố giải quyết, cũng như bối cảnh đã dẫn tới sự ra đời của công nghệ đó. Các ví dụ trong bài gồm những trường hợp như sau.
Tôi nghĩ cần xem xét kỹ xem vấn đề mà chúng giải quyết có thực sự phù hợp với vấn đề mà mình đang cố giải quyết hay không.
Rất đồng cảm. Suy cho cùng, Spring cũng chỉ là một công cụ để giải quyết vấn đề mà thôi.
Đã học được rất nhiều. Cảm ơn vì bài viết hay.
Có vẻ khá nhiều người đôi khi quên mất rằng công nghệ là công cụ chứ không phải mục tiêu.
Khoảnh khắc những thứ như “đã được kiểm chứng ở Big Tech”, “dạo này được dùng nhiều”... trở thành điều kiện chính khi lựa chọn công nghệ, thì việc chi phí tăng lên một cách không cần thiết cũng tự nhiên đi theo.
Ở Hàn Quốc, kiểu sùng bái theo phong trào với Spring khá mạnh.
Chỉ đọc bài thì thấy toàn là những điều quá hiển nhiên được liệt kê ra thôi... nhưng thực tế chắc lại khác nhỉ..