推 alihue: 推推 12/30 13:10
推 AmosYang: 軟體工程 (x) 人體工程 (o) XD 12/30 19:14
推 lance70176: 為啥這篇推的人這麼少XD 12/30 20:08
推 sa074463: 推 12/30 22:22
→ dnabossking: 因爲議題疲乏，某些族群又更爲明顯 12/31 09:37
推 v9290026: 推 12/31 12:09
→ vn509942: 謝謝分享 12/31 13:33
※ 引述《sec5566 (sec)》之銘言：
: 以前上課跟書本都提到寫註解，
: 但是我看資深同事還有接手的程式碼，
: 都沒有註解，只有我在寫，
: 還被主管念過寫註解沒必要，
: 命名好就夠了，
: 是我觀念落伍了嗎？
: -----
: Sent from JPTT on my Sony H4331.
『寫註解到底是不是好習慣？』
雖然這是一個老梗的題目，但不同時期都有不同的想法啊。
特別是工作多年後，可以站在不同角色來想以前沒想過的事。
我有時候充當替新手導覽的角色，每回接觸不同的新手級工程師，
都是不同的文化衝擊。
通常在『新手村』模式的基本要求就是『忠實』表達想法，
我需要明確地知道對方『懂』或『不懂』。
儘管試著裝懂，那在接下去的對話也會很快地能診對出
我眼前面對的初級工程師目前的思緒是卡在哪。
就會再次提醒，若不懂我說的概念，或眼前所見的程式無法理解的情況，
請立即提出。
對於初級工程師或者新進的工程師，對我們正在進行的專案是陌生的。
在我『誠實』的基本要求之下，我很可能有機會在這個 mentoring
的最初階段一直聽到『我看不懂程式』。
程式裡面沒有註解嗎？有些地方有，有些地方沒有，
但是這不是簡地說說註解寫得好或不好可以解決的。
因為註解並不是為了這樣情境寫的『要讓第一次看這份 code 的人就懂』，
況且我們大部分的時候，不會在註解上花費太大的篇幅在寫註解，
也不會有特別細瑣的事寫在上面，要理解一段程式，
要有一定的背景知識存在。
對我來說『註解』是程式的一部分，它能用來支持程式可執行單元的表達性。
若是程式可執行單元已經足夠描述意圖了，
那註解只是使用另一種語法再寫一次說明罷了，
但事情並沒有那麼單純，因為每個人的理解並不完全一致。
文章裡開頭提到的『命名好就夠了』，
現實上一定會有人覺得這命名懂，另一些人覺得這是 3 小朋友的情況。
這就是前面說的『背景知識』不一致產生的思考落差。
這現象並不是有沒有寫註解或命名好不好的問題。而是該有的背景知識缺乏，
而無法理解這個隊團的思考慣性的問題。
簡而言之，你還沒有融入這個團隊的工作模式：
* 核心的系統隱喻
那些討論過的 spec 內，有些核心的邏輯，
圍繞這些邏輯的核心用語與動詞。
這裡的 spec 並不是只 SA/SD 那個時間產出的標準文件，
而是我們在討論 issue 時，具體實現方法的主要概念與細節。
* 對針主要的工作產出有共通的視野
在討論 spec 或 code review 時，漸漸塑造成共通的視野。
在互動的過程中，我們才能知道隊友的想法是不是一致，
所以鼓勵每個人表達是相當重要的，特別是剛加入團隊的同事，
只要他默默地不說話，那就得製造機會給他。
或是偶爾小出槌製造一下別人反駁、糾正觀點的機會。
因為只有在想法上有衝突時，印象才會深刻，
認知通過衝突調和之後形成的共通視野才會穩固。
* 統一的術語
在前 2 個過程中，我們還沒有真的建立好核心隱喻
(一個名詞 與 相應能適用的 動詞 們)
可能會用很多不同的詞來描述概念，最後我們只能保留其中一些，
作為最重要的術語。才不會讓『概念』漂來漂去，
或讓新進的參與者有其他聯想。
程式碼中可以執行的單元，或不可執行的單元
(註解或一些只存在編譯期的語法結構)
是否具表達力是透過互動過程建構的。
我們得溝通、得聊天才知道想法有沒有差距，
有了共通的文化小圈圈才能知道哪些 [命名 / 註解]
是容易讓團隊其他人看得懂的。
工程師的工作是一個互動的過程，它不像過去學校交作業，然後等待評分而已。
你得去跟你的同事互動，聊聊正在開發的程式，
多談談你的理解才好融入團隊的思考慣性。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.138.44
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1546144956.A.439.html