程式員該何時說“不”和“是”

文章目錄

• ​​0 背景​​
• ​​1 說“不”​​
• ​​2 說“是”​​

• ​​2.1 真/假承諾​​
• ​​2.2 真承諾應該怎麼做​​

• ​​2.2.1 團隊的角度​​
• ​​2.2.2 個人角度​​

• ​​3 總結​​

0 背景

此篇為《代碼整潔之道——程式員的職業素養》的第二篇讀書心得，主要講的是當面對産品需求時，應該何時說“不”和“是“。平時開發過程中，我們總是說”是“，很少說”不“。（因為團隊總是喜歡那些給予他們肯定答複的人）。那究竟什麼時候該說“不”？當我們說“是”的時候，又是否是正确的呢？本文正是解答這些問題的。

1 說“不”

• 1，當面對一些為了趕時間進度而不惜犧牲專業習慣（不寫測試、不做重構、缺少完成的回歸測試、不易擴充、修改、維護）的需求。
• 2，不為了按時完成“不合理”的任務，（結果可能是急于完成，卻遲于面市）來刻意追求成為“英雄人物”。

• 因為專業人士（通常稱為“英雄人士”）通常都是出色完成任務，不僅按時，而且符合預算。

• 3，當需求不合理時，為了維護面子和避免沖突，而說“試試看”。

• 因為說試試看，就意味着你承諾了“嘗試”，（你還未盡全力），更進一步是你承諾你會確定成功。（但實際上你卻沒有新的方案或行動，這是一種不誠信的方法）
• 正确的做法應該是：直面不同角色的沖突，（大部分經理都會竭盡捍衛他們設定的目标，因為為了拿出成績，會做出一些不合理的需求）努力尋求雙方認為的最佳的可能結果。

• 4，當在面對一些高風險時刻（公司存亡、人員安全等），應該盡自己最大的能力把最好的資訊（說明哪些是不能做到的，或者是危險性很高的事件）告訴自己的經理。

2 說“是”

2.1 真/假承諾

真正的承諾應該是：

• 1，口頭：說自己将會做
• 2，心裡：認真對待承諾

• 3，行動：真正付出實踐

  特征：

  我将在。。。之前。。。（例如我将在周二之前完成這個任務）

• 1，需要/适當
• 2，希望/但願
• 3，讓我們（而不是我）

2.2 真承諾應該怎麼做

2.2.1 團隊的角度

• 1 ，如果目标還依賴于另一個團隊的子產品，應該

• 和另一個團隊理清子產品間的依賴關系；
• 建立接口，對依賴關系進行抽象；
• 每周至少三次與同僚碰面，來确自己對代碼的修改沒有影響整個系統的建構；
• 編寫自用腳本，對子產品進行測試

• 2，不确定是否能完成，仍然要全力以赴

• 如果無法修複釋出前的bug，任然應該把bug全部過一遍并重制它們，利用本周能支配的全部時間，努力逐一修複bug。

• 3，真的無能為力

• 盡早向承諾的對象發出預警，讓别人調整期望。這樣項目組還可以研究是否采取行動、挖掘可行方案、頭腦風暴等來達成目标，或者調整優先級，讓你先修複簡單的bug；
• 如果不盡早告訴他人問題，就錯失了讓他們幫助你達成目标的機會。

2.2.2 個人角度

• 1，堅守原則。

• 不會為了盡快完成任務，而放棄底線（開發規範）。
• 了解自己的能力，清楚自己保持效率加班的時間，明白要付出的代碼

• 2，努力尋找創新的方法，盡可能做到有求必應。
• 3，做出清晰、正式的承諾，確定各方明白無誤的了解内容。

3 總結