如何給蘋果提交Bug或功能需求？

jopen 9年前發布 | 8K 次閱讀 Bug

如何給蘋果提交Bug或功能需求？

自從 Swift 推出以來，很多開發者已經第一時間嘗鮮并且嘗試用它進行開發了。不過，由于 Swift 還是個演進中的語言，Xcode 對它的支持并不完善，偶爾會出這樣那樣的小問題。有些開發者在發現問題后，頂多發個博客記錄一下然后就不管了，我們是否有更好的辦法，比如給蘋果提交這個 bug，讓它快速修復呢？

答案是有的，并且僅對蘋果的開發者開放，即蘋果的 Bug Reporter 系統。

Radar or GTFO

在蘋果的 Bug Reporter 里，你可以提交你發現的問題或者功能需求，你也可以查看你提交的問題的處理情況。問題會被分配一個 ID，并帶上 rdar://10993759 這樣的 URI 鏈接，因此給蘋果提 Bug 被稱為“file a Radar”，意味著你的問題出現在了蘋果工程師的雷達上面，十分形象。

在國外蘋果開發者中間有一句廣為流傳的話叫做“Radar or GTFO (Get The f*ck Out)”，意思是除非你發布了一個 Radar，否則蘋果不會處理你的問題。無論你在個人博客或者蘋果的開發者論壇上面提交 Bug，即使蘋果工程師看到也會被忽略掉的，這個 Bug Reporter 幾乎是開發者和蘋果之間關于系統和軟件故障的唯一反饋渠道（如果是和 App 審核、蘋果設備相關的問題，你可以尋找對應的客服）。

如何寫一個 Radar？

使用蘋果開發者賬號登錄到 Bug Reporter 后，你可以提交問題。蘋果的這個系統和其它的 Bug 追蹤系統并沒有太大的差別，你需要先選擇發生問題的產品、問題類型、復現頻率，然后用標題和文字來盡可能清晰的描述你的問題細節。

編寫問題細節并沒有固定的格式，你需要提供出問題的系統或軟件版本，如果有截圖或者其他文件證據可以作為附件添加。需要注意的是，你需要用英文編寫問題。

不過，雖然沒有格式，作為完美主義者的蘋果還是對問題細節的描述做出了諸多規定和建議。比如，標題部分：

  • Safari is slow.（壞的）
  • Safari is slow allocating JavaScript arrays. (Include JavaScript sample with your bug report.)（好的）

問題細節也需要包含以下幾個部分：

  • 復現問題的步驟
  • 預期結果
  • 實際結果
  • 變通方案
  • 回歸測試和條件隔離情況（Regression/Isolation）

具體內容可以看蘋果關于 Bug Reporting 的文檔。

提交 Radar 的技巧

提交 Radar 可能會遇到一個情況，那就是這個問題之前已經有人提交過，那么它會被標注為“duplicate”，不要驚慌，其實這里包含著一個提交 Radar 的技巧。

前面說過，向蘋果反饋 bug 的唯一途徑是 Bug Reporter，在其它地方鬧得滿城風雨也沒有用，蘋果也不建議這么做，如果你做得太過分了，還可能受到蘋果的懲罰。那么，如何讓蘋果重視你提交的問題呢？

Daniel Pasco，一位有經驗的蘋果開發者在他的文章里這樣向我們傳授經驗：

工程師團隊總是面對太多需要解決的問題，工程師們定期的和它們的上級主管開會，對問題進行分類，以決定接下來需要解決哪個問題。一個問題被報告得越多，說明它越需要關注，工程師在下判斷時也會更容易。

對于所有軟件公司來說都是這樣，當你發布了一個產品，人們很有可能會報告一兩個邊緣用例（edge case）下的問題，你當然會想在時間允許的情況下修復它，但如果有數百人報告相同的問題，說明問題很嚴重，并亟待解決。蘋果在這方面和其它公司并無不同。

從某種意義上來說，提出重復的問題是一種投票，或是對已存在問題的一個支持。一個問題獲得的重復次數越多，說明它的優先級越高。

因此，如果你發現了一個問題，在提出 Radar 之后，可以將 Radar 原文發布到自己的博客或者論壇上，號召其它開發者提出相同的 Radar，促使蘋果工程師重視這個問題。不過也要有所克制，注意不要濫用。

除了提交重復問題，還有一個可能不太常用的技巧是，你可以去勾搭蘋果工程師，如果你提交的 Radar 好幾天了都沒動靜，你可以聯系蘋果工程師，以求獲得一個反饋。當然，這里如何勾搭和勾搭的技巧就需要大家自己琢磨了。

看到這里你是不是蠢蠢欲動，想去 Bug Reporter 上提交幾個 bug？但國外的蘋果開發者對這個 Radar 系統卻并不怎么買賬，為什么呢？

Fix Radar or GTFO

蘋果的這個 Bug Reporter 系統最大的問題是，開發者提交問題之后，無法快速收到有效的反饋。一般的場景是這樣，你提交了一個問題，然后它被標為 duplicate 并關閉，然后就沒有然后了。別的開發者無法看到你的提交的 Radar，你無法看到蘋果的工程師對于此問題的回復，你也無法得知你提交的問題何時能得到修復。（如果你提交的 Bug 非常緊急或有一些其它問題，蘋果也可能會直接聯系你，不過這種情況很少）

Mattt 大神曾經提到，一個 Radar 在提出足足 7 年之后才被修復，除了提交 Radar 的技巧之外，缺乏有效的溝通手段也是造成這一結果的原因。

另外，這個 Bug Reporter 系統還有 UI 不美觀，完全不像蘋果出品，對于開發者不夠友好的缺陷。

在 2012 年，一些蘋果開發者再也無法忍受如同黑洞一般的 Bug Reporter 系統，發起了“Fix Radar or GTFO”活動，呼吁開發者提交重復性的 Radar，想讓蘋果改進這個 Bug 收集系統，讓它變得更加開放。另外一些人則做了一個 openradar，開發者在提交到官方的 Bug Reporter 之余，也可以將他們的 Radar 提交到這里，開發者可以看到別人的 Radar 并進行討論。

開發者的這些努力收到了一定的效果，2013 年 9 月，蘋果對 Bug Reporter 系統進行重新設計，改進了它的 UI 和使用體驗，但是，對于開發者們開放 Radar 的要求則未予滿足，你仍然不知道你提交問題之后究竟發生了什么。

不過，也有開發者對“Fix Radar or GTFO”運動并不以為然，像這篇文章所說的：

其實開發者并不需要一個 Radar，需要 Radar 的是蘋果，如果 Radar 對于蘋果來說工作得很好，那么就沒什么問題。比如在是否開放 Radar 上面，如果開放 Radar 會造成一些不好的后果，比如 Bug 被惡意利用、Radar 優先級被活躍用戶干擾等等，那么還不如不開放。開發者需要做的是“file and forget（提交并遺忘）”，提交 Bug 已經盡到了開發者的責任，接下來的就留給蘋果吧。

是的，也許我們走過頭了，如果我們知道，提交的 Radar 會被認真對待，那么其實沒有必要要求更多，畢竟對于改進產品最迫切的是蘋果，而不是開發者。

所以，信息不對稱是萬惡之源，那么就讓我們來看看，一個 Radar 被提交后，蘋果是怎么處理的吧。

蘋果內部是如何處理 Radar 的？

一個曾參觀過蘋果內部的開發者描述道： 蘋果內部有一個專門的 Mac app 用于處理提交的 Bug，在這個 app 里面，蘋果工程師能夠對問題進行標記和分類，不同的工程師能對同一個問題進行討論，最終進行優先級的評定，比如評定為“Show-Stopper”狀態的 問題是必須第一時間解決的，否則不會發布下一個更新。

事實上，蘋果非常重視提交到 Bug Reporter 的問題，一位曾在蘋果工作過的開發者寫道：所有的問題都會被很快的分類并進行討論，只是問題是，討論多涉及到蘋果內部的技術，而由于蘋果的保密措施，所以即使是討論也是難以對外分享的。

所以，你可以放心的提交 Bug 而無需擔心它受到冷落，而另一方面，也不要太期待從蘋果得到反饋，如果蘋果修復了這個問題，那么你是幸運的；如果蘋果沒有修復，說明這個問題的優先級還不夠高，工程師們有其它要做的事情。

如果你認為你發現的問題很重要，你可以嘗試一下上面提到的技巧。重要的是態度，其實你和蘋果的目標是一致的，都想解決你提出的問題，所以沒有必要鬧得不愉快。

據蘋果最新的財報顯示，中國已經是 iPhone 最大的發售地了，中國的 iOS 開發者數量也居世界前列，蘋果本身也越來越重視中國。但相比之下，蘋果軟件在中國的本地化仍然存在一些問題，有不少問題值得報告；中國的 iOS 開發者也顯得太低調，無論是開發者之間的交流，還是和蘋果之間的交流都很少。我想，向蘋果提交 bug 和功能需求是一種溝通和表達自己的手段，無論是對于開發者自己，還是對提高中國在蘋果軟件開發生態的地位都是有幫助的。

所以還等什么呢？快去提交 Radar 吧！~

參考鏈接：

來自: idlelife.org

 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
  本文地址：http://www.baiduhome.net/news/view/1d30bd0