) mời làm việc thử với CosmosDB nhé
Thôi anh đừng nói nữa dc ko
anh đừng nói chuyện kiểu out-of-scope tôi cườiKhi cái mới mà a nói + a đã trải nghiệm qua nhiều lần + thấy đc điểm yếu của nó thì a mới “ngộ” ra được anh ạ.
Ko phải tự nhiên người ta phát triển từ procedure programming tới oop rồi giờ lại quay ra functional programming. Hay từ monolithic + 3 layers lại đẽ ra clean architecture, micro services..
Đôi khi anh cũng nên xuống giếng chơi để thấy dc con ếch ở dưới đó biết đâu lụm dc bí kiếp võ công.
Khuyên: a cũng nên mở đầu ra khi thấy tư tưởng khác, đi ngc lại những gì a dc học. Đó là lúc mà một cái gì mới hơn sắp dc sáng tạo ra đó.
via theNEXTvoz for iPhone
với cả mấy cái thứ mà anh nói nó cũng chả liên quan mẹ gì cả cái "không có thời gian" mà tôi nói ở đây nó không phải là nghĩa đenÀ riêng vụ thời gian thì tôi có thừa nhé. Tôi lo cho mấy a e dev thôi chứ tôi rảnh lên Voz cãi nhau giờ hành chính thì a hiểu tôi thừa thời gian rồi.
via theNEXTvoz for iPhone
cái mà tôi nói ở đây là cái câu chuyên dùng để nguỵ biện cho mấy cha dev cùi bắp toàn lấy lý do "không có thời gian" để deliver 1 đống code bùi nhùi ấy mấy cha đấy thì dù có "có thời gian" thì cũng đ biết code sao cho sạch đẹp đâu mà
anh đừng nói chuyện kiểu out-of-scope tôi cười
cái "không có thời gian" mà tôi nói ở đây nó không phải là nghĩa đen
quay trở lại chủ đề chính. mục tiêu của viết unit test nó éo phải là "code chạy không có lỗi" hay "lên prod không có lỗi" như anh nói, mocking code không bao giờ có thể đảm bảo được vấn đề đấy cả, anh muốn đảm bảo được việc đấy đấy thì anh phải dùng các loại test khác. mục tiêu của nó là self-review (nếu anh viết ra 1 cái function mà lúc viết UT đúng cách (hoặc không thể viết được UT) anh cảm thấy nó như c** thì đấy là lúc anh cần phải xem lại đoạn code của mình vì chắc chắn nó đang có vấn đề), documented lại cái idea, logic của function đấy, và đảm bảo được việc re-implement lại cái function đấy (để improve performance chẳng hạn) không bị sót logic hoặc sai idea của cái func đấy -> tự tin hơn trong việc sửa code không phải của mình.
tôi thấy anh kiểu cũng kinh nghiệm lâu năm, cũng có những chính kiến của mình, cũng biết bảo vệ chính kiến của mình. nhưng anh kiểu bình thường toàn làm việc một mình hoặc làm việc với team nhỏ lẻ ý, nên những convention, design kiểu phục vụ việc teamwork (team lớn) hiệu quả, hoặc để để việc maitenance dễ thở hơn anh toàn xem nhẹ xong gào lên bảo thừa thãi không cần thiết, với cả cái gì gì "thực tế không giống sgk". trong khi ý tưởng của nó thì anh không hiểu rõ xong áp dụng sai context...
Ơ cái nhà anh này, đấy là chất lượng code anh các a như shit, est như shit, management cũng như shit nốt. Nó chẳng liên quan đến cái việc UN là thừa thãi như a nói cả. Ở đây mọi người chỉ nói về vấn để kỹ thuật, a lôi cái đấy vào làm gì? A ko làm dc, ko deal dc khách nên a lại bảo UN là thừa. Tôi chịu. Tôi cũng ko biết a role là gì mà a cứ mở mồm ra là chê người khác là thợ code. Nói thật, nếu anh là manager thì a cũng chỉ là thằng “thợ quản lý” với cái mindset nông dân của mình.Còn anh thì chỉ biết mổi cái vấn đề kỹ thuật thôi. Bởi vậy tôi mới nói các anh “thợ code” là đúng đấy.
Giờ tôi cho anh đề bài như này:
1. Code cũ, dependencies búa xua, not testable.
2. Team toàn fresher, junior đúng nghĩa có thời gian cũng éo biết code sao cho đẹp.
3. Trong vòng 1 tuần phải release features, fix các bug critical và đặc biệt ko dc phép fix bugs này tạo ra bug mới vì đã bị escalate nhiều lần, khách hàng yêu cầu test coverage 90%.
4. Dự án over budget, thêm 1 man day là thằng PM gào lên, head department gào lên nên KHÔNG muốn tốn thêm bất kỳ man days nào để refactor code hay delay nữa.
5. PM và Head gặp mặt thì hỏi 1 câu duy nhất: “Khi nào xong?” Éo quan tâm ba cái vấn đề code kiếc vớ vẩn.
Mới anh giải quyết.
Anh lên chém gió về UT của anh đơn giản là người ta đíu quan tâm và cái ng ta quan tâm là cuối tuần này release và khách hàng nó ko chửi nữa. Ok.
via theNEXTvoz for iPhone
A nói chán bỏ mẹ, dự án ngay từ đầu đã ko testable, khách hàng ko quan tâm đến UN, ko có budget cho UN thì khiến anh đi viết UN à? Ở đây đang nói chuyện viết UN thế nào cho nó hiệu quả, tức là nói đến những project có điều kiện để viết UN. Tôi đéo hiểu a đang muốn thể hiện cái gì nữa? Còn dự án thối, thì đời code dạo có ông nào ko gặp mà anh cứ lu loa lên như thể mình a cân cả thế giới thế.Mời anh đọc lại #103 và #114 của tôi. Hình như tôi chưa bao giờ nói UT là thừa cả.
Còn a bảo là chỉ dc bàn vấn đề kỹ thuật thì tôi lượn thôi vì mấy cái đó nó quá cơ bản, a hỏi 1 thằng sv hay đọc sách thì đều chém đc hết.
Khịa mấy a vài cái như “thợ code” hay “công nhân IT” là giãy nãy lên rồi.
A nên nhớ trong thế giới này ko phải Perfect World và tất cả mọi thứ đều phải đánh đổi. Một ng gọi là giỏi là người có thể đạt được mục tiêu trong các điều kiện giới hạn chứ ko phải điều kiện hoàn hảo.
Cái tình huống bên trên tôi đưa ra là một tình huống thực tế. Nếu anh ko phải là thợ code thì a phải giải quyết dc nó với các ràng buộc như vậy. Chứ ko phải là chỉ biết chửi team, chửi sếp, chửi dự án, chửi khách hàng rồi đập bàn nghỉ, bỏ chạy đi chổ khác thôi.
via theNEXTvoz for iPhone
Mời anh đọc lại title của thread nhé
Thật luôn!!????
chỉ cần đọc sách là chém được luôn!!??? quá cơ bản luôn!!??? xin lỗi anh nhưng trình độ junior mà tôi gặp (thậm chí inter hay senior) thì 10 thằng chưa thấy thằng nào biết viết UT thế nào cho đúng hay thể hiện đúng tư tưởng của việc viết UT Cái này không cần anh phải nói mà ai có kinh nghiệm hoặc kinh qua nhiều code base như c** hoặc team như c** là đều biết á anh
Tôi nói thật với anh nhé. Anh cứ giữ cái tư tưởng ấy thì sẽ mãi mãi ngập trong đống c** hoặc chuyển từ ngập ngụa trong đống c** này sang ngập ngụa trong đống c** khác mà tôiCái tình huống bên trên tôi đưa ra là một tình huống thực tế. Nếu anh ko phải là thợ code thì a phải giải quyết dc nó với các ràng buộc như vậy. Chứ ko phải là chỉ biết chửi team, chửi sếp, chửi dự án, chửi khách hàng rồi đập bàn nghỉ, bỏ chạy đi chổ khác thôi.
vì mindset của anh từ đầu nó đã là chấp nhận cái "sự thật" mà anh hay nhắc ý anh nếu là manager thì tôi cũng chỉ đánh giá anh "thợ quản lý" mà thôi luôn bị deadline dí và nghĩ nó là bình thường chứ đ biết làm sao để khắc phục việc đấy và chưa bao giờ nghĩ đến chuyện làm sao để tránh lặp lại việc vô nghĩa như thế trong đầu chỉ luôn nghĩ đến chuyện deliver sản phẩm đúng hạn là được chứ đ có 1 chút lòng tự trọng hay tự hào nào về thứ mà mình làm ra luôn 
Uhm, TDD. Nhưng đây là cách thức tốn thời gian, và đòi hỏi dev có trình độ nhất định.
chuẩn luôn, viết TDD effort x2, thậm chí x3
Không liên quan nhưng mà bác cho e xin thêm dẫn chứng về lập luận tại sao nó quái thai/bu**sh*t?. Nào cũng có cái điểm mạnh và điểm yếu, tùy vào cân nhắc nếu ưu tiên điểm mạnh thì chọn, ưu tiên rơi vào điểm yếu thì không chọn thôi bác.TDD là cái thứ "quái thái" đi ngược lại suy nghĩ bình thường của software development. Nó như là một trend nhất thời chứ hiệu quả thật sự ko bao nhiêu.
Cái suy nghĩ "viết test trước rồi viết code sau" nó thật sự bullshit!
Cách viết đây nhé:Em đi làm 3 chỗ rồi mà chưa làm project nào có unit test hỏi mấy a làm trước thì bảo viết cũng được mà lười. Còn em tự đọc tài liệu trên mạng thấy toàn ví dụ rất đơn giản không áp dụng được gì mấy kiểu: assertEqual(add(1,1), 2)
