背景故事

沒錯你沒看錯標題，陪伴我們超過10年的函式要被砍掉了，但這次我們不哀傷不文青，這次我們來好好討論一下原因和如何遷移！

原本的poll就是接受一個長整數，但這個長整數的單位是什麼？毫秒？秒？分？雖然有經驗的人很快就會猜到應該是毫秒，但身為善良的工程師，為何我們不試著用更能清楚表達語意的物件呢？所以第一個要替換的原因就是為了讓程式的可讀性更高！

從

consumer.poll(0);

變成

consumer.poll(Duration.ofMillis(1000));

大家可以從上述的程式碼看到，新版的寫法在建立Duration的時候可以明確宣告單位，所以在閱讀程式碼的時候可以非常非常清楚的知道超時的具體長度！

故事到這裡就結束了嗎？當然不是，可讀性只是其中一個好處，更重要的一個點的則是行為的調整！大家有沒有思考過，poll的過程到底做了哪些事情？例如Consumer到底怎麼知道要跟哪個伺服器去索取資料？Consumer要不要確認自己已經加入群組？沒錯，事實上poll的過程不只會涉及元數據的更新、同時也會確保自己已經加入群組，所以問題就來了，這些動作到底有沒有要算在超時？或是poll一定要等到該些動作完成才能回傳？

身為優秀的工程師可能會立刻說，當然要尊重使用者給的參數阿，如果更新元數據或是加入群組無法在指定的時間內完成，那就乖乖回傳阿。沒錯，我們也都是這樣想，但事實上這個陪伴大家十年的poll其實是會要完成元數據更新和加入群組才會返回，而這也是困擾許多使用者的疑問，爲何第一次poll的時候好像都會卡很久，現在大家知道原因了，這並不是bug而是一種特色，然後這個特色我們不要了！這就是這次刪除的另一個重點，替代方案不只是用了更好的參數類別，同時也讓元數據的更新和群組的加入納入超時的範圍裡面！

等等，那如果我之前把poll當作隨敲隨到怎麼辦？例如以下程式碼該怎麼改寫？

consumer.poll(0)
assertNotEquals(0, consumer.assignment().size())

解決辦法

很不幸的，這個時候這個時間這個決定，上述的狀況就沒有可以一鍵替換的方式，事實上這個本來就是屬於錯誤的用法，使用者不應該去預期每次poll一定可以獲得或是完成任何事情，一切都是隨著時間隨著緣份，希望這次的修正可以在未來避免許多誤會

廣告

歡迎訂閱全臺最鬆散的開源社群源來適你，上面不定期會有各種開源的廢文。也歡迎參加全臺最鬆散的開源討論頻道，上面有一群網友一起在刷開源技術