iOS 當公司有人向你提問，你該如何應對？
今天 因為iOS 開發的內部版本號耿耿于懷好久，釋然后讓我有了一個新想法：從前，能讓我興奮的點是解決一個有一個拗腦筋的問題，見大部分博客便知，都是技術方面的積累。
那么從今天起我決定讓自己有個新起點，我要為成為一名出色的架構師而努力奮斗了。
起因: 發布了新的測試包，為 iOS 2.0.0(2.0.0.2) ，項目管理人員，不懂括號是什么意思。
對話場景：
我：是內部版本號。
他：能不能寫成整數？
我：安卓是有的 （想起安卓是build 一個整數 只升不降）
他：iOS能也是整數嗎
我：不理解 你這么干的意義 版本號 包括一個或多個時期分隔的整數。內部版本號build也一樣，雖然簡單來說 每次要比上一次大，但是 用以記錄開發版本的版本號和發布版本號同樣重要，版本號的管理是一件非常謹慎的事情
他：是的，我只是想了解編號規則，外部/內部要盡量分開，盡量不能混淆
比如一個是2.0.0 另一個是412
。。。。。
中斷過程，我在我的幾個技術群里發起討論，全部回答不過于：“當然可以寫成整數，不過我不這么寫。”的結論
他來到我工位面前繼續討論
他：改成整數有什么問題嗎(應該是不滿意 我上面的回答)
這么改，內部版本號和外部版本號就分開了并且不混淆，結構非常清晰，并且 你會知道你這個版本打了多少個包
我：（1）內部版本號可以跟蹤每一個發出的版本，發出的錯誤 ，定位錯誤信息具體發生的位置
(2) 正式版本有利用外部版本號區分版本 做強制升級的作用，版本號分割的每一級別每一時期都有區分。當然內部版本號也可以發揮這個作用
(3) 參考了同行業人員，雖然可以，但并沒有人這么寫或者說這么寫的人不是大多數
他：這個理由不好 （應該是整數也可以blabla的意思）
我：如果你覺整數版本號能夠知道打多少包，有這個需求的話，分段式版本號是可以實現的，不覺得哪里還有不妥
。。。
剩下的過程，他一直強調我在緊張，我平常處理矛盾方式是，認慫和妥協來避免沖突。畢竟沖突時刻，不是用腦子用的是情緒。我不是緊張，而是一直動腦想表達分段內部版本號是謹慎，廣泛，友好的。
但是他的話術起左右了，說緊張我的音量就提高放大的告訴他，我怕他。。。（現在覺得我不該那么說，不夠理智，這是話術的作用，被對方一直揣測情緒變化，反而真的有情緒變化。根本原因 就是我不夠強大，心理和技術表達 兩個方面，唯一值得表揚的是技術立場的堅持）
上午，在爭論后，和一堆瑣事中結束，但是我的思考沒停止。
“這不是理由，我想聽理由。。?！? 如果是CTO，對技術人員來說很有指導意義，但是目前能對iOS產品端負責的人是我，有且只有我能負責iOS技術擔當和架構擔當， 我應該有充分的站得住的立場。
我想了好久，其實這還可以從好多角度去考慮這個問題。
重點來了：
（1）內部版本號到底該對誰友好？
內部版本號 應該是對開發人員有好的重要參數，記錄了每一個新產生的版本包括的內容產生情況和即每個build都記錄你的 ipa 包和套裝的聯系。 （整數并沒有體現對開發人員更友好）
（2）上面有提到 使用整數作為內部版本號，是小眾使用，如果出問題，是小眾問題，偏問題，解決效率大打折扣，存在一定時間內無解可能 。 而分段式版本號是最普遍業內人士開發者遵循并使用的。即使出了問題，也是大眾問題，也會是容易迎刃而解的問題。 （相比而言，我們不是一個技術創公司，比不上蘋果，微軟 我們拿什么膽量來 才承擔使用類似偏技術，小眾使用的方法規則帶來的后果）
(3) 知道產品迭代包的個數 ，或者怎么能清晰表達產品迭代 這個是什么問題？
這應該是一個需求 不應該是技術選擇 。
技術選擇應該是架構師考慮的事，而不是項目管理替技術人員做選擇的事。架構師只需要規約成一個功能方案。達到需求目的
（此時方案已經和諧成了內部版本號最后一位做累加，直觀表示內部版本開發階段打包次數）
當然還有別的解決方案，比如做登記表，統計每一次打包 迭代內容，甚至把每一次打包都存到公司云管理上。甚至每打一個包都要打tag,方便用來復現和深度追蹤問題
并且打多少包還和測試程序，測試節奏有關系。
參考安卓，連續四天天打出的包都叫 1.1.0 (Build 28)這樣怎么追蹤問題呢？？ 是哪個具體子版本出了問題？目測只知道是第28個包，但是不出來是哪個內部版本，或者團隊合作打出的分支功能測試包之類的。（分段版本號的意義在此凸顯）
隨著公司不斷引進新的牛逼的技術人才，突然一眼看到我們的內部版本號不是分段的，是個整數。會不會對我們整個技術團隊的信賴感甚至公司的認同感都會大打折扣？
總結：
當有人 給你提問題的時候，你要動腦認真思考一下他問你的問題的本質。
他問的到底是個什么問題？ 這時候 不需要激情反對，也不需要完全妥協。
如果是功能性方面有需求，那么我們就應該用技術去翻譯 解決。
如果是技術上的問題，尤其是牽涉到技術使用了，那么提出的人是誰？
如果是CTO,你的技術主管，這個技術指導意義非常大，并且CTO能夠對技術使用負責。
如果是公司其他職位的人，向技術人員提出的問題只能是功能性質的問題，不能是技術問題，因為他們不會對技術負責。其次，有且只有你自己能對自己的使用技術負責。
說道這，真的覺得豁然開朗。
不是有沖突就不好，真的能讓自己成長。
參考：
1. https://developer.apple.com/library/content/technotes/tn2420/_index.html#//apple_ref/doc/uid/DTS40016603-CH1-VERSION_NUMBER_AND_BUILD_NUMBER_CHECKLIST
posted on 2017-11-29 23:45 ACM_Someone like you 閱讀(288) 評論(0) 收藏 舉報
浙公網安備 33010602011771號