ko clean còn chán hơn, như t đang phải sửa code trong 1 file 60k dòng
Lạ nhỉ, trừ khi sửa ERD còn đâu có phải sửa mấy cái đấy đâu nhỉ, còn BL thì clean mới dễ sửa chứ, giả sử t code bẩn cho luôn BL vào view/model thì thằng sửa khóc thét
SOLID để tăng năng suất, b máy móc đến nỗi tự làm giảm năng suất vì SOLID thì sai rồi
del mẹ, nãy giờ tôi luôn nói
tập trung function tối ưu sau
mà thôi mấy ông trình cao quá, tôi trình còi, ếch ngồi đáy giếng, nên tôi tập trung kiếm tiền, để dành phần code đẹp cho mấy ông
tôi nói rồi, mấy ông luôn luôn nếu... thì...., luôn luôn muốn phức tạp mấy thứ ko cần thiết, luôn luôn suy nghĩ mấy cái viễn tưởngtrình độ dev nó khác nhau ở đó, pro thì biết cách biến phức tạp thành đơn giản, còn newbie thì biết cách biến đơn giản thành phức tạp
thế nhé
[Tạm thời ignore ông 2007
].
Thật ra tôi cũng toàn access db từ controller.Đại khái là vậy, tuỳ vào project sẽ có rất nhiều cách làm khác nhau. Nhưng access trực tiếp database từ web controller sẽ xoá bỏ hết các khả năng này, càng làm code sẽ càng rối
Bác có thể cho em biết nếu làm một project thông thường, không qúa gắt cũng k quá lỏng về deadline thì bác sẽ chọn để chia ra thành những layer nào được không?[Tạm thời ignore ông 2007
Không phải.
1 là Web là entry point, nếu mỗi lần vào website, bạn query trực tiếp vào database thì rất dễ bị treo khi dính DDOS. Mình chỉ cần dùng JMeter query 100 thread/second đến entry point là database có khả năng bị lock. Thường có mấy cách để giải quyết vấn đề này, 1 là dùng rate limiter trên API Gateway, 2 là implement rate limiter trên chính web controller, 3 là caching.
2 là bạn mất đi khả năng enrich user data. Ví dụ giờ mình muốn query thêm user preference ở 1 table khác. Với cách hiện tại thì bạn phải viết thêm 1 query khác trong Web Controller, query đến table user preference, rồi join lại trong web controller và return. Busines logic trong controller sẽ trở nên rất lớn, trong khi nó nên chỉ có nhiệm vụ là gọi các service có liên quan và trả lại response. Viết Unit Test cũng rất đơn giản.
3 là reusability, nếu 1 web controller khác muốn query user info y hệt, thì bạn phải copy code từ controller này, copy qua controller khác => dẫn đến khó maintain code. Hoặc bạn gọi controller này từ controller khác => lâu dài dẫn đến khả năng cyclic dependencies (Controller 1 gọi Controller 2, Controller 2 gọi Controller 3 rồi Controller 3 gọi Controller 1)
Còn nếu như bạn đẩy database task xuống 1, 2 layer nữa như service layer thì các controller gọi service layer là xong, Unit test 1 lần bên Service Layer, ko bị cyclic dependencies. Ngoài ra nếu implement caching trên service layer sẽ tốt hơn là trên controller (vì share được giữa các service). Hoặc dùng caching service riêng như Memcached, Redis tuỳ project thì chỉ cần call ở Service layer là được, thay vì phải call nhiều lần ở nhiều Controller khác nhau.
Đại khái là vậy, tuỳ vào project sẽ có rất nhiều cách làm khác nhau. Nhưng access trực tiếp database từ web controller sẽ xoá bỏ hết các khả năng này, càng làm code sẽ càng rối
Tôi thấy lúc nào cũng cần clean hết. Người ta chưa clean vì người ta chưa thể clean thôi. Nhìn chung, có thể nói là do tầm nhìn của người leader và do requirement của product.
ban đầu triển khai viết thế cx đc thôi, như tôi thì tuỳ fw nữa, trc sau gì tôi cx move về service, nên mấy fw dùng DI thì tôi move luôn từ đầu cho khoẻ, còn như rails/laravel access static method nên viết trong controller lúc đầu, xong logic r move về service sauThật ra tôi cũng toàn access db từ controller.
Được cái toàn code pet project vớ vẩn nên mấy khả năng trên chưa bao giờ gặp.
Hị hị.
clean code cũng có mức độ clean, nên cứ làm tốt nhất có thể ở thời điểm làm là tốt nhất, cái gì có thể clean mà ko tốn effort thì nên làm ngay từ đầu, chứ nó cx ko có cái sau này refactorTôi thấy lúc nào cũng cần clean hết. Người ta chưa clean vì người ta chưa thể clean thôi. Nhìn chung, có thể nói là do tầm nhìn của người leader và do requirement của product.
1. Ví dụ. Ko clean thì làm cách nào product lớn nhưng grab có thể launch ở nhiều thị trường như thế. Grab có những template gen code service để giải quyết vấn đề của họ.
Tuy nhiên team startup học theo cái code gen của họ thì chê.
2. Team đông, người ra người vào nhiều, nhiều repo, phức tạp từ việc setup. -> Cần clean hơn để giảm thời gian người mới join team và làm task.
Chuẩn để hạn chế sai lầm của dev, dev hư lắm. Giấu bug, giấu dốt, lười làm, ẩu tả. Clean cũng là một cách bắt họ làm theo những điều đúng đắn đã đc kiểm nghiêm, loại trừ những cách code ẩu tả, tà đạo của dev.
À, khi đề cập đến clean arch, thì tôi nghĩ phải nói rõ xem clean đến mức độ nào. Nhiều project chia vài ba layer là quá đủ rồi, nhưng có những project lại phải phức tạp hơn.Tôi thấy lúc nào cũng cần clean hết. Người ta chưa clean vì người ta chưa thể clean thôi. Nhìn chung, có thể nói là do tầm nhìn của người leader và do requirement của product.
1. Ví dụ. Ko clean thì làm cách nào product lớn nhưng grab có thể launch ở nhiều thị trường như thế. Grab có những template gen code service để giải quyết vấn đề của họ.
Tuy nhiên team startup học theo cái code gen của họ thì chê.
2. Team đông, người ra người vào nhiều, nhiều repo, phức tạp từ việc setup. -> Cần clean hơn để giảm thời gian người mới join team và làm task.
Chuẩn để hạn chế sai lầm của dev, dev hư lắm. Giấu bug, giấu dốt, lười làm, ẩu tả. Clean cũng là một cách bắt họ làm theo những điều đúng đắn đã đc kiểm nghiêm, loại trừ những cách code ẩu tả, tà đạo của dev.
mình lấy ví dụ trong Java nhé (giờ toàn code Java). Bên mình giờ code thế này:
Thì đó. Vẫn là cần phải có cái tư duy clean trong đầu.
Service manager chủ mang tính logic thôi nhỉ. Nó không cần cũng ko sao.mình lấy ví dụ trong Java nhé (giờ toàn code Java). Bên mình giờ code thế này:
Controller > Service > Data Service > Repository
Trong Controller dùng Dto với Mapper (Mapstruct) package level (interface xxxMapper, class xxxDto, ko dùng public class Dto, public interface xxxMapper)
Trong Service dùng package level Mapper với public Domain Object (đây là public class duy nhất trong đống Dto, Domain, Database Model Entity)
Data Service sẽ có default package level Mapper với default package level Database Model (không dùng public Database Entity)
Các layer chỉ được gọi layer bên phải, không được gọi ngược lại hay ngang hàng để tránh cyclic dependencies.
Ngoài ra nếu mình cần 2 kết quả của 2 Service thì trong package của Controller, mình tạo thêm 1 package level ServiceManager, gọi 2 service khác rồi trả lại kết quả cho Controller:
Controller > Service Manager > Service > Data Service > Repository
Cách làm này gần giống với Clean Architecture, sửa layer bất kì sẽ ko ảnh hưởng đến layer bên phải. Nhưng có thể dùng trong cùng 1 module (ko nhất thiết phải chia ra nhiều module như clean architecture).
Bạn nào có ý kiến khác thì reply để mình tham khảo thêm
Tôi đồ rằng ông rồng cũng phải clean thôi, nhưng là clean theo cách của ổng.Thì đó. Vẫn là cần phải có cái tư duy clean trong đầu.
Vì sao: Đơn giản codebase xịn trên thế giới có cái nào không clean? Trình architechture không hay đọc code à? Đọc code hay thì sẽ thích code hay.
Sẽ rất phi lý nếu độ senior của 1 developer không tuyến tính với tính clean trong code của họ.
Còn clean đến mức nào thì bao nhiêu ngôn ngữ bao nhiêu framework, còn nhiều cách deploy nữa. Không phán được.
Nếu trả lời cho câu clean có giúp chúng ta tốt hơn thì nó cũng như là đi học đại học có giúp chúng ta đi làm tốt hơn.
Thật khó nói.
Đúng rồi, mình cũng ít dùng nó.
Concept này khá hay. Xuống dưới database model thì có dùng ORM được không? Vì bình thường chỉ có 1 entity map với 1 database table, mà như thế là thành shared entity :-? Nếu dùng manual query (như mybatis) thì ko có vấn đề.
Mình thấy như architect hiện giờ làm mới mà dự án lớn thì xài microservices, 1 team sở hữu 1 hoặc vài domain là ổn. Thường chia ra domains như vậy thì sources sẽ không lớn. Xong rồi ở các microservices xài 3 layers hoặc thêm Cqrs là ok. Cũng ko cần phải over engineering quá bằng cái clean architect này làm gì.
1 slice hoàn toàn có thể dùng micro ORM hay full ORM hoặc dùng external API, sẽ có những đoạn code bị lặp nhưng bù lại sẽ có slice feature độc lập và ít phụ thuộc vào nhau thì tôi thấy cũg được
Ah ok, mình quên mất có multi mapping. Cái này micro ORM hay full ORM đều được.
