second(s) đó anh làm sao em chờ nổi 100 minutes để test (yaoming)

Thực tế thì team mình đã sử dụng Planning Poker giống như ý kiến của bạn @kanamikiii . Tuy nhiên, trong thực tế sẽ có những trường hợp khá khó đi tới thống nhất nếu như năng lực hay phương án implement quá khác nhau. Trong trường hợp đó chúng ta có thể sử dụng phương án lấy trung bình. Nhưng ưu tiên cho người trực tiếp implement task đó một trọng số lớn hơn những người còn lại.

Vì việc estimate có giá trị cao nhất khi nó gần đúng với thực tế nhất, chứ không phải sao cho vừa lòng KH nhất. Khi được giao một trọng số đủ lớn người trực tiếp implement sẽ tự thấy mình có ý thức hơn trong việc đảm bảo giá trị estimate mà mình đã đưa ra.

bài viết rất dễ hiểu , Upvoted!

Theo ý kiến của vài người thì để tránh "loãng" bài thì mình sẽ viết theo chương và không tách nhỏ thành bài con nữa (mình đã bổ sung luôn phần còn lại chương I vào bài này)

(?)

Bài viết này chính xác là những gì mình đang tìm. Cảm ơn AD rất nhiều!!!

"I was browsing through Rails source code and here’s what I’ve come up with:" mà dịch thành "từ đó viết được đoạn code mô phỏng lại quá trình mã hóa này:" dịch tào lao vậy anh? là xem mã nguồn rails chứ không phải là viết được ra cái mã đó. the best rồi :v best of translater

"Để kiểm tra current_user đang logged in hay không, một developer đã viết đoạn code truy xuất thông tin dựa trên session như sau" => đoạn code đó là để trả về user đang login nếu có mà bạn, chứ có phải để kiểm tra current_user đang login hay chưa đâu?

Mình mail cho Bạn. Bạn check mail và hy vọng có buổi off với Bạn. Cám ơn Bạn rất nhiều

Lần sau bạn để code cho anh em dễ copy nha

Anh có thể giải thích ý nghĩa của những khai báo trong file dbmanager.h và .m được không ah!!!

Bài viết rất trực quan - thú vị, Nhưng mình có một số quan điểm như sau:

1. Mình sẽ luôn ghi log khi chương trình vào catch theo cú pháp logger.error("class_name - method_name: ", e); Mặc dù như bạn nói vừa throw với vừa ghi log thì nó sẽ khiến thông báo lỗi bị lặp lại nhiều lần. Nhưng logging dc tạo ra với mục đích là "GHI CHÉP" lại các vấn đề trong quá trình ứng dụng hoạt động. Nên nếu loại bỏ việc ghi log chẳng khác gì khai tử việc tracking chương trình cả (nguong)

2. Ngoài ra, tất nhiên, mình nghĩ không phải lúc nào cứ vào catch là phải throw e. Nó tùy thuộc vào việc người phía sau có cần thiết phải nhận exception đó không.

Như vấn đề Transaction trong chương trình, vì lý do là Transaction chỉ rollback data khi và chỉ khi có exception xảy ra, nên đối với việc modifier data thì mới cần throw e, còn như select data thì mình cứ mặc định return về object hoặc collection empty...

Nên mình nghĩ, việc người lái xe nhận cục đá và cân nhắc là có cần quẳng cho thèn ngồi sau giải quyết không, hay là tự mình giải quyết cũng là việc cân nhắc đầu tiên - đó mới chính là code có trách nhiệm. Mình nghĩ là hạn chế throw exception nếu như nó không cần thiết.

Như nhà mình hết gạo, mình biết và đi mượn gạo từ hàng xóm, hay nói với mẹ mình và mẹ mình chạy đi mượn gạo từ hàng xóm thì mình nghĩ là mình chủ động đi mượn sẽ đỡ tốn giai đoạn thông báo, vì 2 việc điều sẽ dẫn đến kết quả là phải có ng đi mượn gao thôi (yaoming)

Đó là ý kiến cá nhân của mình, đúng như bạn nói, tùy thuộc vào từng tình huống mà mình sẽ giải quyết exception hay throw exception cho ng sau. (ahihi)

Việc xây dựng kịch bản và chương trinh team building rất quan trọng, nhưng chưa thấy phần ý nghĩa của chương trình team building này. Vì mỗi công ty có những tình huống, vướng mắc khác nhau trong quá trình làm việc. Team building có thể giải quyết được những vấn đề này. Via : https://saigonteambuilding.net

Cảm ơn bạn:)

Bài viết của bạn rất hay.

Hay quá. Cảm ơn bạn

cảm ơn anh đã giúp em tốn 3 phút đọc 1 bài viết đầu voi đuôi chuột, thiếu tâm huyết, viết lách qua loa. Cảm ơn anh đã làm em lãng phí 5 phút.

Cảm ơn bạn

Test