Cửu Ngũ Chí Tôn
Senior Member
trước lúc có clean thì dùng cái gì?
thảo luận Clean Architecture có thật sự giúp ta code tốt hơn?
- Thread starter soibac123bk
- Start date
soibac123bk
Junior Member
xin bác cho ý kiến ạ. Bác thông chỗ này giúp em với
telbook
Senior Member
nếu input đang chạy được cho hàm sendRequest lib cũ => input là đủ để thực thi request
thì lib mới nếu cần thêm config thì chủ động thêm vào thôi (default value)
VD default config lib mới: sendRequest(oldInput:any, config = {<default_config>})
=> code cũ thì được bổ sung default config nên vẫn chạy được bằng lib mới
Hoặc dùng đồng thời 2 lib và báo deprecated cái cũ đi, migrate dần (case lib mới thay đổi quá nhiều)
VD: wrapper mới sendRequest(oldInput, useNewLib = false)
=> chỗ cũ sendRequest(oldInput) vẫn chạy
chỗ mới sendRequest(oldInput, true) => chạy code mới
midnight_sun
Senior Member
vấn đề nó nằm ở cái cách options input nữa, nếu nó same same nhau thì còn được, chứ giữa các lib khác biệt quá nhiều thì gần như bỏ
ví dụ: wrapper 1 cái hook để handle form, giả sử hiện tại là antd, cần migrate hook đó sang react-hook-form => gần như đập đi xây lại
zollback2
Senior Member
má, để tham khảo thôi chứ fence áp dụng vô hết là hỏng rồi. cái nghề của bọn mình đơn giản là cân nhắc thiệt hơn (trade off). và sau đó là đưa ra lựa chọn.
architecture nào mà mang lại value cho business, ấy là structure đúng. và ngược lại (tăng độ phức tạp, maintain burden, cognitive overhead... trong khi mang lại rất ít giá trị cho dianh nghiệp) ấy là sai
deonhodangkylanthumaynua
Member
Vậy thì tại sao sinh ra clean?trước lúc có clean thì dùng cái gì?
Clean hay Ddd, nó được dùng để đảm bảo khi chưa biết tương lai biz thế nào?
Còn nếu các bạn làm outsource, ( biz, scope đã được fix, hay rất rõ ràng)thì việc dùng ddd hay clean là k cần thiết.
deonhodangkylanthumaynua
Member
Ngoài ra, nếu bạn chưa biết, thì ddd hay clean k sinh ra để tăng perf, hay phục vụ mục đích nhiều user, tỷ người dùng.
dark_matter
Senior Member
Mấy cái cơ bản thôi, nói chung hãy code như 1 người bình thường, đừng có mà phức tạp hoá vấn đề lên, tui từng thấy 1 đứa viết cái api chọc vô database lên show lên web, mà nó viết chạy qua service, rồi từ service gọi repository, xong mapping đủ kiểutốn mất mẹ 1h trong khi nó vốn dĩ chỉ mất có 10p, không đáng, gặp tui gọi trực tiếp database xong mapping ra là ổn, chả cần gì phải phức tạp hoá vấn đề lên
Bạn cứ hiểu cái clean code nó chỉ làm cho phức tạp những cái ko cần thiết, cứ làm từ từ, xong rồi tối ưu lại, làm nhiều sẽ tự động biết clean code ntn
Simple is the best, project mới có 1 chức năng, cứ phải nghĩ ra 10 chức năng tương lai nó có làm gì cho mệt
Mình đã từng suy nghĩ viết sao cho clean code, nhưng cuối cùng thấy ko đáng tí nào, tốn thời gian, được cái thấy thoả mãn nhất thời lúc đó, mốt update mới thấy ngu, ràng buộc quá trời, lại đập đi xây lại, mẹ, đúng ngu
Nếu code outsource, client dùng đúng 1 lần rồi bỏ, hoặc POC thì không sao. Còn viết code cho product thế này thì việc bảo trì với mở rộng code là rất khó.
Simplicity là project làm đúng chức năng được defined, nếu thêm feature thì sẽ extend thêm được 1 cách dễ dàng, hoặc sửa code tối thiểu. Code như trên, nếu cần thêm chức năng business logic/data enrichment ở giữa là viết lại gần hết code, vì bạn lock chặt data flow giữa web với database, không có business service layer hay data service layer ở giữa. Thằng Dev sau làm tiếp chắc khóc thét.
Clean code là cần thiết, làm càng nhiều, maintenance càng nhiều sẽ thấy nhiều cái rất chuối mà lẽ ra nó nên được sửa ngay từ lúc bắt đầu code. Còn hiện tại tất nhiên không thể sửa hết được ngay nhưng nên rút kinh nghiệm để develop code mới tốt hơn.
Code clean mà bị xây đi đập lại nhiều chỉ có thể là sai database model thôi.
zollback2
Senior Member
tất nhiên clean code là tốt. Nhưng cần tỉnh táo để ko quá lậm vào. Clean code cũng có những upfront cost nhất định bắt mình phải pay rất nhiều trước khi thật sự nhìn ra đc kết quả của nó.
Nếu nguồn lực của cty là vô tận thì... vô tư đi, cứ làm sao cho clean nhất có thể.
Nhưng kể cả là big tech company cũng nhiều khi phải cân nhắc đặt lên đặt xuống sao cho hợp lý
https://overreacted.io/goodbye-clean-code/
dark_matter
Senior Member
1 case sai ko có nghĩa là toàn bộ clean code không tốt.
Trong trường hợp này 1 là bạn dev không hỏi ý kiến member và team lead trước khi refactor, dẫn đến mọi người không hiểu được cách làm này và cảm thấy bị "xúc phạm" và không follow hướng làm mới, 2 là không thấy đề cập đến Unit Test, Component Test với Integration Test. Thiếu 2 cái này thì bạn không thể chắc được code sau khi refactor có work như ban đầu không. Cái thứ 3 không thấy đề cập, là push trực tiếp changes lên master branch mà không có review, ngay lúc nửa đêm, điều này là tối kỵ.
Còn thực ra cách clean code không sai, ngay cả cách code trong bài viết, vẫn có thể coi là khá ổn, chỉ cần cả team support thì sau này sửa thêm behaviour vẫn được. Còn team không support, bảo tao không biết làm cách mới, thì héo là chắc vì bạn dev sửa toàn bộ flow của application.
killmytime99
Senior Member
.
Mà thấy bác đang reply dụ clean architecture hơi ngộ, bác viết code có viết unittest không? Viết tùm lum như vậy thì khó mà mock test được nên em đoán bác không viết UT
.
Thêm 1 câu hỏi nữa là bác không chia ra như vậy thì 1 file của bác bao nhiêu dòng nhỉ, nhiều khi 1 class to có khi mấy chục functions ở trong mấy ngàn dòng đúng không ? Thế nếu viết UT 1 function cho 2 cases thì tính ra cũng hơi dữ.
Cái bác đang nói là clean code hay clean architecture nhỉ, do bác nói từ clean code nên em nói về code. Cái clean code thì bắt buộc rồi không có thì code hơi ghê.Mấy cái cơ bản thôi, nói chung hãy code như 1 người bình thường, đừng có mà phức tạp hoá vấn đề lên, tui từng thấy 1 đứa viết cái api chọc vô database lên show lên web, mà nó viết chạy qua service, rồi từ service gọi repository, xong mapping đủ kiểu
Bạn cứ hiểu cái clean code nó chỉ làm cho phức tạp những cái ko cần thiết, cứ làm từ từ, xong rồi tối ưu lại, làm nhiều sẽ tự động biết clean code ntn
Simple is the best, project mới có 1 chức năng, cứ phải nghĩ ra 10 chức năng tương lai nó có làm gì cho mệt
Mình đã từng suy nghĩ viết sao cho clean code, nhưng cuối cùng thấy ko đáng tí nào, tốn thời gian, được cái thấy thoả mãn nhất thời lúc đó, mốt update mới thấy ngu, ràng buộc quá trời, lại đập đi xây lại, mẹ, đúng ngu
Mà thấy bác đang reply dụ clean architecture hơi ngộ, bác viết code có viết unittest không? Viết tùm lum như vậy thì khó mà mock test được nên em đoán bác không viết UT
.Thêm 1 câu hỏi nữa là bác không chia ra như vậy thì 1 file của bác bao nhiêu dòng nhỉ, nhiều khi 1 class to có khi mấy chục functions ở trong mấy ngàn dòng đúng không ? Thế nếu viết UT 1 function cho 2 cases thì tính ra cũng hơi dữ.
Last edited:
dark_matter
Senior Member
Bạn vẫn nhầm khái niệm clean code/clean architecture với simplicity/MVP. Thậm chí có khi bạn còn không nắm rõ SOLID principle OCP. Và khả năng cao bạn không viết test cho những gì bạn code. Vì nếu đập đi xây lại thì phải bỏ toàn bộ test code, còn nếu mở rộng thì không cần.Luôn luôn nếu thì, tự nhiên đang build function này, phải suy nghĩ cho function tương lai, cho lúc mình nghỉ việc ko ai làm đc project, tại sao ??????????????
Chả lẽ giờ mình build mỗi 1 cái chức năng print hello world, phải suy nghĩ làm sao để mốt mở rộng ra print chứ "helllo world 2" dễ dàng à
Nếu hiểu đúng clean code/architecture ngay từ đầu, sau khi setup project structure thì effort của 2 cái hầu như là tương đương. 1 cái giúp cho bạn và cho những người làm sau maintenance code tốt hơn, đây là legacy bạn để lại cho project và người sau. (Mình học được rất nhiều từ việc đọc lại những dòng code này). Còn 1 cái về sau người làm họ phải mất công đập đi xây lại và code của bạn hoàn toàn biến mất. Hoặc nếu bạn mở rộng thêm function khác thì viết clean code sẽ tiết kiệm được rất nhiều thời gian. Thế nên ngay từ đầu mình đã nói ko viết clean code chỉ phù hợp cho các dự án outsource ăn nhanh, hoặc POC. Còn làm product thì khó qua nổi vòng review code.
blanho
Junior Member
thà đừng nói, nói ra để người ta chửi nguMấy cái cơ bản thôi, nói chung hãy code như 1 người bình thường, đừng có mà phức tạp hoá vấn đề lên, tui từng thấy 1 đứa viết cái api chọc vô database lên show lên web, mà nó viết chạy qua service, rồi từ service gọi repository, xong mapping đủ kiểu
Bạn cứ hiểu cái clean code nó chỉ làm cho phức tạp những cái ko cần thiết, cứ làm từ từ, xong rồi tối ưu lại, làm nhiều sẽ tự động biết clean code ntn
Simple is the best, project mới có 1 chức năng, cứ phải nghĩ ra 10 chức năng tương lai nó có làm gì cho mệt
Mình đã từng suy nghĩ viết sao cho clean code, nhưng cuối cùng thấy ko đáng tí nào, tốn thời gian, được cái thấy thoả mãn nhất thời lúc đó, mốt update mới thấy ngu, ràng buộc quá trời, lại đập đi xây lại, mẹ, đúng ngu
killmytime99
Senior Member
vãi)) thật mấy bác hỏi mấy câu em cũng bó tay luôn ấy
ủa chứ dev ko biết test thì sao mà hệ thống chạy, hay là dev code 1 phát là hệ thông nó chạy ko lỗi, rồi còn cả 1 đống tester phía sau làm cái gì
em cũng chán chả muốn trình bày làm gì, cái mock test của bác, nó là 1 cái cực kì cực kì đơn giản, bn cách để làm, chả hiểu bác đang muốn nhấn mạnh cái gì, clean code để test cho dễ à
chắc bác nghĩ cái unit test là cái gì cao siêu lắm, em nói thật có cái em sài, có cái em chả sài làm gì, em đố bác test được mấy bug liên quan tới thread nhờ unit test đấy
Chứ em hỏi giờ khách nó cần cái web để login, và nó chỉ thấy cái web có login đc hay ko, login nhanh hay chậm, chứ ko phải là cái web, cấu trúc nó đẹp thế nào, code dễ hiểu ra làm sao
vl
)) clean code ý nói code clean.Còn cái clean architecture em đang hỏi bác là 1 file bác dài bao nhiêu, và bác mock tụi dependencies để test đồ k ? Và bác kêu viết chung thì 1 file nó dài nên hỏi là file UT của bác có dài luôn không ?
Còn mấy cái test kia liên quan gì, bác đang phản biện mà không ăn nhập cái gì cả,
dark_matter
Senior Member
1 sản phẩm muốn tồn tại lâu dài nhất định phải code clean, chỉ là làm trước thì sau này đỡ mệt lẫn thời gian refactor. Nếu bạn rush cho project thì sau này sẽ vẫn phải refactor lại (technical debt).quá tập trung clean code, làm tốn thời gian release sản phầm, chưa biết sản phầm có đc đón nhận hay không nhưng mất quá nhiều thời gian để phát triển, vs mục đích là dễ bảo trì về sau
Thường thì 1 project dùng 80% để làm feature mới (JIRA bên Development board), 20% để refactor (JIRA bên Kanban board chẳng hạn).
Mình cũng ko định reply nhưng post của bạn có technical debt (từ web query thẳng database) nên mình phản biện để tránh mọi người hiểu sai.
https://stackoverflow.blog/2021/10/...sses-bottom-lines-and-empathetic-programmers/
killmytime99
Senior Member
Bác nói như kiểu bác đang làm productvấn đề là bác clean code làm cái gì
cái việc test đó, là cái cực kì đơn giản trong lập trình, bác cần em test cái gì, mà phải clean code mới làm đc
chí phí nhân lực, thời gian hoàn thành, lợi nhuận thu lại, hay bác viết hệ thống vì đam mê
mà thôi nói với mấy bác chắc suy nghĩ khác nhau, chả đc cái gì cả
)) mà em không nghĩ 1 product thì code như bác nói 
Hoặc không rõ product bác đang nói là kiểu nào ))Em làm outsource thôi, client thì product họ cũng vừa phải mà thấy code người ta đàng hoàng, lúc build source đầu người ta còn phân chia rõ ràng code từ năm 2017 mặc dù legacy mà nhìn vô vẫn học hỏi được.
The_Hermit
Senior Member
Thế đặt lại câu hỏi là cái product của bạn nó chỉ đơn giản có thế thoi hay sao? Và code xong là deliver luôn, biz ko phát triển, ko thêm tính năng?thật, nói chuyện với mấy bác, em chán quá, toàn lý thuyết xuông
thế bây giờ 1 cái function đơn giản nhất quả đất, login, check user, pwd vào web đi, căn bản nhất quả đất, cho thêm cái function đăng kí cho luôn 1 cặp, rồi thế làm chọc thẳng từ database lên làm cho nhanh, mất 10p xong function, hay là mất 30p ngồi viết services, repo, rồi DI để xong
Có 1 chuyện là code của bạn sẽ có thể là ref cho người khác trong team. Tao thấy thằng này nó chọt thẳng DB lấy data xài luôn, chắc convention project cho, tao chơi vậy luôn!!! Rồi technical debt lâu dài tích lũy thì chỉ có đập đi xây lại.
soibac123bk
Junior Member
có thể bác hơi xem nhẹ việc viết unittest , nhưng ở mô số nơi thì viêc viết test là bắt buộc, nếu không chi phí fix bug vặt có khi còn nhiềuu hơn cả việc bác viết test ngay từ đầu, hơn nữa bác còn kéo theo công việc của những người khác (ví dụ QC, ...) vì họ phải tìm ra bugs để bác fix.vấn đề là bác clean code làm cái gì
cái việc test đó, là cái cực kì đơn giản trong lập trình, bác cần em test cái gì, mà phải clean code mới làm đc
chí phí nhân lực, thời gian hoàn thành, lợi nhuận thu lại, hay bác viết hệ thống vì đam mê
mà thôi nói với mấy bác chắc suy nghĩ khác nhau, chả đc cái gì cả
việc bác viết tất cả vào một function như vậy rất khó viết test, và bác sẽ không bắt được hết case để test được, vì khi bác chia thành function nhỏ, thì bác dễ nhìn thấy hết số case để test còn với 1 function lớn thì rất khó. Hơn nữa viết unittest function nhỏ sẽ dễ dàng hơn nhiều so với function lớn.
Còn nữa nếu bác query trong db thẳng thì bác mock test kiểu gì được, ít nhất phải chia hàm ra chứ?
Em thấy ý của bác không sai, chỉ có điều bác là người hướng tư duy sản phẩm ra nhanh nhất có thể để ra nhanh và fail cũng nhanh, trong khi những người khác thì thuần technical hơn và muốn build cái gì đó để lâu dài hơn. Tuỳ trường hơp mà lối tư duy nào sẽ phát huy hiệu quả. Cảm ơn bác đã tham gia đóng góp ý kiến vào thread của em
midnight_sun
Senior Member
thế bây giờ tình huống project của e việc login, register, không chỉ gọi qua http, mà còn gọi qua grpc, consumer kafka,.. như vậy là sẽ duplicate logic ở cả 3 cái transport này phải kothật, nói chuyện với mấy bác, em chán quá, toàn lý thuyết xuông
thế bây giờ 1 cái function đơn giản nhất quả đất, login, check user, pwd vào web đi, căn bản nhất quả đất, cho thêm cái function đăng kí cho luôn 1 cặp, rồi thế làm chọc thẳng từ database lên làm cho nhanh, mất 10p xong function, hay là mất 30p ngồi viết services, repo, rồi DI để xong
telbook
Senior Member
Bác trên chắc chỉ chạy vế đầu. Ban đầu chạy nhanh ok đấy, không bảo trì, vận hành, mở rộng gì thì đúng là không cần clean làm gì, còn chả cần architecture gì luôn.
Càng chạy dài càng thấy clean code quan trọng.
Càng làm nhiều dự án thì càng thấy architecture quan trọng.
Code abtract từ dự án này đẩy sang dự án khác, cứ gặp pattern là ốp vào. Gọn nhẹ dễ vận hành, bảo trì, phối hợp với dev khác.
Còn thích ngày mai cũng như hôm này, project mới cũng bắt đầu từ trang giấy trắng thì không cần clean code, architecture gì hết
Similar threads
