第一屆開發者寫作松，軟體工程師軟實力系列第二篇
第一篇文章提到，完美主義的人心中那把尺，會比其他人來的嚴厲些。這篇文章要延伸探討的是，那把尺的標準有哪些？如果想要提高對自己的要求，有哪些層面？太過講究完美的工程師，是會累死自己還是做出品質優良的產品？
完美的定義
完美來自個人的刻板印象和價值觀，以及對產品原型設計的解讀。
ＡＰＰ開發的完美有分很多面向和角色：
1.看得到的完美，例如符合使用者習慣、流程順暢不卡關，滿足所有需求
2.看不到的完美，例如乾淨的程式碼、架構完整、易於維護擴充的設計
使用者的完美
例如下圖的貓咪夜燈，看到圖一就很容易會認為這是有缺陷的產品，因為圓滑的外框就會引導使用者認為整體都會是圓滑的，而圖二則是使用者認為這個產品原有的樣子。
也就是說：
符合使用者認為這個產品應該有的樣子，就是完美。
這是ＡＰＰ完美的第一關：滿足需求及市場價值。如何提升呢？
隨時隨地看看ＡＰＰ商店上有哪些產品，好的看優點、壞的引以為戒，自己就是使用者，才會了解普遍使用者的需求，這就是為什麼在我剛進入iOS開發時，前輩告訴我：
要當一個優秀的iOS工程師，就一定要有自己的iPhone。
產品經理的完美
對一個產品經理來講，無論這個產品經理重視的是品質還是業績，幾乎所有產品經理要的都是：快速有效率少BUG的穩定產出。
而大部分的工程師都會回應：那是不可能的。
那在不可能的國度中，工程師到底要怎麼生存？
首先要有一個認知：品質和時間不一定永遠選同一個，通常都有順序和嚴重程度的差異，因此排緊急優先度就是開發順暢的關鍵，但這通常都是產品經理在排的，開發者能做的，是讓產品經理了解任何決定背後的影響和成本，以及未來潛在問題，最後溝通出開發順序及相關應變配套措施，就自己能力所及達成產品經理需求，就成為不完美中的完美法則。
每個人的需求都不一樣。
團隊的完美
每個團隊有各自的文化和習慣，也有各自的盲點和問題，所謂的完美，就是在現有條件下達成平衡並且隨著時間進步。
無論是對外部或高層能交出漂亮的績效，還是對內部有高度凝聚力和應變能力，團隊氣氛的營造都是不可或缺的，但既然是科技人，就用科技解決人的問題！以下是過往團隊嘗試過的幾個方式：
1.用看板簡化開發以外的瑣事及會議紀錄。
2.編寫團隊開發規範，包含CodeReview、CodeStyle、相關教程。
3.不定期討論科技產品、應用、議題。
4.參與外部活動並與團隊成員分享。
5.與其他部門共同協辦讀書會，例如UX、QA等等。
除了管理的範疇，技術交流成為開發團隊優劣的關鍵，除非面試官有把握每一個錄取的人都是高手且技術水平相當。
能有技術交流的團隊，才有前瞻性，而不是一群外包工程師坐在同一個辦公室裡。
開發者的完美
當年同事笑我說：開發iOS的毛都很多。
但現在我必須承認，隨著開發經驗增加毛會越來越多……
在學習過程中，經歷了幾個階段：
1.剛入行的菜逼八，每天提心吊膽怕自己做不出功能，能完成就已經不錯了，De一個BUG生四個都是家常便飯，就靠毅力和不服輸撐下去。
2.熟能生巧後效率提升，開始思考如何提升品質減少BUG。
3.功能產出已經不太是煩惱後，就能深入學習程式架構和設計模式。
4.自己專案已經沒什麼大礙後，開始往Library或UI、UX延伸。
但寫乾淨的程式碼，是打一開始就必須有的認知，就算永遠一個人開發，看到一堆垃圾也會增加維護成本，千萬不要覺得自己不會寫出沒有用的程式碼，過了一年回頭看自己Code覺得寫很爛的大有人在。
生命是長期而持續的累積，程式碼也是。
完美的過程
毛這麼多，中間不會遇到什麼障礙嗎？事實是我遇到的心理障礙比技術障礙還要多很多……
菜鳥階段，通常都會有幾個共同的問題：
1.我無法解決，但前輩很忙不知道該不該問？
2.想寫的更好但一直優化就無法有實質產出。
如何提問
首先針對問問題這件事來講，先確定前輩是給問的，不要一道牆在那卻偏要去撞，有些人就真的不喜歡跟別人互動，但那真的是少數，大部分的情況是他也不知道要怎麼跟你互動。
不是因為面對電腦而對社交生疏，而是因為沒有社交機會所以生疏。
曾有個ＰＭ把開發工程師形容成一群老實天真又聰明的小動物，心中沒有太多心機，眼裡只有程式碼。無論原本什麼科系背景，能在這個職業穩穩待著的肯定有兩把刷子：能忍受坐在電腦前面至少八小時、能不斷的學習新知。
因此無論是新的舊的團隊成員，都要把交際這件事情考慮進去，不是有問題就問或因為怕碰壁就完全不問。
三個重點：
1.適當的提問，不要什麼都沒試過沒準備就問，同事不是你的Google大神，但也不要跟悶燒鍋一樣悶著，爆炸了讓別人收攤，通常我建議的範圍是半天到一天，同一個問題解決不了就去問。
2.挑對時間問，例如知道前輩準時下班就不要下班前問，提問前先問一下有沒有空是基本禮貌。
3.挑對問題問，通常會有一段問問題訓練期，如何精確地表達過程和重點，真的是一項必備技能。
提問真的是一門藝術，跟溝通一樣。
我原本就是個問題兒童，不過也因為就是有太多問題了，所以也連帶訓練出解決問題的能力，也就是工程師的本質。問問題絕對沒有錯，前提是問對了問題，但最差的情況是新人都沒有問題，就算他天資聰穎也不會完全了解專案需求和過往紀錄。
黃金Coding期
真的很有意思，就像寫作需要靈感，寫程式碼似乎也需要有Fu，在走向完美的路上，碰壁了怎麼辦？
1.先不要寫，離開當前環境和狀態(喝個水上廁所)，有助於跳脫盲點。
2.找個人聊聊。
3.靠自己判斷是否缺乏資源，先補強缺乏的部分。
延伸：小黃鴨偵錯法
這真的是一個認識自己的過程，知道自己卡住時該怎麼辦？哪時特別容易卡？哪時思緒特別順暢？順的時候要如何避免被別人打斷？
優化和功能產出不是二擇一
就跟品質和業績共存的道理一樣，因此我才會特別強調clean code，在寫下的那剎那就確保是乾淨的，比事後檢查修改來得更有效率，但要做到就必須要刻意練習。
當每次寫的Code都是當時能力所及最好的品質時，就能提高進步速度，過了一個門檻後，這種落差就會逐漸減少，但一樣是靠溝通，或是需要團隊支援，這都沒有絕對的答案。
不完美才是最完美？！
回到完美主義的問題，當過了新人期後，仍然追求完美卻無法如願時，怎麼辦？
一個產品的成敗，不是技術決定一切。
從產品的產出過程：解決問題的初衷、外觀設計、使用流程設計、各種軟硬體技術克服、各種前後端資料串接、行銷推廣、商業模式等等各種面向。即便有了極為優秀的技術團隊，但產品無法被大眾接受，仍然會是失敗收場。
產品核心概念也決定著成敗，有些產品每個方面都看似平庸但卻被市場接受，有些產品有非常突出的亮點但卻是小眾需求，創新的設計往往需要時間被習慣和在地化。
有些情況在業務與專案管理的立場，沒有完成的產品基於各種考量上線，可能更優於完成所有功能後才進入市場，但這些都不是一個技術職原本在意的事。
了解除了技術以外的各種面向後，就會發現原本的不完美，似乎也沒那麼糟？
完美的副作用
工程師容易有強迫症？
這絕對是因人而異，但一個長期訓練專門挑問題毛病並負責解決的職業，肯定比其他職業有更高的機率有相關的職業病，由於我不是本科系，因此在工作幾年後就能看出跟同學間有明顯的差異和變化。
發現自己有傾向時怎麼辦？只能不斷告訴自己工作以外的地方不要那麼執著，執著也沒錢賺。但一個高壓力久坐的工作，心理健康和身體健康都顯得非常重要，有正確的心態和健康的身體，才能穩定的發揮自身價值。
吃得很隨便、穿得很隨便，寫出來的程式碼卻一點也不隨便。
放下還是理解？
生活上沒啥問題，但工作也很強迫怎麼辦？也許對專案有更多層面的了解，會有所幫助，例如去了解產品經理怎麼看？有些時候其實沒那麼完美也沒關係。畢竟在團隊中，產品不是屬於自己而是團隊的，很多時候溝通比成果重要，過猶不及。當別人都要你放下而你卻放不下時，有更多的理解才有助於突破瓶頸。
佛祖給的答案都相同：「只要放下，你就能不再煩惱。」
結論：放下屠刀立地成佛。
