thảo luận Clean Architecture có thật sự giúp ta code tốt hơn?

clean architecture thì nên sử dụng khi product domain tương đối mature, khi đó domain layer sẽ rất khó bị thay đổi bởi requirement mới.
còn một khi domain chưa mature thì bạn k nên áp dụng (đặc thù là các layer bên trên depend vào domain layer)
đôi khi cũng k nên máy móc việc áp dụng clean architecture, hay DDD, cái quan trọng là làm sao đáp ứng được các functionals và unfunctional của product.
 
deonhodangkylanthumaynua said:
Mvp thì làm láo nháo được, chứ kiếm ăn chạy xổi, đến lúc nhỡ may mắn, vào cầu, lượng user tăng đột biến, perf lởm, sv ngất lên ngất xuống. Hoặc tăng từ từ, biz nở ra, sửa chỗ nọ, vá víu chỗ kia. Bug lên bug xuống.
Click to expand...
sợ nhất mấy ông biz ko có ai sài mà cứ design cho tỉ người dùng :shame:
 
ThiLam said:
clean architecture thì nên sử dụng khi product domain tương đối mature, khi đó domain layer sẽ rất khó bị thay đổi bởi requirement mới.
còn một khi domain chưa mature thì bạn k nên áp dụng (đặc thù là các layer bên trên depend vào domain layer)
đôi khi cũng k nên máy móc việc áp dụng clean architecture, hay DDD, cái quan trọng là làm sao đáp ứng được các functionals và unfunctional của product.
Click to expand...
mấy cái product mới toanh startup đồ cứ táng mvc mvp 3 layer vào code cho lẹ mà ra feature có users refactor sau cũng chả muộn đây cứ thích tay to ngay từ đầu xong biz méo ra gì cuối cùng project chết trong tức tưởi :feel_good:
 
hinh.bong.cua.may said:
mấy cái product mới toanh startup đồ cứ táng mvc mvp 3 layer vào code cho lẹ mà ra feature có users refactor sau cũng chả muộn đây cứ thích tay to ngay từ đầu xong biz méo ra gì cuối cùng project chết trong tức tưởi :feel_good:
Click to expand...
Cái đó ai cũng biết mà bác, các bác cãi nhau về vấn đề này làm gì, em đăng bài lên đề tìm xem có cao nhân nào có cách nào để có thể cân bằng không thôi, hoặc nếu áp dụng thì nên áp dụng thế nào là hợp lý. Tóm lại là minhf muốn lắng nghe anh em đã và đang apply kiến trúc này có phản hồi thề nào, nếu thấy k ổn thì đã giải quyết thế nào để mình được học hỏi thêm.
 
hinh.bong.cua.may said:
mấy cái product mới toanh startup đồ cứ táng mvc mvp 3 layer vào code cho lẹ mà ra feature có users refactor sau cũng chả muộn đây cứ thích tay to ngay từ đầu xong biz méo ra gì cuối cùng project chết trong tức tưởi :feel_good:
Click to expand...
Hay nghe thiên hạ nói có user thì refactor sau mà mình chưa bao giờ thấy cái mùa xuân đó cả lol. Sửa 1 function còn impact analysis loạn cả lên, đây đòi sửa architecture
 
midnight_sun said:
cái việc đấy là bắt buộc, clean arch thím sinh ra nhiều struct là để đúng khuôn, không cần thiết ,còn cái service kia bắt buộc phải làm như vậy, nếu không sao chạy đc, 2 cái đấy khác nhau, tất nhiên đang nói context là app có nhiều transport để trigger service , chứ còn có mỗi http thì cx chả cần, nhưng chỉ đang lấy ví dụ về mình dựa vào hệ thống trc, r ms adapt kiến trúc từ từ, chứ ko phải ngay từ đầu design 1 cục bự
Click to expand...
cảm ơn bác, em cũng nghĩ clean architecture mình k thể áp dụng rập khuôn được, quan trọng là ở bài toán của mình thì áp dụng nó ra sao cho nó phù hợp mà thôi. Dù sau thì tư tưởng của nó cũng khá là hay và cần lưu ý - "layer phía ngoài giao tiếp với layer phía trong bằng simple structure, còn layer phía trong giao tiếp với phía ngoài bằng interface".
 
The_Hermit said:
Hay nghe thiên hạ nói có user thì refactor sau mà mình chưa bao giờ thấy cái mùa xuân đó cả lol. Sửa 1 function còn impact analysis loạn cả lên, đây đòi sửa architecture
Click to expand...
cái này giống với câu chuyện của mình hiện tại, cho đến khi có được một lượng user tương đối (sau 2 năm kể từ lúc launching) thì codebase đã lớn đến mức không thể refactor lai nổi rồi. Chưa kể khi có user rồi thì ra tính năng khác để kiếm được nhiều user hơn nữa nên k có resource để refactor kiến trúc luôn. Lúc này làm rất ức chế, codee theo kiểu chắp vá vì có nhiều thứ k thể đập được nữa vì impact rất lớn.
 
Last edited:
soibac123bk said:
cái này giống với câu chuyện của mình hiện tại, cho đến khi có được một lượng user tương đối (sau 2 năm kể từ lúc launching) thì codebase đã lớn đến mức không thể refactor lai nổi rồi. Chưa kể khi có user rồi thì ra tính năng khác để kiếm được nhiều user hơn nữa nên k có resource để refactor kiến trúc luôn. Lúc này làm rất ức chế, codee theo kiểu chắp vá vì có nhiều thứ k thể đập được nữa vì impact rất lớn.
Click to expand...
Cái cách bạn nhìn nhận về Clean Architecture như vậy thì có thể coi qua Vertical Slice Architecture
 
Trần đời đi làm 8 năm, kinh qua chắc cũng 15 cái sources khác nhau ở dự án thật chưa từng thấy 1 cái sources nào gọi là clean.
Có 1 cái source mình gặp cực kì clean, ở các microservices cũng thế. Cơ mà việc phát triển features mới rất là chậm vì phải theo đúng architecture, chỉ hợp với mấy công ty mà ổn định phát triển features lâu cũng ko vấn đề gì, với lại cái sources này được dev toàn bởi các seniors dev đổ lên từ EU.
Làm càng lâu càng thấy mấy cái architectures đẻ ra concept thì rất hay, nhưng mà vào làm thực tế thì kiểu như trời với đất vậy. Nên bài toán về design phải là keep everything simple, cái này mình làm toàn với mấy thằng CTO tụi nó cũng đồng ý là cứ làm đơn giản thôi, apply những thứ cơ bản như solid, factory là được rồi, phần nào cần centralize thì tập trung nó vào 1 chỗ, cần decentralize thì tách nó ra, vừa làm vừa refactor là ok :D
Thời gian đi đọc cái đống tụi nó vẽ vời thì nên bỏ ra mà học leetcode, system design là ngon nhất. Cũng ko tự nhiên mà các công ty lớn nó tập trung vào leetcode và system design :D là những thứ nó ko thay đổi nhiều theo thời gian và là mind set của engineer, còn những thứ như architectures thì mỗi dự án lại mỗi khác tuỳ thuộc vào lifecycle của dự án, của sources.
 
Đọc cuốn này ngắn gọn dễ vào hơn. Simple/ clean/ adapt to change là khi muốn sửa thì số dòng code phải sửa là tối thiểu.


IMG_20230930_085715.jpg
 
asklyking said:
Tiki nó bán sách trên nền tảng magento đấy. Sau nó đập hẳn đi build mới luôn kìa.
Click to expand...
Được bao thằng đủ lực để làm vậy đâu. Thế nên coi việc code cho chạy được mốt refac sau như là 1 việc bình thường thì mình thấy nó khá hài
 
The_Hermit said:
Được bao thằng đủ lực để làm vậy đâu. Thế nên coi việc code cho chạy được mốt refac sau như là 1 việc bình thường thì mình thấy nó khá hài
Click to expand...
việc chạy biz trước rồi refactor hay build đẹp rồi run là trade off thôi. Chứ hầu hết ai chả thích đẹp thích hoàn hảo.
Cũng nên chấp nhận là source code chỉ clean ở 1 thời điểm và đẹp trong mắt ng ta lúc đó thôi.
 
asklyking said:
việc chạy biz trước rồi refactor hay build đẹp rồi run là trade off thôi. Chứ hầu hết ai chả thích đẹp thích hoàn hảo.
Cũng nên chấp nhận là source code chỉ clean ở 1 thời điểm và đẹp trong mắt ng ta lúc đó thôi.
Click to expand...
minh nghĩ việc cần bằng được giữa yếu code đẹp, code dễ maintain và thời gian code sẽ phản ánh được phần nào đó trrinhf độ của người lập trình viên, level càng cao thì 2 yếu tố này lại càng cân bằng hơn.
 
VD: javascript
Case 1: Gọi network bằng lib axios => import gọi thẳng axios ở khắp nơi
Case 2: Wrap axios bằng hàm sendRequest => import sendRequest gọi network

Dễ thấy khi muốn thay axios bằng thư viện khác, hoặc sửa logic catch error ... => Case 1 phải thay ở nhiều chỗ, case 2 thì chỉ sửa ở wrapper.
Case 2 sinh ra code abstract, boiler plate để wrap được axios và các trường hợp sử dụng

Đều có trade off và quyết định dùng cách nào, lúc nào chính là lý do senior khác junior
 
rongthhieng2007 said:
trc em cũng theo clean code, thời gian suy nghĩ clean như thế nào quá mẹ nó thời gian viết code :D
sau cùng bây giờ cứ viết ra function cái đã, xong xuôi rồi tối ưu sau, học mấy cái pattern cơ bản rồi áp dụng thôi, suy nghĩ nhiều nhức hết cả đầu :D
còn project to thì chia ra hết từng service con, sai service nào thì chỉnh service đó, nhanh gọn lẹ, về sau fix trên server sống cũng dễ, chứ lúc server lỗi, build lại server rồi release thì chết mẹ nó user rồi :D
Click to expand...

Mà mình nghĩ code cũng phải đảm bảo chứ nhỉ, những cái cơ bản như là chia class, magic number, constant, dtos thì nên phải có rồi chứ viết nùi nùi vô đó thì sao mà tối ưu cho nổi.

Chứ thường khi đã code xong nếu bác không tối ưu thì thằng khác vô nhiều khi nó kêu thà viết lại mới còn hơn vô sửa code :amazed:

Lí do mình nói như vậy tại vì mình mới join 1 team, ông mà build source cũng nói y chang bác, xong code thấy ghê, mà kêu vô tối ưu chỉnh logic ngồi đọc cũng mệt nói gì tối ưu.
 
telbook said:
VD: javascript
Case 1: Gọi network bằng lib axios => import gọi thẳng axios ở khắp nơi
Case 2: Wrap axios bằng hàm sendRequest => import sendRequest gọi network

Dễ thấy khi muốn thay axios bằng thư viện khác, hoặc sửa logic catch error ... => Case 1 phải thay ở nhiều chỗ, case 2 thì chỉ sửa ở wrapper.
Case 2 sinh ra code abstract, boiler plate để wrap được axios và các trường hợp sử dụng

Đều có trade off và quyết định dùng cách nào, lúc nào chính là lý do senior khác junior
Click to expand...
case 2 nhìn thế chứ cx nhiều vấn đề, ví dụ case kia dùng axios thì cái wrapper phải define nguyên lại cụm params theo axios, đến lúc đổi lib lại phải đổi params theo cái lib đó, và các đoạn code đang dùng wrapper cũ cũng phải đổi params theo, trừ khi mình tự define được các params mình luôn cần dù cho bất kì lib nào
 

Similar threads

khanhnamvn
thảo luận Sau 1 năm rưỡi làm app mình học được gì?
3 4 5
Replies
88
Views
7K
Violents
Violents
Duy1122
thảo luận [Database] Hiệu Suất Phân Trang Xâu Trong SQL Database
Replies
6
Views
565
heocon0123
heocon0123
K
tin tức FPT Software hợp tác với Creatio, thúc đẩy ứng dụng No-Code trên toàn cầu
Replies
0
Views
332
Kisuf
K
D
kiến thức Lộ trình tự học phát triển Website Fullstack - Fullstack Web Development
Replies
11
Views
1K
duykhanh471
D
ds199x
còn vozer nào 1998 mà chưa có nghề nghiệp ổn định không?
2 3
Replies
45
Views
3K
serlips
serlips

Share this page

Back
Top