Luật 3 lần là một vấn đề tranh cãi. Đối với sản phẩm lâu năm, việc 1 đoạn code được sử dụng 2 lần ở 2 nơi có thể thành bug ẩn. Đúng là việc đi đến đâu refactor đến đấy là có vẻ tốn kém, rườm rà. Nhưng code được viết tốt thì ít phải refactor hơn. Để lại các đoạn legacy code có thể phải trả giá bất ngờ trong tương lai. Thiết kế lẫn code đều cần đạt được khả năng thích ứng với thay đổi trong tương lai và suy nghĩ dòng này sẽ chỉ được gọi 1, 2 lần không hơn là suy nghĩ nguy hiểm có thể đi ngược lại giá trị của code cũng như thiết kế, sản phẩm.
refactor đúng là có quy mô khác nhau, ở mức thiết kế hoặc ở mức dòng code. nhưng "refactor ở quy mô nhỏ" có thể là khó đong đếm, vì review code đã loại bỏ lỗi ở mức quy mô "nhỏ" khá nhiều.
refactor thì không hời hợt được và cần sự quyết tâm đáng kể. Nguồn lực cho refactor thường không được tính toán nghiêm túc trong các dự án và khiến việc refactor trở nên áp lực khi nó trở thành việc không tên, hay không được "tính tiền". Vì thế, nó không chỉ là việc của dev, mà ở mức quản lý dự án.
Bài viết rất hay. Mình muốn có lời khuyên cho case hiện tại đang gặp phải:
Postgresql: 14
TimescaleDB + pg_cron: Installed
Table có tần suất ghi,đọc lớn (hiện check trong base/xxxx -> size đang là 190G)
=> Mình check config postgresql thì không thấy có enable autovacuum, mà size của disk càng ngày càng tăng
Mình muốn hỏi xem có nên bật autovacumm và chạy VACUUM FULL ngay bây giờ để giải quyết tình trạng này không. Vì mình đã 2,3 lần nâng disk size lên rồi nhưng không giải quyết triệt để. Hi vọng nhận được lời khuyên từ bạn
mãi mới hiểu được cái translateZ all phải + 50px. Cho ai chậm tư duy thì ví dụ mặt front trục Ox sẽ bên phải, còn mặt back khi rotateY(180 độ) thì trục Ox của back sẽ hướng về bên trái nhé
THẢO LUẬN
Nai xừ, đọc lại nhiều lần vẫn thấy hay anh ạ 😁
nếu muốn vẽ bounding boxes các đáp án đã tô thì làm như thế nào ạ
Mình nhầm vì dữ liệu được thay đổi nên cost ở execution plan 1 bị ước lượng sai
Bởi vì index đã được thay đổi nên nó estimate cost sai!
Mình vẫn đang chưa hiểu vì sao Execution plan 2 lại tốt hơn execution plan 1 nhỉ, cost cái thứ 2 lớn hơn mà ta
@nghiand1010 Dạ vâng anh 🫡
@tmsangdev Ok thank em
Em cảm ơn đại ca :v Em dùng Camtasia với Canva đại ca ơi
Hay quá chú làm video bằng phần mềm gì thế!
Ớ Đồng học lớp Fresher Web 06 ở MISA trước à man?? Giờ join công ty nào rồi man? 🤘
Bài viết rất chất lượng ạ
hehe cảm ơn
Hay quá ad
hay qua a
bài đọc dễ hiểu
Luật 3 lần là một vấn đề tranh cãi. Đối với sản phẩm lâu năm, việc 1 đoạn code được sử dụng 2 lần ở 2 nơi có thể thành bug ẩn. Đúng là việc đi đến đâu refactor đến đấy là có vẻ tốn kém, rườm rà. Nhưng code được viết tốt thì ít phải refactor hơn. Để lại các đoạn legacy code có thể phải trả giá bất ngờ trong tương lai. Thiết kế lẫn code đều cần đạt được khả năng thích ứng với thay đổi trong tương lai và suy nghĩ dòng này sẽ chỉ được gọi 1, 2 lần không hơn là suy nghĩ nguy hiểm có thể đi ngược lại giá trị của code cũng như thiết kế, sản phẩm.
refactor đúng là có quy mô khác nhau, ở mức thiết kế hoặc ở mức dòng code. nhưng "refactor ở quy mô nhỏ" có thể là khó đong đếm, vì review code đã loại bỏ lỗi ở mức quy mô "nhỏ" khá nhiều.
refactor thì không hời hợt được và cần sự quyết tâm đáng kể. Nguồn lực cho refactor thường không được tính toán nghiêm túc trong các dự án và khiến việc refactor trở nên áp lực khi nó trở thành việc không tên, hay không được "tính tiền". Vì thế, nó không chỉ là việc của dev, mà ở mức quản lý dự án.
Bài viết rất hay. Mình muốn có lời khuyên cho case hiện tại đang gặp phải:
mãi mới hiểu được cái translateZ all phải + 50px. Cho ai chậm tư duy thì ví dụ mặt front trục Ox sẽ bên phải, còn mặt back khi rotateY(180 độ) thì trục Ox của back sẽ hướng về bên trái nhé
mình thấy có vấn đề là, nếu có nhiều dòng cùng scan_dt, thì sẽ JOIN tất cả. bài toán yêu cầu JOIN 1 dòng, và scan_dt lớn nhất
(
bài viết này đang đi khá sâu vào vấn đề build hệ thống chat, mà bỏ qua việc đó là hệ thống chat phục vụ 50 triệu người 1 ngày. Giật title quá.