除錯心法３

心法8：詳細的閱讀回報的錯誤訊息以及log file
發現有很多人對於系統回報的錯誤訊息內容視若無睹 , 然後拼命要找人幫她解決問題


舉例來說:
今天在協助別人除錯某個報表時 , 發現報表程序有被執行 ,但是沒有如預期的送出報表 email
試了幾次 , (沒錯 我自己也會耍白痴 , 對於該檢查的錯誤訊息略過 ,
不過我略過的原因是因為一開始我去協助除錯的時候 , 負責的人就告訴我 有錯誤產生是那個報表程序本來就會有的)


再看一次錯誤訊息 , 發現錯誤訊息中有一個項目是說: 報表程序找不到某一個目錄下的某個附件檔案
(這個報表程序是會發出Email 並且將特定檔案當作附件送出) ,


我去檢查了一下那個目錄 , 發現沒有那個檔 ,
然後我想辦法 造了一個 報表程序要的檔案 , 重跑了一次報表程序 就有正常的產出了



我協助除錯的範圍還滿廣的 , 系統的設定 , 程式的內容 , 一些阿貓阿狗的問題
都會丟到我這裡來 ,
也算是同事長官們看的起我 , 給我機會 ,


我想說的是 在外人眼裡 , 我除錯可能就跟喝水一下 , 幾乎都能解掉 ,
就算不能解掉 , 也都找出問題的癥結 ,


我可以跟大家說 , 那些問題其他人 100% 也都能解的出來 , 只是時間可能花的比較長 ,


很多人告訴我  , bug 解不出來 ,
我實在不好意思告訴她們:
如果你願意當個傻子 , 不斷的嘗試 ,
將所有可能的變數 , 排列組合都測試一遍 , 你一定可以解的出來的 ,


可惜很少有人願意當傻子 , 傻傻的在自己的位子上 , 試著數種 , 幾十種 可能的解法
發現這個解不出來 , 就動腦想自己 還有哪裡忽略了  , ...
是不是漏了什麼沒有注意到 , ... , 動腦之外 , 要動手去測試 , ...
很多人可能在第二種解法解不出來時就放棄了...


如果你知道一個被別人號稱是"大師"的傻子
在別人面前可能三兩下就可以把別人困擾數個人月的問題 解決掉 ,
但是實際上在面對各式各樣的除錯歷程 卻是堅持奮戰 , 屢敗屢戰 , 直到把問題解決為止


被人稱"大師" 只是口惠而實不惠 , 調整工作職等時 沒有自己的份 ,
協助除錯 , 並不是自己份內規定要去做的 , 協助除錯也是需要佔用到自己正常的工作時間的


想除錯 沒有那麼難
不想用心 , 就解不開

除錯心法２

心法４：有時除錯不是只有靠技術，要靠正確的觀念跟概念．
心法５：比對法，找出異動點．
心法６：先畫出部署的架構圖（概念或是實際的）
解說：
那一個最近幾個月發生的除錯案例來解說好了，在部門內部會議中，有其他同仁反映了一個問題他們已經弄了一個多月還沒有搞定的問題．
他們使用ETL工具在對AS400與AIX進行轉檔，同時也會對MS SQL進行轉檔．
那個ETL工具是在執行在AIX上面，使用的是AIX上面的ODBC設定去對DB2或是Wiindows 上的MS SQL 做存取．
他們發現對MS SQL 一直無法正確存取並且寫入資料

其中的一位處理的同仁D在白板上說明了他的觀點 , 他認為是 MS SQL Server上面的ODBC 版本不對 ,
他認為要更新 MS SQL Server上的 MDAC 套件...

我當場聽了就有點昏去 , 那位同仁D據稱是DB高手 , 可能是我的表情太不好看了 , 老闆當場就將這個問題指派給我處理

隔天早上 , 我去找了相關同仁詢問必要的資訊 , (心法２：聆聽報案者的解說)
其中一個負責的同仁J告訴我 , "他們的作業原來是可以的" , ［表示不是他們的程式或是設定錯誤］
我又去問了另外一位同仁B , 他說他們存取的MS SQL Server資料庫的機器並不是放在機房中, 而是擺在 IT 同仁的腳下，最近大家剛剛換了位子．［解說：我們一般的個人腳下的機器都是使用DHCP而不是固定IP］＜－心法５，找出異動點．這裡發現有一個異動點
我又回過頭去請同仁Ｊ幫我在AIX上面叫出ETL使用的ODBC設定檔．
這麼一檢查，發現他們所使用的連到那台MS SQL 的設定是使用IP 而不是使用 Hostname 設定．
於是我請同仁J修改設定將原先的IP改成那台MS SQL 機器上的新的IP．並且將這個ODBC設定儲存.
然後再請網路管理的同仁Ｋ開放防火牆，讓AIX可以連到那個MS SQL機器(當然是設定成新的IP)

就做了這麼幾件事, 接著請同仁J再去測試 , 馬上就成功了．
一個困擾他們至少一個多月的問題，在半個早上就被我解決了．

這中間，所有的作業都是其他同仁進行的，我只有出一張嘴而已．
ETL 我不熟 , AIX 上的ODBC 設定檔的叫出 ,我也不會，防火牆的設定修改，我也不會．
那我憑什麼可以把問題解決？我靠正確的觀念與概念．

首先
同事Ｄ提到的MDAC 那個是DB Client 端的存取元件 , 但是在這個問題中 , 我們的DB Client (ETL)是在AIX 上面, 不是在 Windows 上 , 更何況是要把 MDAC 裝到 DB Server端去, 所以這個根本就是個錯誤的解法．
（心法６畫出架構圖，我在一開始的會議中就把圖畫出來，並且分出誰是DB Client 誰是DB Server的腳色，我才能快速的去確認問題的真正的癥結點在哪一部分，不然按照同事D的建議解法,可能到今天還在找問題出在哪裡!!!）

以上案例是我碰到的並解決的真實案例．我無意拿這個案例去攻擊或者是貶低任何人．只是拿來作為除錯心法的解說案例之一．
所以你不會看到內文中提到我們公司的名稱或是部門名稱或是同仁的姓名．

如果有其他同仁看到了，你會知道我是誰．但是我只是拿出來做解說，並且作為自己的除錯心法中的一個案例．

心法７：除錯有時需要一點運氣．
是的，有很多問題我相信別人也能解，但是我常常都能在別人解了很久解不出來的狀況下，把問題給找出來並且處理掉．
有時要靠一點運氣．但是人不會一直都有好運氣，所以我還是要靠正確的觀念與知識去除錯．

除錯心法-1

身為 IT 的技術人員 , 有時要處理的問題不是只有不懂電腦的End User，有時連IT 內部的人員或者是程式設計師也都會碰到各式奇奇怪怪的問題．

我勉強算是個中上等級的技術人員，所以常常會有其他人處理過但是仍然無解的問題，丟到我這裡，希望我能夠將這些問題解決．

就經驗來說，我大概有90%都能夠把問題解決．
所以來說說的我除錯心法吧！　都是有點零散的片段，必要時我會挑出一些案例來解說．可能會發成多個片段


心法１：重現犯案現場
解說：如果有人告訴我，他的程式或是系統出現了什麼錯誤．我會希望他能夠讓錯誤重現．也就是說在什麼樣的步驟下或是程序下，照著做一遍就會出現相同的錯誤．
如果不能重現，那麼錯誤幾乎就很難抓到．

心法２：聆聽報案者的解說
解說：有時候來報案求助的人可能是個電腦白痴，但是也有可能是個與某個問題奮戰了很久的程式設計師．有時候她們已經快要找到問題的關鍵了，只是沒有意識到．

心法３：不要完全聽從報案者的解說
解說：此點好像與心法２互斥．但是它很重要．
說了來報案者有可能是電腦白痴也有可能是個糊塗蛋，可能完全一問三不知，或者是胡說八道一通．如果你照著他們的說法去除錯，可能永遠也查不到問題．

OOAD-可怕的OOAD與Design Patterns應用方式-2

OOAD-可怕的OOAD與Design Patterns應用方式-2

因為這些人根本就不會寫程式碼 , 所以她們畫出來的UML設計圖 , 連她們都不知道對不對,
根據上面的問題衍生出來的下一個問題就是:
她們常常希望來個OOAD大師(不過一定要是外面花大錢請來的那種)
如果是內部的人員 , 又是免費的 , 絕對稱不上是大師 ,

有句成語: 眼高手低 大概是形容這些人的現況
她們常常期望找本高深的書 , 找個高等的老師 , 找個高貴的大師就能教會她們 , 如何成為 OOAD中手 , 但是常常沒辦法達成心願 , 為什麼?
這麼比喻吧 , 你找了個諾貝爾物理學獎的得主來教一個幼稚園的小朋友 , 你覺得這個幼稚園的小朋友在學了一年後就可有大學程度的物理學知識嗎?
她們仍然沒有自覺 , 仍然以為找個大師過來就可以讓她們瞬間提升 ,
我只能說要聽懂大師或看懂大師的著作或教學 , 你絕對不能是個完全不會的人 ,
舉例來說 當大師提到 某某系統使用了 Bridge 或是Adapter 樣式 , 這樣用如何如何時, 如果你完全都不會沒有基礎 , 那接下來大師的講解 , 你會聽懂才有 X

我憑什麼這樣說? 老話一句 , 她們不會寫程式碼(再解釋一遍是PC端的程式碼 , 且是物件導向 , 與Web應用程式方面的 )

所以當你(或是外面來的顧問)再跟她們談最基礎的程式語法例如某些寫法是不對的 , 某些寫法會造成記憶體漏失 , 某些寫法會造成效能不好 , 而這些寫法是因為設計不良造成的, 我可以跟你掛保證 , 她們絕對聽過就忘記 , 為什麼?   老話一句 , 她們不會寫程式碼

至今仍然有不少人以為去外面學了OOAD/UML的課回來就可以當起 SA/SD...
我只能說 , 不會寫程式碼的人開出來的 SD 規格文件 , 你覺得會如何?

接著開發過程中 , 一個問題又一個問題不斷的出現 , 有些問題的出現完全是在於這些相關人等自身的問題 , 幾乎是問題的源頭: 她 們不會寫程式碼(我指的是PC端的程式碼 , 且是物件導向 , 與Web應用程式方面的)
哪些問題?
例如: 測試 , 她們就會問 : 要測哪些 , 如何測 , 測什麼 , 怎麼測?
例如:封裝 , 打包 , 部署 , 她們通通都一定會問 ,(如果她們有實作過 , 根本就連問都不會問)
這些問題 , 不是我看不起人 , 而是真的因為問題的源頭是
這些人都不會寫程式碼
不要再讓不會寫程式碼的人去負責 SA/SD 然後去做分析設計文件
再打個比喻好了
有一個不會騎腳踏車的人 , 不斷的追問人 , 要如何騎腳踏車?
你會告訴他 , 你先坐在腳踏車上 , 然後他會接著問 , 要如何坐在腳踏車上 , 腳架要不要放下來?
<這個比喻很愚蠢吧 , 真的會有人這麼愚蠢嗎? 會騎腳踏車的人絕對不會問這些...
但是就跟那些不會寫程式碼的人卻在上過 OOAD的課程後 , 回來衍生的問題一樣 , 她們會問一些你很難好好教她們的問題 , 當然她們也不會讓你教 , 因為只有她們老師講的是對的>
至今這種可怕的方式 仍然存在...

OOAD 之道 , 開始於 Coding
要記住 OOAD 存在的目的是為了完成系統 , 是為了寫出可工作的程式碼
不會寫Code的人 , 千萬不要來談 OOAD 如何 , Design Patterns 如何如何?
這些對於不會寫 Code的人只是空談

可怕的OOAD與Design Patterns應用方式-1

可怕的OOAD與Design Patterns應用方式
因為工作的關係 , 接觸到了 OOAD．然後又因為OOAD摸到了Design Patterns
但是發現週遭有不少人用可怕的方式在想像與應用OOAD與Design Patterns

可怕的是主管找了一些不會寫 PC端程式 , 不會寫 Web程式的人去外面上了OOAD的課程之後
回來做專案 , 要當專案的 SA , SD
這些人去外面上了課 , 回來的第一個症狀就是他們上課的老師不錯 ,
接著就是當你在專案與這些人討論時 , 她們會告訴你 , 你說的跟她們老師說的不一樣
因為她們老師不錯 , 所以你說的不對...
碰到這些人我以前會好好的教 , 好好的講 ,
現在真的年紀大了沒力了 , 不想說 , 就讓她們去玩

說了半天還是沒有說到重點 , 為何我說她們的用法與想法很可怕
OOAD 是某些有先見的前輩針對使用物件導向的軟體開發與維護(請注意維護這兩個字)大家慢慢不斷的補充與改進其流程與設計方式
舉例來說 OOAD 搭配的表示語言就是 UML
它是圖示語言 , 是系統的設計圖 ,
但是你可以看到某些完全不會寫程式的人去上完課後 , 回來跟你辯說她們的圖如何如何
你的圖又如何如何 , 完全不聽人說 , 這些人以為去上完課回來就會了 UML就懂了 OOAD ,
完全忘了 UML 是OOAD的一部分而已 , 它的存在是為了開發系統而產出的分析設計文件
如果沒有了實做 , 這些圖根本就是個笑話...
你可以試著拿著那些不會寫程式的人畫出來的UML設計圖 , 去問她們根據這張圖寫出來的程式碼會是如何? 如何才是正確的?
因為這些人根本就不會寫程式碼 , 所以她們畫出來的UML設計圖 , 連她們都不知道對不對,

根據上面的問題衍生出來的下一個問題就是:
她們常常希望來個OOAD大師(不過一定要是外面花大錢請來的那種)