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

tôi tối ưu code lại, cái gì dùng chung bỏ gộp vào, tạo các extension, utils ra để sài, thích thì sài thêm DI nếu cần thiết, mọi bước clean code các ông nói, tôi nắm nó từ 4 5 năm trc, tới giờ tôi vẫn xem qua các pattern mới :D
đấy có vậy thôi, code => hoàn thiện => tối ưu => code => hoàn thiện => tối ưu, chả có cái gì phức tạp, tôi nói rồi, đừng có phức tạp hoá mới thứ lên :D
tối ưu code như bác nói thì là nhóm code vào 1 chỗ, hay tách ra gì đó, đại loại vậy đúng ko, vậy làm sao để sau khi làm như bác thì hệ thống có thể chạy ổn định, effort cho việc kiểm tra đó như nào, và effort cho việc clean đó như nào nữa bác :p:p
 
thôi thôi cút cút, thằng như mày tao ko tiếp, kiến thức ko lôi ra, thích chửi bới thì cút :D
tao đi làm tiền tao kiếm cả trăm, tao già trâu, ếch ngồi đáy giếng nhưng khách tao cả trăm khác rả khắp cái vn này, tao làm ra tiền từ lập trình, giờ thích so tiền hay kiến thức lập trình, tao so vs mày hết :D
Làm được cả trăm triệu mà tự khen to thì đúng là ếch ngồi đáy giếng thật :sweat: chửi người khác được người khác chửi lại thì dựng đứng cả lên ko là già trâu thì là gì fence :shame:

via theNEXTvoz for iPhone
 
thôi ông đừng bắt bẻ câu chứ làm gì, hệ thống chạy ổn định hay không, là phải dùng tool đo lường, sử dụng log để tracking, chứ del phải từ ba cái clean code ông nói, ông clean code mà không có tí log nào trong code xem ông tracking đc lỗi hay không, ông clean code xong ông đo đc hệ thống ông chịu tải đc bao nhiêu à :D
tôi nói rồi, mấy ông luôn phức tạp hoá vấn đề lên làm gì :D
bác nhạy cảm z :beat_brick: như bác nói thì giai đoạn sau của bác là sửa code, sửa code thì đồng nghĩa với việc phải test lại các chức năng cũ, thì e hỏi effort dành ra cho việc đấy là thế nào thôi mà
 
thôi ông ơi, tôi biết mẹ cái mánh ông hỏi tôi làm gì rồi :D
tôi hỏi ông, ông clean code xong, project phát triển thì ông có phải clean code lại hay không :D
ông cứ phải rườm rà làm gì, có tinh thần học hỏi thì tôi tiếp, còn thích hỏi móc họng thì tiễn :D
ông chắc ko nghe câu, nếu nó chưa hỏng thì đừng có sửa :D simple is the best :D
e nghe bác nói thì ko thấy đề cập đến giai đoạn refactor, clean code nhiều, mà bác chỉ nói về giai đoạn đầu, thì e mới tò mò giai đoạn sau bác làm gì thôi, vì hầu như mọi người đều phải maintain/refactor , thì lúc làm cái đấy phải tự chạy lại các chức năng để đảm bảo nó chạy đúng, mình sửa không bị sai thôi
 
Tạm tổng kết lại là có 3 track: mmo/freelance, outsource và product.

Có thể bên mmo, code cho client không cần clean code + test.

Nhưng làm outsource nên chú ý đến vấn đề này.

Còn product là bắt buộc. Bạn rush release sớm nhưng 1 khi có lỗi production thì reputation risk của cty sẽ lớn hơn rất nhiều so với thời gian viết code.

Nếu làm mmo như trên thì mình có thể hiểu tại sao mmo khó quay lại code bình thường. Có 1-2 topic như thế ở Voz. (Mình sẽ không ngạc nhiên nếu mmo bảo học cấu trúc dữ liệu và giải thuật là dư thừa, competitive programming is a waste of time, hoặc bỏ luôn ngành cntt ở đại học, học youtube tutorial là đủ ;)).

Đóng topic được rồi khỏi cãi nhau :LOL:.
 
trong hợp đồng của project có chữ SOLID hoặc architecture có SOLID, thì đó là cái phải theo. kể cả việc code coverage, ví dụ 70% mới dc lên test env, hoặc QA ko test thì có cl mà lên dc prod env

dead line là thứ giết chết tất cả, my fen cần cứng rắn để bảo vệ quan điểm

mấy thằng senior architect nó cũng chỉ hơn ông senior dev chỗ này: bảo vệ quan điểm, phần lớn là giải thích được 1 cách hợp lý, hoặc thằng cùn thì nó bảo tao chốt thế

Đồng quan điểm với bác, quan trọng nhất bất kể hoàn cảnh thì phần core cũng phải cứng rắn và bảo vệ được quan điểm của mình. Chỉ cần đưa project chạy được 1 time theo setup đã chốt thì từ từ các task đều được estimate dựa trên chính thời gian build trên cái setup đó -> thành cái khuôn
zFNuZTA.png
....
 
tóm lại là mấy ông bớt nghĩ mấy cái viễn tưởng lại, tập trung vào chất lượng sản phẩm, del mẹ thấy mấy ông viết code còn hơn là phật sống :D
làm việc không có QA, không test mà cứ nói là tập trung vào chất lượng sản phẩm, chất lượng này là cái trình độ code không bao giờ có lỗi của bác à.
Xong cứ bô bô là chạy dự án nhanh, tôi kiếm được tiền nên tôi là đúng. Vì có quan tâm code sau này nó như nào đâu mà chả vậy. Làm xong job là bấm nút biến rồi. Tiền giờ dễ kiếm quá :sneaky:
 
Cho hỏi bác @rongthhieng2007 thường code các dự án như thế nào, team size bao nhiêu, dev trong bao lâu, và bác dành bao lâu để upgrade/maintain thêm.
Vì lợi ích khi apply clean code/arch chỉ thể hiện rõ khi project quy mô lớn, project bình thường thì làm simple vẫn được. Giống như mấy bài giải thuật, nó quá đơn giản để chia function, viết hết code trong main vẫn chẳng sao.
 
À Thoughtworks nổi tiếng về design pattern với outsource mà. Chỉ ko biết chi nhánh vn làm ăn thế nào thôi. Mình fail interview cty này bên Singapore 4-5 năm trước. Giờ vẫn cay :D
TW e app vào bị từ chối liền :cry:. Bác fail role gì nhỉ :p
 
6AdRbcF.png

Thôi anh @rongthhieng2007 lo đi trang bị kiến thức chứ ko sau già rồi không làm freelancer, ko kiếm được việc fulltime thì khổ ra :sweat:
Đi xin việc bị mấy thằng trẻ trẻ phỏng vấn vô nó hỏi solid thì lại khổ. Chứ tôi ở Mỹ rồi làm biếng vật nhau đọ tiền với anh quá, qua làm culi tư bản lo trả bill chết mẹ rồi :shame:

via theNEXTvoz for iPhone
 
team tôi chỉ có 5 người, tuỳ mức độ dự án mà chia ra, nhẹ thì 1 mình tôi cân, nặng thì thuê thêm outsource bên ngoài :D
quy trình thì cứ tư vấn khách => chốt cọc => báo kế hoạch cho team => code => demo sản phầm cho khách => lại lên kế hoạch code => code => demo cho khách. cứ thế lặp lại, dm giờ kêu 3 ngày xong cái login, tới hôm đó function ko xong thì ăn cứt cả đám hết chứ ở đó mà bảo trì về sau :D

mấy ông cứ kêu phải clean code thì mới làm đc project quy mô lớn, tôi đó mấy ông lúc bắt đầu phát triển project biết nó lớn tới mức nào đấy, clean code kiểu gì, giờ ví dụ cái hệ thống facebook, ông clean code kiểu gì lúc project mới bắt đầu :D
chắc gì cái project của ông nó sẽ phát triển tới mức đó, tôi nói rồi, source code nó sẽ phát triển cùng project, giống như đứa trẻ mới biết bò rồi mới biết đi, đừng có làm phức tạp các vấn đè nó vốn dĩ đơn giản, mọi thứ phải theo yêu cầu đề ra của khách hàng, đừng tự lấy mình làm trung tâm :D ông viết code có clean đến thế nào mà tốn quá nhiều thời gian release thì cũng vô dụng, chỉ mình ông thủ dâm tinh thân là mình viết code giỏi hơn người khác :D
close topic đc rồi, context khác hẳn nhau, các ông ở trên đều đang làm ở sản phẩm đã phát triển, và đang develop/maintain trên sản phẩm đó, còn của ô là phát triển mới từ đầu, và team size ko quá lớn, với những thứ như vậy thì mindset rõ ràng là quá khác nhau r, mà đã khác nhau vậy thì cãi nhau đến tết cũng chả xong
 
tôi lôi cmt tôi ra có cmt nào tôi nói ko cần test, tôi cho ông 100tr :D
bốc cứt thì tự ăn đi chứ, đâu phải ai cũng có thói quen ăn cứt như mấy ông
#147
sửa cả cái cấu trúc project tôi làm ra cũng del lỗi đc
test trong dev, nó cũng như sống cần hít thở không khi vậy, del ai đi lôi cái việc hít thở đc không khí ra để tự hào cả :D
Test của bác chắc là manual test đúng không, hay người khác viết test cho bác.
Không có auto test mà tự tin sửa cấu trúc cả project thì cũng pro đấy.
Rồi bác muốn nói deadline dí sát nên test manual cho qua còn đi demo đúng không. Rồi trong quy trình làm việc đó có giai đoạn nào cho viết test/refactor/tối ưu code. Deadline liên tục nên bỏ qua test luôn đúng không, hít thở cái là test xong?
Đúng bệnh kinh niên của Freelancer ăn xổi, xong rồi cứ lấy tiền ra khè, ăn nói thì 2 câu phải 1 câu chửi.
 
toàn nhét chữ vào mồm thế này bảo sao trình độ lập trình cũng như hạch :D
tôi nói rồi, xong function tối ưu sau, clean code là 1 phần trong dev, nhưng đừng thần thánh hoá như kiểu bí kíp, tôi del bao giờ kêu ko cần clean code cả, nhưng có hay không nó phải phù hợp :D
tôi cũng nói luôn là mấy anh nên chú trọng vào function, thuật toán, vào log, vào hiệu xuất, cách xử lý dữ liệu, tôi del bao giờ kêu mấy cái này là dư thừa cả, đừng tự cầm cứt rồi nhét vào mồm tôi :D
trong comment của tôi, có cái nào tôi kêu ko cần quan tâm tới thuật toán, tới cấu trúc dữ liệu cứ lôi ra được, tôi sẫn sàng pay ngay 100tr cho người đó :D

sau cùng tôi nói luôn, mấy ông còn chia ra 3 mảng thì tôi thấy mấy ông chả biết cái quái gì về lập trình cả, chắc thằng mmo, hệ thống của nó viết bằng ngôn ngữ ngoài hành tinh ấy, còn product thì viết bằng ngôn ngữ con người à :D del mẹ, nó cũng chỉ là hệ thống vs mục đích hoạt động khác nhau, chả có cái nào cao siêu hơn cái nào :D

tóm lại là mấy ông bớt nghĩ mấy cái viễn tưởng lại, tập trung vào chất lượng sản phẩm, del mẹ thấy mấy ông viết code còn hơn là phật sống :D

à mà tôi nói luôn, cái ông nói khả năng fix lỗi của product, ko phải nhờ cái clean code nhà ông mà mới fix đc lỗi, nó nhờ vào log, khả năng tracking lỗi ông ạ, cái này nó liên quan tới trình độ dev nhiều hơn là cái mớ clean code nhà ông :D

tôi đến lạy trình độ của mấy ông, nhờ clean code fix lỗi, dễ test :D ôi vãi đạn, tiền kiếm đc cũng ít, mà kiến thức cũng chả hơn ai :D sợ thật :D
Mình ko tiện nói về tiền nong hay cty nhưng IT lương 150m (giả sử vậy) của bạn chỉ hơn fresh bên mình 1 xíu thôi, đây là tính năm ngoái :LOL:. (Hơi khập khiễng tí vì mình ko base ở Vn) Mà các bạn fresh còn phải training 2 năm mới cứng được. Mà lương chả liên quan đến code design nên đừng mang ra khoe.

Ngay cái việc web query thẳng qua database là 1 big red flag.
Sau đấy là bạn trả lời lung tung giữa các Testing type với khăng khăng nhìn code là biết đúng, ko cần test nên ăn gạch thôi.

Test là để bắt lỗi ngay từ khi develop và qa, sau đấy loại trừ dần và khi có lỗi trên production thì biết ngay nó không nằm ở đâu. Nhiều lỗi nó là business logic chứ ko phải dạng exception, tốt nhất nên test hết trước khi release.

Còn chờ có bug trên production rồi nhìn log và sửa thì sẽ mất nhiều thời gian hơn. Chỉ cần 10’ ko nhìn ra lỗi là bên mình mất số tiền tương đương với 150m của bạn rồi. Ngồi đấy mà đọc log :LOL:.
 
ok, close thôi, nhìn lũ sinh viên mới ra trường đi làm, biết cái clean code mà cứ như biết đc bí kíp gia truyền buồn cười vãi :D
quan trọng nhất vẫn là chất lượng sản phẩm, ông phát triển sản phẩm của ông, họ phát triển sản phẩm của họ, mỗi context có cách khác nhau để đảm bảo chất lượng, nên đừng phán xét nhau như vậy làm gì
 
Kiến trúc nào mà dễ unit test / integration test nhất thì dùng. Thường nó sẽ nghiêng về hướng của clean architecture.
Mọi người mình thấy thường rất under estimate thời gian để debug.
Chịu khó vượt qua được bước đầu khi dùng automation test xong sẽ thấy code nhanh hơn nhiều.
Vì có thể code đến đâu refactor ngay đến đó. Đặc biệt những thuật toán phức tạp nhiều edge case.

Refactor liên tục làm mình hiểu bài toán với hiểu thuật toán hơn nhiều. Cũng ít bug đi hẳn so với hồi trước khi làm auto test.

Làm xong feature nào là feature đó chạy ngon rất hiếm khi phải quay lại fix bug, feature thêm liên tục đều đều.

Nếu làm những cái lên quan đến scanning / parsing hay về compiler nói chung sẽ thấy auto test đủ các tầng là điều tối quan trọng
 
team tôi chỉ có 5 người, tuỳ mức độ dự án mà chia ra, nhẹ thì 1 mình tôi cân, nặng thì thuê thêm outsource bên ngoài :D
quy trình thì cứ tư vấn khách => chốt cọc => báo kế hoạch cho team => code => demo sản phầm cho khách => lại lên kế hoạch code => code => demo cho khách. cứ thế lặp lại, dm giờ kêu 3 ngày xong cái login, tới hôm đó function ko xong thì ăn cứt cả đám hết chứ ở đó mà bảo trì về sau :D

mấy ông cứ kêu phải clean code thì mới làm đc project quy mô lớn, tôi đó mấy ông lúc bắt đầu phát triển project biết nó lớn tới mức nào đấy, clean code kiểu gì, giờ ví dụ cái hệ thống facebook, ông clean code kiểu gì lúc project mới bắt đầu :D
mà chắc gì cái project của ông nó sẽ phát triển tới mức đó, tôi nói rồi, source code nó sẽ phát triển cùng project, giống như đứa trẻ mới biết bò rồi mới biết đi, đừng có làm phức tạp các vấn đè nó vốn dĩ đơn giản, mọi thứ phải theo yêu cầu đề ra của khách hàng, đừng tự lấy mình làm trung tâm :D ông viết code có clean đến thế nào mà tốn quá nhiều thời gian release thì cũng vô dụng, chỉ mình ông thủ dâm tinh thân là mình viết code giỏi hơn người khác :D
Có thể vì anh chưa đủ trình để apply clean code thôi. Là chưa đủ nên tích lũy kinh nghiệm nhiều sẽ thấy thế nào là clean code từ đầu.
Facebook là ví dụ vớ vẩn ở đây. Facebook đẻ ra không phải là product lớn.

Cái cách làm của anh cũng chả phải mới mẻ trong nghành pm, nhưng anh cần biết ưu và nhược nhé ( và điều kiện để apply kiểu làm việc đó ). Không phải người ta không biết đâu anh. :)
 
tôi nói rất nhiều lần cái test là cái căn bản nhất trong dev, thật tại sao nhiều ông cứ nghĩ phải clean code mới test dễ vậy, viết 1 script test mất bn thời gian, xong chỉ việc chạy script biết đúng hay sai liền, liên quan mẹ gì tới clean code hay ko :D
vấn đề chỉ có là clean code là việc bình thường làm sau khi xong function, chả có cái quái gì cao siêu cả, mấy ông trong này cứ kiểu như lụm đc bí kíp, cái del gì cũng clean code, đơn giản ko thích cứ thích phức tạp :D
sợ thật :D
thời đại automation đầy ra đó, đến cả code hỏi chatgpt nó còn quẳng luôn vào mặt, còn trong đây coi clean code như là bảo vật gia truyền, phải làm theo, ko làm là ko được, vãi cả đái :D
Đôi khi bạn xài framework nhiều rồi, tiếp cận code tốt, code theo community convention từ đầu. Bạn chưa thấy được những convention hay framework đó nó đã giúp bạn điều gì và nó được implement như thế nào nên bạn nghĩ nó không phức tạp như vậy.
Bạn thử pick một ngôn ngữ, không xài framework và code một cái project theo ý bạn mà có khoảng 3 ông khác code chung. Nghĩ thử bạn làm thế nào.

Những cái thứ bạn tưởng bình thường đó là có người thiết kế cho bạn đó. Và chắc chắn là nó clean.

Tôi thấy là bạn im lặng đi để cao nhân khác nếu người ta lên tiếng nói chuyện. Bạn với anh kia toxic quá. Riết ng ta ko muốn chia sẻ.
 
Xin mọi người hãy đừng reply bình luận của ổng nữa. Em lập ra thread để hóng ý kiến từ các bạn, các cao nhân để anh em cùng học hỏi. Ý kiến nào anh em cũng lắng nghe nhưng đừng đẩy nó đi đến chỗ toxic. Anh em im lặng để các cao nhân họ còn vào cho ý kiến.
 
Back
Top