Những phần mềm phức tạp lại chia đơn giản. Còn mấy cái như thớt thì chia phức tạp. Mà chức năng nào cũng chia theo repository, model, entity, service, controller các thứ. Cũng tùy vì không phải phần mềm web nào cũng làm vậy và cách làm đó lại khá cứng nhắc.
Chia chương trình thành nhiều hàm nhỏ để tăng tính single responsibility + reuse.
6k loc là chỉ 1 người viết thôi, những người khác chỉ fix bug, nên không có chuyện conflict.
CRUD mà.
Có thể nói mấy cái web chắc 99% chủ yếu là crud. Nâng cao hơn nữa thì kết nối api đến bên thanh toán hay google fb. Thực sự mà nói áp đống repo, service vào khác gì dùng nuke để giết gà con đâu.
Đấy là anh nghĩ vậy thôiLập luận logic là hơi kém à nha.
Giờ có 2 bảng: User và Order --> Có 2 repo UserRepo và OrderRepo.
Chắc chắn có 1 query liên quan tới cả User và Order, cứ gọi nó là 1 join query nhé.
Câu query này bảo đặt ở đâu cũng được phải ko nhỉ? Giờ đặt tạm ở UserRepo nhé.
Xong rồi trong OrderService cũng cần câu query ấy (logic rất thường gặp phải không nào?) thì lại phải invoke thằng UserRepo à? Thế thì làm sao còn đảm bảo tính 1 - 1 nữa
Tại sao anh không nghĩ đến việc sẽ có một repo khác handle những câu query kiểu liên quan đến cả 2 bảng user và order nhỉ. Ví dụ như UserOrdersJoinedRepo chẳng hạn (ví dụ nên bỏ qua tính đúng đắn của tên class đi nhé ). Vẫn đảm bảo"repo xử lý table", vừa đảm bảo luôn cả single responsibility nhé .Đã nói ở trên nhé
Ông dùng pull/merge request bao giờ chưa. Ông master chỉ review rồi merge vào thôi mà có phải fix gì đâu. Ông mà phải fix conflict là ông dev fix bug kia ấy chứ
Hờ tớ 10 năm exp, hiện đang lead team 7 người và quản lí 15 cái source base của 1 start up nhé. Bạn muốn chia sẻ kinh nghiệm gì với tớ cứ chia sẻ lên đây thôi
Việc merge source code của member trong team một ngày t phải làm không dưới 10 lần đâufile của anh nhiều người cùng thêm feature thì dễ conflict là đúng rồi. còn file của người ta chỉ có 1 người code feature, những người khác fix bug thì thêm unit test rồi tạo pull request, ông master chỉ việc merge, nên sẽ không có chuyện conflict.
nghe nói là bạn làm php, php mà quản lý tốt như thế cũng đáng nể đấyHờ tớ 10 năm exp, hiện đang lead team 7 người và quản lí 15 cái source base của 1 start up nhé. Bạn muốn chia sẻ kinh nghiệm gì với tớ cứ chia sẻ lên đây thôi
Làm start up thực ra mỗi thứ 1 tí. Devops,front end,backend thậm chí có cả bê máy chủ lên viettel idc để lắp đặt nữa cơnghe nói là bạn làm php, php mà quản lý tốt như thế cũng đáng nể đấy
My 2 cents:
kek làm startup thì ai chả làm wholestack. cơ mà php muốn làm ngon thì cần kỷ luật khá cao, tôi thấy nể thì vào khen thôi có gì đâu.Làm start up thực ra mỗi thứ 1 tí. Devops,front end,backend thậm chí có cả bê máy chủ lên viettel idc để lắp đặt nữa cơ
Nói về php thì ông nào chê thì chê chứ t thấy vẫn ok, quan trọng là nó giải quyết đc bài toán thôi. Php hồi xưa thì lởm chứ version 7 có static type là scale ngon lành rồi
Tại vì anh không bắt chia nhỏ file ra nên dev mới phải suốt ngày đi resolve conflicts thì cóHờ tớ 10 năm exp, hiện đang lead team 7 người và quản lí 15 cái source base của 1 start up nhé. Bạn muốn chia sẻ kinh nghiệm gì với tớ cứ chia sẻ lên đây thôi
repo trả về full entity thì code bác chưa tối ưu rồi, muốn lấy gì select cái đó thôi chứ
Anh phải phân biệt đc merge source code và resolve conflict chứ. Merge source thì ông lead nào chả phải làm hàng ngàyTại vì anh không chia nhỏ file ra nên mới phải suốt ngày đi resolve conflicts thì có
Anh phải nghĩ là "không nên để xảy ra việc conflict" (risk0 gần bằng 0) thay vì "xử lý việc conflict không khó" (risk1 > risk0) chứ
)
setter injection thì chấp hết những cái circular luônđúng rồi đó bác, nó đi inject circular luôn rồi
), team công ty cũ của t còn dùng 4-5 layer thay vì 3 layer như của ông đang nói đấy )
Giờ ví dụ như vầy. UserRepo. GetUserById.
Xin lỗi tôi nói thiếu.Anh phải phân biệt đc merge source code và resolve conflict chứ. Merge source thì ông lead nào chả phải làm hàng ngày
Tại vì anh không bắt chia nhỏ file ra nên dev mới phải suốt ngày đi resolve conflicts thì có
Anh phải nghĩ là "không nên để xảy ra việc conflict" (risk0 gần bằng 0) thay vì "xử lý việc conflict không khó" (risk1 > risk0) chứ
Anh không vứt toàn bộ feature vào 1file là tôi mừng cho dev của anh
Resolve conflicts là việc của dev, nhưng take risk lại là việc của anh
