軟件開發(fā)雜談

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

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

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

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

看產(chǎn)品經(jīng)理的ppt，里面有下面的一段話：

做“產(chǎn)品”，不外乎“要想自己爽，先讓別人爽”。   
永遠(yuǎn)站在用戶的角度考慮問題。 細(xì)節(jié)、細(xì)節(jié)、還是細(xì)節(jié)。 根據(jù)實際情況排定優(yōu)先級比確定功能更重要。  

深以為然，在做Tiny框架中，框架組做Eclipse插件的同學(xué)其中做一個功能是執(zhí)行器，他的方案是：開個首選項，然后由開發(fā)人員在里面配置啥種類型的文件由哪個類去執(zhí)行。于是我問，如果有好多個執(zhí)行器，開發(fā)人員不就配死了？于是他做了個功能擴展，增加一個批量導(dǎo)入功能，可以批量導(dǎo)致了。于是我問如果有100個項目，100個開發(fā)人員，有100種 執(zhí)行器，不同的項目需要的執(zhí)行器又不一樣，是不是就得配100次配置文件，然后花大量的成本去分發(fā)這個配置文件，還得讓程序員花大量的時間去導(dǎo)入這個配置文件？？關(guān)鍵是隨著項目的不斷變化，用的執(zhí)行器是可變的，那么上面的這個過程就得不斷進(jìn)行，還涉及到一個版本維護(hù)的問題，比如有的人導(dǎo)入了新的，而有的人還是舊的。這樣綜合起來得投多少人力物力和管理成本？ 我給的方案是：在開發(fā)執(zhí)行器時配置一個執(zhí)行器xml定義文件，然后工程去掃描當(dāng)前項目中的執(zhí)行器xml定義文件，于是工具開發(fā)人員只開發(fā)一次，每個執(zhí)行器開發(fā)人員只配置一次，真正的使用者，啥也不用管，隨時都是最新可用，0工作量。

兩個方案對比，工具開發(fā)者工作量小了，執(zhí)行器開者工作量大了可以忽略的一點點，最終使用者，節(jié)省了大量的工作量，關(guān)鍵是不會讓他們覺得使用麻煩，且不會出錯。

雜談之三：讓程序拋錯還是讓程序“正確”執(zhí)行？

龍振東同學(xué)，一直在使用TinyDbRouter，也發(fā)現(xiàn)了里面的一些BUG，也提了許多的改進(jìn)建議。由于他是把代碼拉到本地在本地改的，我建議他直接fork我們的代碼，并在修改之后pull request給我們，這樣，對兩方都有好處。 其中涉及到一個問題，他在QQ上問我如何處置：有些非標(biāo)準(zhǔn)SQL，SQL解析器不支持，他建議（實際上他前期就是這么做的）在出現(xiàn)不支持的SQL異常的時候，改由讀寫分離方式去執(zhí)行。 由于當(dāng)時在開車，是在電話里和他溝通的，因此就沒有聊天實錄了，我直接敲字敲上來吧。

悠然：由于出現(xiàn)了SQL解析異常，說明這個時候SQL是不標(biāo)準(zhǔn)的，有可能是適用于讀寫分離，有可能適用于分庫分表，你不管采用哪一種方式進(jìn)行處理，總有一種情況是用“錯誤”的方式去執(zhí)行的，這樣就會導(dǎo)致出現(xiàn)非用戶期望的結(jié)果--而且這個時候，用戶得到了看起來正常的結(jié)果--因為沒有異常和錯誤發(fā)生，但是實際上結(jié)果是不正確的。這種處理結(jié)果比拋異常直接告訴他不支持這個功能嚴(yán)重得多得多，會直接害死你、害死你的老板、害死你的客戶。  

所以，請直接拋異常，而不是改成前面的處置方式。如果這個SQL對你非常重要，那唯一正確的辦法是擴展SQL解析器，使之支持。你覺得怎么樣？  

龍振東：然。  

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

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

雜談之四：再論緩沖相關(guān)代碼的演變

本人寫過一篇關(guān)于緩沖方面的文章，可以通過點擊上面的鏈接去查閱。有許多人回復(fù)，有些人覺得不錯，有的人覺得不好，各說各有理。 其實計算機領(lǐng)域當(dāng)中，解決一個問題，可以有N種方案，有時他們的差別非常小，這個時候就需要仔細(xì)斟酌了。 這不，周末大家又問了：

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

這里，又是我經(jīng)常說的一個話，好軟件是“品”出來的，當(dāng)一個問題有N種解決方案的時候，就要把各種方案仔細(xì)品味。

雜談之五：新人心態(tài)的問題

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

雜談之六：工作年限與水平的關(guān)系

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

細(xì)細(xì)品味！