thảo luận [Chuyện trò linh tinh - Box CNTT]

AnhLaAiZay said:
Chào các tiền bối, em là coder mới vào nghề, các tiền bối cho em xin kinh nghiệm để code sao cho ít bug, hoặc kinh nghiệm để fix bug mà không lòi ra bug khác với ạ, bị teamlead chê khiến em cảm thấy rất buồn và chán nản , không biết hồi mới đi làm các bác có bị tình trạng như em không ạ chứ giờ nghĩ lại lời teamlead nói em thấy buồn quá
Click to expand...

Bug là bình thường. Nhưng thái độ và hành động sau đó sẽ tạo ra khác biệt.

1) Có lặp lại bug giống như vậy nữa không?
2) Có tìm cách để ngăn bug tương tự có thể xảy ra trong tương lai không?
2.1) Nên tìm hiểu về các linting tool
2.2) Có check list cho mình: ví dụ
  • FE: có bind event thì phải nhớ unbind khi component unmount
  • BE: thêm query chỗ nào thì check lại có cần index không? Nếu không index có bị chậm không...
3) Chịu khó học học và học, để biết best practice chỗ này nên làm thế nào? Code review để coi anh em người ta xử lý cái tương tự ra sao?...
4) Test kỹ vào, cái chú Junior hay có kiểu code và đẩy ticket thật nhanh, chậm lại, tự review code của mình, tự nghĩ xem mình code vầy dễ hiểu ko? Đã cover hết dc các case trong AC chưa?...
Code nhanh chỉ có giá trị khi nó là code tốt và ít/không bug.

Gửi từ Samsung SM-F936B bằng vozFApp
 
AnhLaAiZay said:
Cái project em đang làm là viết cho nội bộ nên không viết unit test để giảm thời gian phát triển ấy bác , nhiều khi sửa bug này xong nó lại lòi ra bug ở chỗ khác
Click to expand...
Thật ra viết nhiều unit test quen rồi thì viết code cho nó testable thôi, sau quay lại viết unit test cũng được.
 
ai biết chỉ mình với nhé. đã tìm trên stackoverflow nhưng vẫn chưa ra
1693454321531.png

System.out.println("role user::: " + authentication.getAuthorities()); //role user::: [ROLE_USER]
nhưng admin vẫn có thể thực hiện request được

1693455619582.png
 

Attachments

  • 1693455422202.png
    1693455422202.png
    28.2 KB · Views: 25
Last edited:
cool-girl said:
Tất cả dự án mình làm thì phải commit là coverage at least 80%. Không có thời gian viết là không biết viết hoặc triển khai code ngu nên không viết xuể. Code không UT khác gì rác.
Click to expand...
Code rác là sản phẩm unusable.
Coverage 80% không đồng nghĩa là sản phẩm sẽ sử dụng được.

Bật mí cho bác biết là rất nhiều product ngoài kia có cách triển khai cực kì đỉnh cao, sản phẩm có hàng triệu người xài, nhưng coverage chưa tới 10%
 
AnhLaAiZay said:
Chắc có lẽ em thuộc dạng nhạy cảm bác ạ , ông lead cũng hiền ko chửi mắng gì chỉ tỏ thái độ chán chường xong kêu nhìn code chán các thứ nhưng cũng vẫn chỉ bảo làm lại, cơ mà nghe buồn ghê gớm
Click to expand...
Tôi cũng đang mentor một fresher đây, đúng là chán luôn. Bạn chán 10, người ta cũng chán 6-7 đấy. Nên là cố gắng lên, làm ở cty rồi cũng mang về mà đọc lại, nghiên cứu thêm, tiến bộ nhanh tý thì cả bạn và mentor đều đỡ vất vả. Cái nghề này bảo học thì dễ, nhưng làm được việc thì cũng phải lăn lộn cỡ 1 năm mới tự bơi được.
xjIzSG9.png
 
youknowwho151 said:
Code rác là sản phẩm unusable.
Coverage 80% không đồng nghĩa là sản phẩm sẽ sử dụng được.

Bật mí cho bác biết là rất nhiều product ngoài kia có cách triển khai cực kì đỉnh cao, sản phẩm có hàng triệu người xài, nhưng coverage chưa tới 10%
Click to expand...

Bác bật mí công ty nào để em mở mang tầm mắt với :shame:

Nói chuyện bỏ qua unit test tạm thời để đẩy product nhanh nếu không công ty phá sản thì còn thông cảm được. Nhưng về lâu dài, test coverage thấp sẽ dẫn đến nhiều bug hơn, hệ thống khó thay đổi hơn, team làm việc kém hiệu quả hơn. Nói cách khác là chất lượng code kém.

Tất nhiên, test coverage cao nhưng code ngu thì vẫn chết. Nhưng Unit test là điều kiện cần thôi, không phải điều kiện đủ. Ngoài UT còn có tầng tầng lớp lớp các loại test khác như integration test, end-to-end test, acceptance test, performance test, smoke test, etc. Lên đến production còn có logs, alert, các kiểu. Vậy mà code có thể bug bất cứ lúc nào, chứ đừng nói đến việc không có luôn unit test.

Bỏ qua unit test có thể nhanh đoạn đầu nhưng về lâu dài là net negative. Nên nếu không biết viết/viết không hiệu quả thì chịu khó tập viết nhiều cho quen. Coverage 100% khó đạt được và cũng không cần thiết; nhưng tầm 90% hoàn toàn có thể đạt được.
 
cool-girl said:
Cơ mà viết UT tốn thời gian đến vậy à. Tôi nghi ngờ cái cách anh viết UT quá.
Click to expand...
bên mấy chỗ mình làm chủ yếu UT các phần business logic, kiểu dạng code phân loại, tính toán, validation.. cái nào thấy dễ hỏng thì test thôi nên coverage 20-30% là bình thường, mấy đoạn code config, setup, handler các kiểu thấy test cho có thì mất thời gian. Test đủ case cho thằng logic đã tốn thời gian rồi, vì có khi coverage vẫn vậy nhưng case thì nhiều. 3 4 cái if đã 2^3 2^4 case rồi :D

Nhưng nếu có điều kiện thì coverage càng cao càng tốt hơn k
 
cool-girl said:
Tất cả dự án mình làm thì phải commit là coverage at least 80%. Không có thời gian viết là không biết viết hoặc triển khai code ngu nên không viết xuể. Code không UT khác gì rác.
Click to expand...
Đừng phiến diện vậy thanh niên. Sản phẩm bên mình phân phối đến tầm 30tr user, ko viết UT gì luôn bạn.
 
8UiHkRX39E32H said:
Bác bật mí công ty nào để em mở mang tầm mắt với :shame:

Nói chuyện bỏ qua unit test tạm thời để đẩy product nhanh nếu không công ty phá sản thì còn thông cảm được. Nhưng về lâu dài, test coverage thấp sẽ dẫn đến nhiều bug hơn, hệ thống khó thay đổi hơn, team làm việc kém hiệu quả hơn. Nói cách khác là chất lượng code kém.

Tất nhiên, test coverage cao nhưng code ngu thì vẫn chết. Nhưng Unit test là điều kiện cần thôi, không phải điều kiện đủ. Ngoài UT còn có tầng tầng lớp lớp các loại test khác như integration test, end-to-end test, acceptance test, performance test, smoke test, etc. Lên đến production còn có logs, alert, các kiểu. Vậy mà code có thể bug bất cứ lúc nào, chứ đừng nói đến việc không có luôn unit test.

Bỏ qua unit test có thể nhanh đoạn đầu nhưng về lâu dài là net negative. Nên nếu không biết viết/viết không hiệu quả thì chịu khó tập viết nhiều cho quen. Coverage 100% khó đạt được và cũng không cần thiết; nhưng tầm 90% hoàn toàn có thể đạt được.
Click to expand...
Có nhiều lý do mình không thể nói cho bạn chi tiết dc.
Nhưng các dự án mình làm, đều release lúc coverage chỉ 5-10%. Chủ yếu là ở những logic chủ chốt. Và phần lớn là đều thành công cả

Còn dĩ nhiên khi dự án đã đi vào maintainance thì viết thêm cũng dc thôi.
 
cool-girl said:
Tất cả dự án mình làm thì phải commit là coverage at least 80%. Không có thời gian viết là không biết viết hoặc triển khai code ngu nên không viết xuể. Code không UT khác gì rác.
Click to expand...
ông chưa bị dí dự án bát release gấp à
 
codecmartin said:
Đừng phiến diện vậy thanh niên. Sản phẩm bên mình phân phối đến tầm 30tr user, ko viết UT gì luôn bạn.
Click to expand...
youknowwho151 said:
Có nhiều lý do mình không thể nói cho bạn chi tiết dc.
Nhưng các dự án mình làm, đều release lúc coverage chỉ 5-10%. Chủ yếu là ở những logic chủ chốt. Và phần lớn là đều thành công cả

Còn dĩ nhiên khi dự án đã đi vào maintainance thì viết thêm cũng dc thôi.
Click to expand...
đúng r, UT là nên khi dự án gấp và cần khi dự án ko gấp, rất cần khi dự án maintain
 

Similar threads

L
Em xin kinh nghiệm phỏng vấn vòng 2 SMC ạ!!!
Replies
0
Views
362
lichntcc
L
asacoco
Technician có cửa lên engineer không?
Replies
15
Views
1K
Roland2020
Roland2020
magic152
thắc mắc lỗi 404 khi cố gắng kết nối máy ảo Worker1 với node Master (k8s)
Replies
9
Views
396
magic152
magic152
kienteppei
Xin tư vấn cấu hình 15tr không màn, chủ yếu làm văn phòng, có sử dụng pts và illustrator, lâu lâu game fifa ạ.
Replies
12
Views
488
NewgearKG
NewgearKG
Xuan Ha Thu Dong
thảo luận [Review] Cuộc sống và công việc Dev ở Hà Lan. Làm thế nào để tìm việc ở HL và châu Âu nói chung?
4 5 6
Replies
102
Views
8K
itachicitus
itachicitus

Share this page

Back
Top