妥協

妥協

黃弘 做於 2015/11/02 01:20

零. 完美主義者的自我意識

不隱瞞的說，我是一名重度「拖延症」患者。也許從我出生開始就在本身跟本身較勁、擰巴，拒絕妥協卻從不表態，由於我也不知道我在堅持什麼。

小時候爸媽以異常節儉的方式表如今我面前，他們偶爾「大方」一下要給我買點什麼褲子、鞋子，我老是堅持不要。我不知道我爲何不要，總之我就是不想要，因此他們就猜想究竟是沒知足我什麼，是顏色仍是款式，以爲我很犟。

個人確很犟，由於我女兒也這樣。因此我反而懂她了——很奇怪的反應。

有時候我對本身要求完美，要麼滿分要麼鴨蛋。高中時跟語文老師對着幹，只要是他的課我就不上；要麼不交做業，要麼寫完一整本的做文。與其鬥，可謂其樂無窮。

後來也知道本身不是那塊料，就再也不寫文章了，改寫代碼。但惋惜的是代碼總有個時效，你總得依賴某個環境而存在，而環境老是在變。Java 1.4 用到如今 8，PHP 4.3 用到如今 5.3，聽說 7 都出來了。其餘喜歡的 Perl, Python 亦如此。我想寫個長久的東西，但過不了幾年再看就是垃圾，或代碼樣式陳舊得讓人難受。

好比個人開源項目之一 HongsCORE 從 11 年末啓動到如今都 4 年了，總共規劃的 4 個系統只勉強出來這麼 1 個管理系統，大量的時間在折騰框架上，並且越折騰還越來勁。

尤爲是在命名和代碼對齊上，耗費的時間可能就佔了一半，爲此沒完沒了的重構。命名倒不是由於用的詞意思不對，而是——不能對齊，或不能呈現某種簡單的規律。好比都是 6 個字母，或依次 三、四、5 個字母，或按功用某些類必須排列在一塊兒且有前後順序，巴不得想給類名都加上 0一、02 的前綴。

這可能就是有些人還大讚的「完美主義」吧。而我卻深受其害，進度受此拖延。爲了緩解本身的「症狀」，我就去開發了一個「數據管理」的模塊，這下建表、字段愛叫啥叫啥了，由於底下都是代號，一串無特定意義的 36 進制數字（0~Z），並且還故意設計成不可人爲指定；展示上某份數據、某字段今天叫張三明天改叫李四無所謂，不再用爲命名糾結了。

但總有其餘的事縈繞在你腦海——只要你沒「治療」好你本身。好在現實老是在該讓你醒醒的時候就給你澆一壺涼水，2012 年就被猛的澆了個透心涼，而後竟然就特麼大徹大悟了，悟出了一劑良藥：妥協。

一. 咱們要妥協什麼

由於本身嘴笨，每次講這個話題都講不清本身內心的意思，結果給人的感受就是：他這個老油條，又在講買菜理論，要討價還價了。而我在家根本不買菜也從不砍價。

過去在不一樣的單位觀察，總結成功的項目和失敗的項目，發現一個你們都知道的沒鳥用的現象：成功的項目每每有個「老傢伙」在「管事」。相反新提拔起來的開發人員去作項目管理一般會出問題，要麼成員不服作鳥獸散，要麼常常無法定期交付，儘管你看他是那麼的努力。

是「管理」經驗問題？我歷來不相信對開發人員有何「管理」經驗，這是一羣聰明透頂的人，喊口號、講人生、畫大餅、立規矩那套壓根行不通，若是你相信他有用我告訴你有效期是半小時。惟一對全部人一樣有用的我相信只有利益，實實在在的東西——這是幫絕頂現實的傢伙。

他們要妥協什麼、能夠妥協什麼呢？基於預期收益對目標的妥協。如今都是一條繩上的螞蚱，你好我好他也好，其餘部門都眼巴巴的看着，你們都等着了，能作出來你的代碼就沒白費，休假、腐敗、獎金、加薪，打臉也要去申請。不談利益瞎扯淡的那都是耍流氓。

要別人妥協什麼呢？定稿、定稿、定稿，重要的事說 3 遍，意思就是：哥們，咱們要衝了，您可路指得準點，別讓我端着槍跑出一里地了你又喊跑錯啦，回來~回來~，我得回得來呀。

二. 妥協是一種堅守

你不得不面對一個問題，什麼時候本身該妥協，什麼時候對方該妥協。彼此應當總有本身要去堅守的東西，要麼爲了維護系統的統一或穩定性，要求對方作出妥協；要麼對方堅持推出與競爭對手有差別的產品，你作出妥協。不管哪方作出妥協，風險老是明確的存在，可能推遲、可能將來維護困難、可能作完了也就完了毫無特色。

每一個人都在大談堅持，但事實上不管你是堅持仍是放棄都是錯的，前進是坑、後退也是坑，只是大部分人只知道後腳跟處有個坑，殊不知道大霧瀰漫的前方也是個大坑。進老是要進的，坑老是要填的，要看爲了什麼而捨棄了什麼。

讓他人妥協，是堅守本身的價值；對本身妥協，是堅守本身的利益和羣體的目標。

三. 如何讓對方妥協

有人以爲，我就一底層寫代碼的，要佔據主動，推進別人走，怎麼可能？

做爲一名智商不高情商也 Low 的笨碼農告訴你，你行的。若是你情商夠高可直接跳過此節，由於對您實在沒神馬有價值的建議。對一名搞不來人情世故，不會玩、不會來事的宅男來講，有效的讓對方作出讓步的方法只有一個：讓對方感覺到風險，而非藏於心裏深處。

看過《三體》的朋友應該知道，第二部《黑暗森林》中 4 位「面壁者」中的 3 位相繼被「破壁」，只有大宅男羅輯成功的阻止了三體的入侵，而其方法竟然是「威脅」：告訴你三體人，你要滅我，我就在你滅我以前廣播座標，我們全完蛋。

固然不是要對本身的上司、同事用如此歹毒的招數，當量要縮小些，對相關人作不到動之以情就要作到曉之以理：我能夠按你說的作，但這會帶來不肯定的安全性，緣由在於……同時破壞了系統的統一性，原本此類問題能夠複用某某模塊，如今由於增長的特殊需求，而某某模塊因爲過去並未考慮到這種可能沒法細分……由於這些額外的需求致使部分東西必須從新開發，時間上須要延期……總之，若是您堅持這麼幹我們就這麼幹了……

你必須把你的擔心說出來，你的同事、上司是個明白人的話會仔細考慮清楚的，若是他能承擔那你也可安心去作，且可能因部分不肯定性爭取到合理的時間，他也好作出充分的防風險準備。

透明多是三體的弱點，換個角度可能就變成優勢。

四. 能夠沒用的私貨

我不知道爲何，我從小就喜歡這 4 個字，「能夠沒用」，我在個人書本上處處畫滿這 4 個字。有用沒用不重要，重要的是你在思考。

a. 開發原則

人多、時間緊，代碼寫很差？我有招：

1. 獨立原則：設立公共庫，項目突擊期不得往裏面隨便加東西，各自的工具各自維護，待重構期再總結重用；

2. 特例原則：同1，不是對整個項目細節特別熟悉，對實現手段瞭如指掌，不要輕易作大規模封裝，封裝儘量是數據流經路徑可拆解的（反轉控制），避免遇到某個特殊問題而沒法特殊處理；

3. 就近原則：同1，相關的代碼應該儘可能的靠在一塊兒，或命名規範一致，如頁面 A 要用到一段獨立的腳本 B，不太長就放在頁面內，太大放到同一目錄下或指定目錄下同名文件中，看到 A 就能快速的找到 B。

b. 產品對策

實際工做裏並沒參與多少產品設計，以旁觀者的角度也提幾點：

1. 夯實基礎：設計稿應當是思惟發散的，先把主幹想清楚定牢固，枝葉就不容易被大風颳得東倒西歪；

2. 各個擊破：主幹肯定下來後若是時間倉促必定要逐個枝條充實完善，不要一層層的完善，由於理解老是有誤差，沒有細節開發很難保障與設計一致；

3. 最小文檔：相似就近原則，給開發的文檔要足夠小和集中，若是資源多必須分散，請肯定主文檔，並加好「連接」。

五. 寫此文聯想到的

《失控》 個人最愛 http://book.douban.com/subject/5989373/
《三體》 近年大熱 http://book.douban.com/subject/3066477/

我發現上面的標題很整齊，我很欣慰，該睡覺了