弱爆程序員的特征值
首先說明：
1、以下特征是真實遇到過的，同事犯過的，乃至我自己也犯過的；
2、為了劇情需要，某些例子進行了一些夸張修飾等演繹創作，如無雷同，請勿生氣；
3、如果你出現過以下癥狀之一，并不代表你就是弱爆了，但是如果你一直出現，乃至一說到這個大家就能聯想到你，那么你就得小心了；
4、如果你是集這幾個的大乘者，恭喜你，你已經找到了離開這個行業的充足理由了。
好了，搞定！
“那個Bug解決了嗎？”
“好了，搞定！”
“這么快？”
正當你非常欣喜的時候，就傳來了噩耗：剛才還能編譯成功的，就失敗了。（好吧，我們的集成編譯尚未成功配置上，理論上這種事情應該會被退回。）又或 者能編譯成功，但是呢，原來明明能起作用的一個下拉框，突然發神經的不起作用了。最隱蔽的莫過于，一切正常，但是當你看到代碼的時候，你就暈厥過去了。比 如我們曾經發現了一個Bug，簡單說就是每次用戶點擊某個東西，就會執行下面的這段C#代碼：
controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;
這個Bug很明顯會導致速度越來越慢，因為同一個更新操作會被更新N次，并且這個N會越來越大。其實這個Bug已經夠弱了，但是后來居然被修改為：
- controlPropertyPanel.PropertyChanged -= this.UpdatePropertyOnChanged;
- controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;
那估計是他的Bug
這段代碼能編譯，能執行，但是就是弱爆了。因為這不僅僅沒有從根本上去掉造成問題的邏輯，還會帶來更多的困惑：為什么要先減后加呢？
這類特征，請大家看看有趣的《各種流行的編程風格》，我這個例子算是一種撞大運。我覺這吧，這類問題都是因為只想解決一些表面的東西為目的，完全不管底下的其它任何問題而造成的。
“這個問題為啥還沒解決呢？”
“我覺得應該是他那里邊的Bug，我調不了。”
“哦……”
這個“他”可以是某一位同事，或者前同事，或者微軟，或者別的什么公司，再或者某個開源代碼的作者。這些個我都遇到過，比如說是另一位現在在職的同 事吧。當你告訴這位同事這個Bug似乎在他那兒，并且問問什么時候解決，他也許會很愧疚的立刻調試，可***結果卻仍然是開頭對話主人翁的所寫代碼的問題。
再比如說是微軟吧，那么對話可能就會包括：“啊，SilverLight真是爛，老是內存泄漏、崩潰等……”“是啊是啊！爛死了！早知道用 Flash了。”又或者會說：“微軟就是爛，Java就是好。”其實，我不想比較什么SilverLight還是Flash，.NET還是Java。因為 在討論這些問題之前，先***想想，這真的是別人的錯么？相信是其他人的錯是一件很簡單的事情，因為這樣推脫之后你就可以啥都不做了，反正不是我的錯。
如果真的發現了這是別人的Bug并證明了，那倒好說。但這種特征是一種純粹的懷疑，并沒有絲毫的證明。在仔細找了自己所有可能犯的錯之后，如果你懷疑是別人的問題，那請求證一下。
無圖無真相！
“樓主，無圖無真相啊！”
“樓主，無代碼無真相啊！”
“樓主，給翻譯一下啊！”
據說Linus在別人詢問Linux內存管理的一個什么問題時，回答道“Read the fxxxing source code”，很多時候我也有類似的沖動。我發現在信息發達的時代，不少人的閱讀能力、動手能力都嚴重退化了。這些人***就是你親自來幫他把問題解決了，他 才不想了解里面到底 發生了什么。這種問題體現在博客里面，就是寄希望于你寫得圖文并茂，圖嘛***花里胡哨同時言簡而意概，文字嘛***大段大段的代碼。其實圖不是重要的，只是 為了好看，重點是代碼，這樣他一Copy就可以直接解決他們的問題了。
比方說，Silverlight里面沒有各種圖像格式的編碼器，于是當你希望保存Jpg的時候怎么辦呢？Google一下，發現原來有人寫過一個 FluxJpeg的編碼器。下載下來一跑，唉還真能用哎。之后就直接簽入，也不捎帶看一下有沒有什么問題，或者設計不合理的地方。（其實真的有，會很慢， 因為有大量毫無必要的數組拷貝。）
又或者說，遇到了某個Bug，搜索一下發現，哎，還真有人遇到過，而且還有代碼哎！把代碼扒下來一跑，發現好像解決了，至于為什么就不管了。甚至還遇到過根本就不管解決不解決問題，反正代碼扒下來了就簽入了的。
再比如，寫一篇博客講解如何縮減.NET編譯出來的文體大小，其中提到許多概念需要先閱讀微軟官方的一個文檔。結果，還是會有人回復說，你那個文章里面提到那么多的Blob，也不說說Blob里面都有什么，大概是很不滿意吧。可是這個文檔里面都有啊，難道就不能自己閱讀一下？其實即便我連這個文檔都沒有給出，自己也應該有這個能力去進行思考，去動手尋找。
千萬不要退化成一個啥都要別人給你嚼爛了才能夠吞下去，吞下去也不會消化吸收的人。這樣的人大概別人給的是大便，只要有代碼無真相，也會照樣吃下去的。若真如此，那你打算如何提高呢？
那是個對象！
“這個ExpressionVisitor，它是用來干什么的？”
“……”
“好吧，或者這么說，他是一個什么東西？”
“他是一個對象！”
“啊？”
“哦，是一個對象的實例。”
大概這樣的回答，和那個微軟工程師說“你在直升飛機上” 差不多——反正你也不能說是錯的，但是就是沒什么意義。其實不知道沒啥問題，人又不是神，怎么可能都知道呢？不去仔細了解和學習問題也不嚴重，因為你可以 改。但是當你習慣性的隨便找一個絕對沒錯但又不說明任何問題的答案，甚至似是而非的東西來對付的時候，你就離弱爆的邊緣很近了。
當然，上面的對話也許是比較極端的。一個稍弱一點的對話版本是：
“這個內存泄漏是怎么造成的呢？”
“嗯，會不會是圖片放的位置不對呢？”
哈，還是很夸張對吧？沒辦法，寫博客有時候需要夸張的文字，否則你無法理解我的意思是：有時候，大家會傾向于從自己的記憶中尋找一些相似的物品，然 后選擇相似度自認為比較高的東西出來當作答案，而全然不管兩者之間的邏輯是否有哪怕那么一絲的關聯。也許很多時候，我們確實需要從相似的東西開始，但請別 把他當作終點。程序是需要嚴謹的邏輯的，所以你也必須非常嚴謹的去推演。
#p#
關于這類的問題真的太多太多了，比如我指著下面這段代碼當中的紅字：
var dictionary = new Dictionary<string, string>();
dictionary["someKey"] = “someValue”;
“這句話說明了什么？”
“說明dictionary是一個數組。”
集大成者
***我舉一個集大成者的例子，說，有個任務是要在SilverLight應用上面添加一個“收藏本站點”。好，怎么解決呢？網上一搜，發現有很多這樣的代碼：
- function AddBookmark(Url, LabeName) {
- if (document.all)
- {
- window.external.addFavorite(Url, LabeName);
- }
- else if (window.sidebar)
- {
- window.sidebar.addPanel(LabeName, Url, '');
- }
- }
然后直接扒下來就放上去了，通過某種方式在SilverLight中調用這段JavaScript，簽入，搞定了！結果到了測試那邊發現完全不能用，無論在IE6/7/8/9/10，還是在FireFox/Safari/Chrome上面，都不能使用。我問：
“這是什么原因呢？”
“不知道，反正瀏覽器報告沒有權限，可能是瀏覽器的安全設置原因吧，或者操作系統的Bug，也可能是瀏覽器的某種Bug？”
“不可能啊？這些代碼存在很多年了，要有問題早就能在網上搜索到了。”
“那也許是SilverLight調用的時候有什么安全問題。哎！SilverLight好煩啊！”
“那怎么還沒有解決呢？”
“好，我馬上解決它！”
很快，那段Javascript就變成了：
- function AddBookmark(Url, LabeName) {
- try
- {
- if (document.all)
- {
- window.external.addFavorite(Url, LabeName);
- }
- else if (window.sidebar)
- {
- window.sidebar.addPanel(LabeName, Url, '');
- }
- }
- catch
- {
- alert("您的瀏覽器因為安全設置的問題無法收藏，請手動添加收藏！");
- }
- }
看到這樣的代碼，我徹底震驚了。親自調試了一下，發現確實報告了一個“沒有權限”的異常。但是，我還發現，那個Url參數的值是 “www.adomainname.com\test\page.html”。那這不廢話么！瀏覽器認為你要收藏的是一個本地硬盤上的路徑，怎么可能在一 個Internet Zone上允許收藏這種路徑呢？我于是指著代碼問：
“這個Url是什么？”
“是一個變量”
“啊？”
“哦，不對，是一個參數。”
你是否也有類似的經歷呢？
