《開源架構那點事兒11》：軟體開發雜談

標籤：

雜談之一：技術只是成功的一點點基礎條件，真正還是得靠做人

話說，有位lianzi同學，水平不錯，思想超前，簽約阿里現在在百度實習，以前因為噴我的貼又沒有啥理由，因此告訴他離我遠一點，但是最近他又回到我群裡了，一直伸個大拇指，我說啥他都是大拇指，覺得怪怪的，總不是那麼個感覺，終於憋了一段時間，又恢複了正常的溝通方式，聊天實錄：

 

【傳說】杭州-悠然 18:31:13lianzi本色終於出來了。【傳說】杭州-悠然 18:31:30我學得這樣才是你自己，你天天伸個大拇指，我都覺得不像你了。【活躍】lianzi(756215798) 18:32:17哈哈哈，還好，還好【傳說】杭州-悠然 18:32:52活個本性挺好的，有時碰一下大家也理解的。碰完了繼續哥兒倆好不就可以了。【活躍】lianzi(756215798) 18:37:22是的

雜談之二：讓誰“爽”的問題

看產品經理的ppt，裡面有下面的一段話： 

做“產品”，不外乎“要想自己爽，先讓別人爽”。 永遠站在使用者的角度考慮問題。 細節、細節、還是細節。 根據實際情況排定優先順序比確定功能更重要。

 

深以為然，在做Tiny架構中，架構組做Eclipse外掛程式的同學其中做一個功能是執行器，他的方案是：開個喜好設定，然後由開發人員在裡面配置啥種類型的檔案由哪個類去執行。於是我問，如果有好多個執行器，開發人員不就配死了？於是他做了個功能擴充，增加一個大量匯入功能，可以批量導致了。於是我問如果有100個項目，100個開發人員，有100種 執行器，不同的項目需要的執行器又不一樣，是不是就得配100次設定檔，然後花大量的成本去分發這個設定檔，還得讓程式員花大量的時間去匯入這個設定檔？？關鍵是隨著項目的不斷變化，用的執行器是可變的，那麼上面的這個過程就得不斷進行，還涉及到一個版本維護的問題，比如有的人匯入了新的，而有的人還是舊的。這樣綜合起來得投多少人力物力和管理成本？我給的方案是：在開發執行器時配置一個執行器xml定義檔案，然後工程去掃描當前項目中的執行器xml定義檔案，於是工具開發人員只開發一次，每個執行器開發人員只配置一次，真正的使用者，啥也不用管，隨時都是最新可用，0工作量。兩個方案對比，工具開發人員工作量小了，執行器開者工作量大了可以忽略的一點點，最終使用者，節省了大量的工作量，關鍵是不會讓他們覺得使用麻煩，且不會出錯。

雜談之三：讓程式拋錯還是讓程式“正確”執行？

龍振東同學，一直在使用TinyDbRouter，也發現了裡面的一些BUG，也提了許多的改進建議。由於他是把代碼拉到本地在本地改的，我建議他直接fork我們的代碼，並在修改之後pull request給我們，這樣，對兩方都有好處。其中涉及到一個問題，他在QQ上問我如何處置：有些非標準SQL，SQL解析器不支援，他建議（實際上他前期就是這麼做的）在出現不支援的SQL異常的時候，改由讀寫分離方式去執行。由於當時在開車，是在電話裡和他溝通的，因此就沒有聊天實錄了，我直接敲字敲上來吧。

悠然：由於出現了SQL解析異常，說明這個時候SQL是不標準的，有可能是適用於讀寫分離，有可能適用於分庫分表，你不管採用哪一種方式進行處理，總有一種情況是用“錯誤”的方式去執行的，這樣就會導致出現非使用者期望的結果--而且這個時候，使用者得到了看起來正常的結果--因為沒有異常和錯誤發生，但是實際上結果是不正確的。這種處理結果比拋異常直接告訴他不支援這個功能嚴重得多得多，會直接害死你、害死你的老闆、害死你的客戶。所以，請直接拋異常，而不是改成前面的處置方式。如果這個SQL對你非常重要，那唯一正確的辦法是擴充SQL解析器，使之支援。你覺得怎麼樣？龍振東：然。

他很快就完成並提交給我，下面是溝通實錄：

【傳說】杭州-悠然 20:10:03以後就直接在我們工程上改吧。這樣就可以一起共用了。今天我給你電話裡講的原則，在工作中一定注意了。否則你給捅大摟子的要:)【話嘮】龍振東(593038106) 20:11:37一些有爭議的地方我都會先提出來討論【傳說】杭州-悠然 20:11:54嗯嗯，我給你講個故事吧。我們這邊有個非常牛X的人。看到另外一個人寫的程式有個問題：就直接反編譯然後改了就弄上去了，結果問題確實沒有了。他也不和別人說這個事兒，結果後來升級的時候一搞，這個修改丟失了。結果出了非常大的亂子。又有一次，他又和另外一個程式做對接，結果他想獲得人家內部的資料。【冒泡】杭州-cwl(150326161) 20:14:07我感覺說的是我。。。【傳說】杭州-悠然 20:14:16人家裡面的資料是private的，他改改存取控制，然後就訪問到了人家的private資料。然後他得意的爽得不行。【話嘮】龍振東(593038106) 20:14:51後來呢【傳說】杭州-悠然 20:14:55結果過了一段時間，又他媽的出大問題了，原來人家把private的對象改名了。還有一次，他又是修改訪問設定，訪問了人家的私人方法，這次啥也沒改，結果又他媽的不行了。死活無法跑，結果這牛叉人物到現場，跑北京搞了好幾天，終於查清了，原來是在Oracle JDK可以突破安全訪問私人方法，但是在AIX下的IBM JDK突破不了了。所以：千萬不要耍小聰明，會吃大虧的。在電腦領域一定要嚴謹，要按常規的正常途徑來解決問題。

雜談之四：再論緩衝相關代碼的演變本人寫過一篇關於緩衝方面的文章，可以通過點擊上面的連結去查閱。有許多人回複，有些人覺得不錯，有的人覺得不好，各說各有理。其實電腦領域當中，解決一個問題，可以有N種方案，有時他們的差別非常小，這個時候就需要仔細斟酌了。這不，周末大家又問了：

【活躍】lianzi(756215798) 10:03:18早，現在不知道看什麼技術文章啦，昨晚睡覺前看了篇悠然和hasor的部落格就是那篇緩衝重構調優的邏輯是很清楚的，至於最優解，鬼知道【傳說】杭州-悠然 10:05:45下面不是被噴了麼:)【活躍】lianzi(756215798) 10:07:19好吧，那最後的最佳化方案是什麼呢？實際效果如何呢？【傳說】杭州-悠然 10:07:40實際，我們用得感覺還不錯。maven外掛程式？【傳說】杭州-悠然 10:07:58關鍵是避免程式員參與緩衝方面的事情。由於通過Maven外掛程式動態內嵌程式碼，因此效能方面也非常有保障。【活躍】lianzi(756215798) 10:08:52這個說法，我覺得，要看情境如果小弟不怎麼給力是好事，但是程式員在調試代碼的時候怎麼辦？至少內建個http server 有個緩衝的dashboard你覺得呢？【傳說】杭州-悠然 10:09:46其實你可以理解成一種AOP處理。程式調試代碼，就是全部從真實資料庫取資料呀。又沒有任何影響，用Maven命令處理過，只是通過緩衝加速了而已。【活躍】lianzi(756215798) 10:10:57我的意思是這樣子的，緩衝應不應該對程式員透明【傳說】杭州-悠然 10:11:28我們的選擇是透明。【活躍】lianzi(756215798) 10:11:39認同【傳說】杭州-悠然 10:11:48文章中說了諸多好處，尤其是一種緩衝方案換成另外一種緩衝方案的時候。關鍵是避免程式員參與緩衝方面的事情。【活躍】lianzi(756215798) 10:12:02是，邏輯清晰【傳說】杭州-悠然 10:12:07選擇透明的方式，只要架構師或高程完成就好了，原有代碼不用做修改。【活躍】lianzi(756215798) 10:12:19我們老大也經常罵我，說要把故事講完整【傳說】杭州-悠然 10:12:25上次我們從MC->Redis，那代碼改得，都吐血了。【活躍】lianzi(756215798) 10:12:53沒做抽象層？【傳說】杭州-悠然 10:13:01如果再從Redis->另外的方案，不是又要吐血了？【潛水】上海-雲卷江南(25269626) 10:13:08改個實作類別不就行了【傳說】杭州-悠然 10:13:31如果你做了抽象層，使用的就一定是KV的。如果要深層次使用，就麻煩了，有的支援有的不支援。但是技術肯定是雙刃劍，有好處也有壞處。【活躍】lianzi(756215798) 10:14:53這個我理解【傳說】杭州-悠然 10:15:06如何發揮好處，避免壞處了。即使是搞了抽象層，我在文中也寫了，到處是處理緩衝邏輯的代碼，也是不好的。【潛水】上海-雲卷江南(25269626) 10:15:43簡單用【傳說】杭州-悠然 10:15:53所以，比較好的辦法就是採用面向切面的方式進行處理。【活躍】lianzi(756215798) 10:17:25這個我認可，一開始設計的就有問題

這裡，又是我經常說的一個話，好軟體是“品”出來的，當一個問題有N種解決方案的時候，就要把各種方案仔細品味。 雜談之五：新人心態的問題

【活躍】lianzi(756215798) 10:20:14每每看到oscer說剛畢業的學生會什麼的時候，我都在思考，應該多向前輩學習，但心裡總有點不爽哈哈，也許是初生牛犢不怕虎吧【傳說】杭州-悠然 10:23:25不知我的故事，有沒有給你講過。我剛畢業的時候，第一個網名起的是叫高手來著。【活躍】lianzi(756215798) 10:23:48沒呢，然後呢【傳說】杭州-悠然 10:24:03當時心態估計和你差不多，總覺得你畢業多幾年有個啥用，我照樣比你強。後來過了一段時間，默默改成：學習中的高手又過了一段時間，默默改成：學習中的低手到現在，哥已經不敢說哪一塊是NB的了，覺得啥也瞭解不夠深入。【潛水】上海-雲卷江南(25269626) 10:25:15我也畢業不久【活躍】lianzi(756215798) 10:25:23悠然，我覺得我還算虛心好學【傳說】杭州-悠然 10:25:43嗯嗯，不錯的苗子。【潛水】上海-雲卷江南(25269626) 10:25:44事實就是很多人經驗根本和能力沒什麼正相關【傳說】杭州-悠然 10:26:18你要知道，在戰場中打得猛的，打得準的，都已經死掉了。【潛水】上海-雲卷江南(25269626) 10:26:34越來越謙虛是因為自己無知，而不是隊友強大【傳說】杭州-悠然 10:26:57偶爾有幾個活下來的，那就英雄了。活下來的，都已經不再標榜自己打得准，躲得好，只是說：運氣好一點而已。所以，年輕人麼，適當藏一下鋒芒是有益於發展的。【活躍】lianzi(756215798) 10:28:48悠然說的很對啊【傳說】杭州-悠然 10:29:23你看看所有獲獎感言當中，沒有哪一個說：因為我ＮＢ所以，我才...而感謝這個，感謝那個，感謝邊邊角角的人物。【活躍】lianzi(756215798) 10:29:39浸染了奮鬥的淚泉，腮邊了犧牲的血雨【傳說】杭州-悠然 10:30:04一個用來展示自己的感恩之心，二來是因為這些人的成功不一定主要是邊邊角角人的功勞。但是如果讓他們不爽了，他們一個小小的“失誤”就可以廢了你的大好前程。你再NB，做的東西，也不可能一點瑕疵也沒有。【潛水】上海-雲卷江南(25269626) 10:31:18 好高深的樣子【傳說】杭州-悠然 10:31:19當你有一點瑕疵，就會被人攻擊致死。【活躍】lianzi(756215798) 10:31:22山水有相逢，悠然的卻是管理者的心態，悠然悠然啊【傳說】杭州-悠然 10:31:32我再給你講一個例子。有一個以前阿里的架構師，水平，那是一個高。用他的話來說：除了看我感覺順眼點，其他沒有一個他會看在眼裡的。【活躍】lianzi(756215798) 10:32:55很高的評價，這個人有問題，我覺得【傳說】杭州-悠然 10:33:06但是因為鋒芒太盛，被剝得人無一個，槍無一條，完了還讓人家說他水平太差。所以，別標榜自己水平多好，能力多強，紮紮實實做事，老老實實做人才是正點。

雜談之六：工作年限與水平的關係

【活躍】lianzi(756215798) 10:37:47這個我覺得和經驗關係更大 <span></span>【吐槽】上海 浩子(120195645) 10:38:49什麼事情，都應該與實際進行權衡【傳說】杭州-悠然 10:39:02所以比較拽的架構師，可以把工作並行起來。就是說大家各做做的，到時可以組到一起來，又不費什麼工作量。【活躍】lianzi(756215798) 10:39:29為什麼呢？因為踩過的坑比較多是吧雙擊查看原圖【傳說】杭州-悠然 10:39:36當然，這個層次就有點高了。【活躍】lianzi(756215798) 10:43:05這個我認，現在還是學習階段，多踩坑吧【傳說】杭州-悠然 10:43:49當然，這裡的經驗，不等同於工作年限。但是同樣努力用心的兩個人，工作三年和工作一年，差別還是非常大的。【活躍】長沙-Sept() 10:45:13體系是自底向上構建出來是 最終的表現 始終受到基礎影響基礎構造決定啦 最終的極限與瓶頸【活躍】lianzi(756215798) 10:46:12恩恩，說得好【傳說】杭州-悠然 10:46:16所以，我有個說法，就是工作3，5年說做一個多麼先進的架構還是為時尚早的，當然實驗性的沒有問題。【活躍】長沙-Sept() 10:46:22@lianzi 基礎構造的限制 可以說已經決定 結果最高極限 了【傳說】杭州-悠然 10:47:11因為，你局部的實踐能力和技術的應用能力應該是有的，但是整體宏觀視野肯定是有不足的。這個你去看人家的架構，也只是看得外部，內在的一些因果關係，根本不清楚的，有一定理解也是不完備的。用Sept的話來說，你的起點決定了你的終點。你期望說後面再去補充，這個成本是非常高的。就好象你想蓋個大樓，前面沒太想好，就直接上手蓋，期望中間進行不斷修正就可以蓋出大樓來。但是到最後的時候，發現根本沒有辦法進行調整好讓它轉向正確的方向。

細細品味！ 

 

 

歡迎訪問架構論壇：http://web.j2ee.top。本例涉及的代碼和架構資料，將會在論壇分享。《自己動手寫架構》成員QQ群：228977971，讓我們一起動手，瞭解架構的奧秘！ 

《開源架構那點事兒11》：軟體開發雜談