Documentation/translations/zh_TW/process/6.Followthrough.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_TW/process/6.Followthrough.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_TW/process/6.Followthrough.rst
Extension
.rst
Size
10733 bytes
Lines
157
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

.. include:: ../disclaimer-zh_TW.rst

:Original: :ref:`Documentation/process/6.Followthrough.rst <development_followthrough>`

:Translator:

 時奎亮 Alex Shi <alex.shi@linux.alibaba.com>

:校譯:

 吳想成 Wu XiangCheng <bobwxc@email.cn>
 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>

.. _tw_development_followthrough:

跟進
====

此時，您已經遵循了到目前爲止給出的指導方針，並且，隨着您自己的工程技能的增加，
已經發布了一系列完美的補丁。即使是經驗豐富的內核開發人員也能犯的最大錯誤之一
是，認爲他們的工作現在已經完成了。事實上，發佈補丁意味着進入流程的下一個階段，
可能還需要做很多工作。

一個補丁在首次發佈時就非常出色、沒有改進的餘地，這是很罕見的。內核開發流程已
認識到這一事實，因此它非常注重對已發佈代碼的改進。作爲代碼的作者，您應該與
內核社區合作，以確保您的代碼符合內核的質量標準。如果不參與這個過程，很可能會
無法將補丁合併到主線中。

與審閱者合作
------------

任何意義上的補丁都會導致其他開發人員在審查代碼時發表大量評論。對於許多開發
人員來說，與審閱人員合作可能是內核開發過程中最令人生畏的部分。但是如果你
記住一些事情，生活會變得容易得多：

 - 如果你已經很好地解釋了你的補丁，審閱人員會理解它的價值，以及爲什麼你會
   費盡心思去寫它。但是這個並不能阻止他們提出一個基本的問題：在五年或十年後
   維護含有此代碼的內核會怎麼樣？你可能被要求做出的許多改變——從編碼風格的
   調整到大量的重寫——都來自於對Linux的理解，即從現在起十年後，Linux仍將
   在開發中。

 - 代碼審查是一項艱苦的工作，這是一項相對喫力不討好的工作；人們記得誰編寫了
   內核代碼，但對於那些審查它的人來說，幾乎沒有什麼長久的名聲。因此，審閱
   人員可能會變得暴躁，尤其是當他們看到同樣的錯誤被一遍又一遍地犯下時。如果
   你得到了一個看起來憤怒、侮辱或完全冒犯你的評論，請抑制以同樣方式回應的衝動。
   代碼審查是關於代碼的，而不是關於人的，代碼審閱人員不會親自攻擊您。

 - 同樣，代碼審閱人員也不想以犧牲你僱主的利益爲代價來宣傳他們僱主的議程。
   內核開發人員通常希望今後幾年能在內核上工作，但他們明白他們的僱主可能會改
   變。他們真的，幾乎毫無例外地，致力於創造他們所能做到的最好的內核；他們並
   沒有試圖給僱主的競爭對手造成不適。

所有這些歸根結底就是，當審閱者向您發送評論時，您需要注意他們正在進行的技術
評論。不要讓他們的表達方式或你自己的驕傲阻止此事。當你在一個補丁上得到評論
時，花點時間去理解評論人想說什麼。如果可能的話，請修復審閱者要求您修復的內
容。然後回覆審閱者：謝謝他們，並描述你將如何回答他們的問題。

請注意，您不必同意審閱者建議的每個更改。如果您認爲審閱者誤解了您的代碼，請
解釋到底發生了什麼。如果您對建議的更改有技術上的異議，請描述它並證明您對該
問題的解決方案是正確的。如果你的解釋有道理，審閱者會接受的。不過，如果你的
解釋證明缺乏說服力，尤其是當其他人開始同意審稿人的觀點時，請花些時間重新考慮
一下。你很容易對自己解決問題的方法視而不見，以至於你沒有意識到某些東西完全
是錯誤的，或者你甚至沒有解決正確的問題。

Andrew Morton建議，每一個不會導致代碼更改的審閱評論都應該產生一個額外的代碼
註釋；這可以幫助未來的審閱人員避免第一次出現的問題。

一個致命的錯誤是忽視評論，希望它們會消失。它們不會走的。如果您在沒有對之前

Annotation

Implementation Notes