canh_1412
Senior Member
uh, đang dùng testcontainer cho kafka, restAPI, db, s3.testcontainer, hơi chậm nhưng chạy dc integration test
uh, đang dùng testcontainer cho kafka, restAPI, db, s3.testcontainer, hơi chậm nhưng chạy dc integration test
Èo, sao bác nặng lời thế, user vẫn xài ts hoac js bthg mànah, DHH lười type thôi, và muốn vứt user dùng lib vào xọt rác. Giờ còn đang phổ cập no build đấy, Trmúa hmề.
, cái bỏ kia chỉ ảnh hưởng contributor thôi, mà lười type là đúng rồi, dynamic typing thì type ít hơn là đúng rồi :v.Èo, sao bác nặng lời thế, user vẫn xài ts hoac js bthg mà, cái bỏ kia chỉ ảnh hưởng contributor thôi, mà lười type là đúng rồi, dynamic typing thì type ít hơn là đúng rồi :v.

Ông nói vậy mấy anh dev trong này chửi cho đấy, trong đây toàn phật sống đi làm coder thôitheo kinh nghiệm ngắn ngủi của tôi là ngồi chà code cho cố tới lúc quay lại fix bug lại lật tung banh chành ra chứ đéo gìclean cho cố quay lại ngồi mò![]()
![]()
viết 1 dòng code phải quan tâm tới tương lai bn người 
hehe, cái này chắc là lỗi do findAll and replace :v rồi, chắc do "rush B" rồi. :VXem tệp đính kèm 2144911
thôi bào chữa làm gì, end user đang typescript dùng cái này ăn break mà bảo chỉ ảnh hưởng contributor? không để cho ai migrate dần, không bàn bạc, báo trước gì đánh cái bụp.
Bác lên cái pull request remove typescript mà nghe sấy![]()
Thế mới sinh ra thằng DTO báccontroller->service->repository
Từ bên ngoài giao tiếp với layer bên trong bác có dùng đến đến entity không bác hay chỉ dùng mỗi simple structure thôi, vì em thấy nếu không dùng thì có vẻ code khá là messy, ví dụ từ controller gọi vào service mà truyền cả một object thì khá khó cho người đọc code hiểu được trong object đó cần có những gì.
chứ 1 func truyền nguyên 1 arr hoặc 1 km params thì có maintain ối zồi ôi bác ơi 
DDD không nên áp dụng cho project vừa và nhỏ, chỉ nên áp dụng cho project lớn và có khối lượng nghiệp vụ nhiều và phức tạpmình đang thấy tư tưởng của DDD và clean architecture không khác nhau nhiều lắm. Mình không phủ nhận những điểm mạnh của DDD hay clean architecture như khi triển khai thì rất tốn thời gian và không phù hợp với những project dạng startup
Không có ông review code có mindset clean, thì đúng kiểu 3 7 21 ngày là thành nồi lẩu ngayTheo em architecture , tech stack rồi code base ngon đến đâu thì nếu dự án dài hơi rồi cũng rác thôi.
Nó chỉ ok trong trường hợp lý tưởng business rõ ràng, estimate time cũng như due date lý tưởng.
Chứ dự án cứ kéo dài vài năm, rồi chục năm, business mới đẻ ra liên tục, team dev người ra người vào thì clean đến mấy rồi cũng rác thôi.
Code base ban đầu chỉ tính toán đc đến 1 phần nào thôi k bao giờ cover được all case.
)kể cả có review thì những lúc deadline dí release version mới đến nơi rồi bắt code lại thì k kịp, thì đành phải cho lên r note lại update ver sau thôi.Không có ông review code có mindset clean, thì đúng kiểu 3 7 21 ngày là thành nồi lẩu ngay)

Vậy là chia layer giúp dễ viết test, chứ đâu phải do CA. Và hầu hết các architecture bây giờ đều chia layer.tôi làm android viết theo CA chia thành nhiều layer cảm thấy viết unit test rất dễ dàng, thậm chí nhiều lần unit tests đã cứu tôi nhiều bàn thua trông thấy. Còn nếu ko chia layer tôi nghĩ khó để viết test
nhưng mà chia layer theo kiểu uncle bob là 1 phần của CAVậy là chia layer giúp dễ viết test, chứ đâu phải do CA. Và hầu hết các architecture bây giờ đều chia layer.
blog.cleancoder.com
kể cả có review thì những lúc deadline dí release version mới đến nơi rồi bắt code lại thì k kịp, thì đành phải cho lên r note lại update ver sau thôi.
e nghĩ là rồi cũng rác thôi, rác ít rác nhiều chẳng tránh dc đâu.
quan trọng linh hoạt dc việc, chứ gò team quá thành phản tác dụng. chứ dc mấy sản phẩm mà nguyên team cứng làm với nhau mấy chục năm trời thì may ra hope
via theNEXTvoz for iPhone
, ko phải chỗ nào bên dev cũng bị dí đâu
phải tính chứ thím. thế nó mới khách quan.nếu fen bỏ deadline ra thì khác, ko phải chỗ nào bên dev cũng bị dí đâu
bên cty cũ tôi làm thì review code ko xong, ko lên dc QA server. đối với team dev gần như ko có khái niệm deadline
làm lâu thì vẫn có code rác, và lúc đó thì refactor thôi![]()

Cái deadline này thì deal lại với bên trên thôi bác, k thì đẩy thêm resource vào bác ạ. Bác thấy cảnh lên tính năng trong ngày: dev + selft test + tester + qc => incident => rollback, mất nguyên vài ng nhảy vào tìm trouble/bug để fix. Kết quả thì vừa ăn tụt kpi, vừa mất thêm resouces.kể cả có review thì những lúc deadline dí release version mới đến nơi rồi bắt code lại thì k kịp, thì đành phải cho lên r note lại update ver sau thôi.
e nghĩ là rồi cũng rác thôi, rác ít rác nhiều chẳng tránh dc đâu.
quan trọng linh hoạt dc việc, chứ gò team quá thành phản tác dụng. chứ dc mấy sản phẩm mà nguyên team cứng làm với nhau mấy chục năm trời thì may ra hope
via theNEXTvoz for iPhone

Chưa rõ bác triển khai như nào. như mình dùng thì cắt bớt đi vài thứ. mình build cho Nestjs và dotnet core cả 2 dùng CQRS- Mình có đọc cuốn Clean Architecture có tác giả Robert Martin, lúc mới đọc thì cảm thấy như tìm được chân lý vậy nhưng sau khi áp dung nó vào trong công việc thì thấy thưc sự có nhiều vấn đề, cụ thể như sau:
- Khối lượng code sẽ phình ra rất nhiều, và tồn tại rất nhiều boilerplate => code rất chán.
- Trong giai đoạn đầu của project, khi mà requirements thay đổi liên tục thì để sửa code được implement theo clean architecture rất tốn thời gian cụ thể: phải sửa entities, repository, business logic ...
- Hầu hết chúng ta đang sử dụng framework và hầu hết những framework này đều không tuân thủ Clean Architecture, nên để áp dụng nó mình phải bỏ những phần được framework hỗ trợ, và chọn cách đi lòng vòng hơn để tuân thủ SOLID. Đôi lúc thấy bản thân mình như chế tạo lại cái bánh xe vậy.
Đó là những khó khăn mình đang gặp phải khi áp dụng clean architecture vào các dự án hiện tại của mình. Để áp dụng được thì không khó, nhưng thực sự thấy có quá nhiều vấn đề. Mong các cao nhân trên đây chia sẻ về kiến trúc này và chia sẻ thêm về kiến trúc code trong các dự án hiện tại của mọi người.