Ai tìm đc trong cmt của tôi, tôi nói tôi code ko cần clean code, tôi pay thẳng 100 củ
Vấn đề ở đây tôi muốn nói, clean code nó chả là cái quái gì to tát cả, hệ thống tròn méo chưa biết ra sao bày đặt clean code, làm ảnh hưởng tới thời gian release sản phẩm, cái tôi muốn nói là mấy ông luôn làm mọi thứ phức tạp, trong khi mọi thứ thực sự đơn giản
Vâng, tôi thấy mấy ông thực sự chả biết cái quái gì về clean code cả, học nhiều đi tắm cũng cởi chuồng thôi
luôn luôn xáo rỗng mọi thứ, trong khi chất lượng sản phẩm mới là cái kết quả cuối cùng
Đúng là trình newbie, luôn thích phức tạp mọi thứ lên
Những cái b nói đúng nhưng mà chưa đủ đâu, việc force clean code nó còn tuỳ thuộc vào Cty và giai đoạn,
Đối với nhiều Cty, đặc biệt là startup hoặc trong giai đoạn làm MVP, thì đúng là thời gian release sản phầm là quan trọng,
Nhưng trong môi trường enterprise mà mọi ng đề cập phần lớn là những Cty đã đi qua giai đoạn trên rồi, cái họ cần là sự ổn định nhiều hơn, lúc này clean code là khá quan trọng, vì nó cần cho sự ổn định của team, của SP.
B ko clean code, ok, lúc b còn làm trong Cty, b có thể dễ dàng maintain, update chỗ code đấy của chính b vì b biết hết những hidden logic trong quá trình b tham gia phát triển SP.
nhưng nếu t là ng quản lí của b, trong môi trường enterprise, t sẽ ko cho phép b làm thế,
vì 1. b có thể nhày việc bất cứ lúc nào, ng nhận maintain dự án sau b sẽ rất khó takeover lại, vì phong cách code mỗi ng khác nhau, nếu ko có qui chuẩn, thì ng sau sẽ rất khó follow.
2. kể cả trong TH b vẫn còn làm trong Cty, thì nếu CV của b đang bị overload, thì sẽ rất khó để chia sẻ workload của b cho 1 team member khác, vì ng đó sẽ gặp phải vấn đề như trên.
3. Seniority của các team member là khác nhau, khi b phải review code của fresher/ junior, việc ko có clean code sẽ là 1 cực hình, vì rất nhiều bạn có xu hướng viết code all in one, việc ko bóc tách các layer/logic sẽ làm b khó follow và verify cũng như phát hiện hidden issue.
Thêm nữa việc 1 project cả trăm ng tham gia không hề hiếm nhé,
Các Cty mà legacy project theo mô hình monolithic hoặc Cty làm super app thì phần lớn đêù có 1 repo mà có hàng trăm ng contribute vào,
Cty 10 năm trc và Cty gần nhất của t đều làm theo mô hình này.
tất nhiên về mặt feature sẽ chia nhỏ team size, cố gắng để các team làm việc song song và ko ảnh hưởng đến nhau,
nhưng việc conflict/ hoặc luân chuyển nội bộ khi các team giải tán/ sát nhập là không thể tránh khỏi, nên việc duy trì 1 cái qui chuẩn cho cả trăm dev khá quan trọng đấy.