△Hollis, 一個對Coding有著獨特追求的人△

這是Hollis的第?251篇原創分享

作者 l Hollis

來源 l Hollis（ID：hollischuang）

最近全民開始了在家辦公模式，目前看來這種模式還要持續很長的一段時間，至少要到3月份才能有可能回到公司辦公了。

其實，在哪辦公對于程序員來說其實差別并不是很大，無非就是在哪敲代碼而已。

時間很快，從在家辦公開始，一直想說點什么，但是一直都沒落筆，現在已經兩周多了，是時候寫點什么了，這兩周給我最大的感受有兩點。

一、會議比以前多了

在家辦公之后，每天都是各種電話會議、視頻會議、語音會議等等。

在公司辦公的時候，只有有一些大事，如需求評審、設計評審之類的才需要開會，還有就是項目晨會或者團隊周會之類的。

但是在家辦公之后，每天會被拉著參加各種會議，以下是我某一天的會議日程：

從早上9點，到晚上8點，一直都有會議，甚至有時候還有很多會議時間是重合的。

這時候就體現出在家辦公的好處了，我就可以同時參加多個會議。釘釘視頻會議開一個，手機電話會議開一個。不需要我的時候我就把我的麥禁掉。

比如有些會議，我只是負責把相關人員拉在一起，大家討論下，最終得到一個結果，我發個郵件出來就好了。這種我就不需要發言，只需要聽著就行了。

還有的一些會議，如技術方案評審之類的，可能會議中只有一小部分是和我相關的，那么我只需要再討論這部分的時候開麥發言就好了。

如果是在公司開會，是不可能同時進行的，這反而大大提升了開會的效率。

二、砍需求砍得更狠了

我萬萬沒想到在家辦公帶來的一個變化，也不知道是好是壞，那就是：我砍需求砍得更狠了！

相信很多一線開發人員都和我一樣，每天都會接到各種各樣的需求，而給我們提需求的人也是形形色色。

而各種奇葩需求更是讓我們哭笑不得，但是大多數程序員在做過一些心理斗爭之后都會想辦法解決這個需求。

其實，所有需求都需要解決的，這沒錯，但是我還是給大家提一個建議：先用嘴解決需求，不行的話再用代碼解決。

在家辦公之后的這兩周，我負責的一個項目目前正處于聯調階段，但是這個階段還是會接到一些需求，這其中有些是產品經理提出來的需求變更、新增需求等，還有些是合作方技術提出來的有些技術需求，如要求接口同步、要求多一次系統交互、甚至要求ERROR_CODE的格式等等。

因為我負責的這個項目是個新產品上線，完全初期，要盡快上線接收用戶檢驗，沒必要一開始就搞的特別復雜。所以對于這些需求，目前的狀態是能砍則砍，不能砍的先用最簡單的方式先上去。

所以這兩周來，我越發的發現我砍需求砍的原來越狠了，甚至有一次，我團隊的另外一個同學問我一個單據的狀態問題，我隨口問了下問這個干什么，他說產品經理讓他實現個小需求。

我了解下來之后，就拉他和產品經理一起開了個電話會議，然后動之以情，曉之以理，把"不合理"的地方都砍了，把"能優化"的也都優化了。

本來需要2-3個系統合作才能實現的一個查詢功能，經過調整之后，變成只需要查詢一個系統就可以實現。這既減少了系統交互、降低了風險，又減少了用戶的理解成本。何樂而不為呢？

我始終認為，啥需求都接的程序員，一定不是個好程序員！但有些需求，總要有人先站出來砍！就算最后沒砍掉，我認為也是有好處的：

1、可以讓我們理解這個需求背后的東西。之所以最終沒砍掉，肯定是有很多原因在的，只有在討論的過程中我們才能更多的理解這些背后的原因。否則最后可能只是你毫不情愿的實現了一個你認為"垃圾"的功能，但是實際上可能這個需求背后有一些你不理解的原因。如合規風險、法務風險等等。

2、表達一個我們的態度。我覺得，作為一個程序員，態度還是很重要的。比如有些惡心的或者需求，我們可以"迫于壓力"去實現，但是我們還是有權利表達我們"不認可"的態度。而且這個表達的過程，也是你樹立話語權的一個過程。

我砍需求有很多考慮，但是減少工作量絕對不是最重要的。最近幾天砍需求，我大概總結了一下，用到的很簡單的幾個架構設計原則：

1、Keep It Simple ， Stupid

2、Open/Closed Principle

3、Single Responsibility Principle

4、Minimize Coupling

5、Avoid Premature Optimization

簡單點，無論是系統功能，還是系統代碼，最怕的就是復雜。越復雜的功能用戶越不喜歡，所以，如果一個功能很復雜，那大概率是個垃圾功能。

系統實現上面也是，如果一個功能，實現起來很復雜，那大概率會存在很多問題。而解決這些問題最好的辦法就是提前減少復雜度。

除此之外，要明確知道系統邊界以及系統關系，實現一個功能可能有100種方式，但是到底由誰來實現比較合適？如何才能降低系統間的耦合度？如何實現才有更強的可擴展性和可維護性？這些都是要考量的。

還有比較重要的一點，在初期，不要過早的做所謂的優化。記住：Done is Better than Perfect，

我們日常要接的需求中，有一些是業務需求，還有一些是技術需求。那么，有什么好的原則或者辦法可以參考呢？到底哪些能砍，哪些不能砍？到底應該怎么砍呢？

關于這些問題，我后面會寫一篇詳細的方法論，結合我工作中的例子，論如何砍需求。大家如果有更好的建議，或者對這個話題感興趣，可以給我留言，歡迎探討！

愿這個世界沒有需求變更！~

關于作者：Hollis，一個對Coding有著獨特追求的人，現任阿里巴巴技術專家，個人技術博主，技術文章全網閱讀量數千萬，《程序員的三門課》聯合作者。

- MORE | 更多精彩文章 -

• 恕我直言，有了這款IDEA插件，你可能只需要寫30%的代碼...
  

• 【阿里內推005期】阿里菜鳥（上海）招JAVA開發。
  

• 菜雞程序員是如何寫代碼的？
  

• 漫畫：大廠總提SaaS化部署，到底什么是IaaS、PaaS和SaaS？
  

如果你喜歡本文,

請長按二維碼，關注?Hollis.

轉發至朋友圈，是對我最大的支持。

好文章，我在看??

總結

以上是生活随笔為你收集整理的在家办公的我，砍需求砍得更狠了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。