在前面的一系列文章裡，我發現有些人有些很有趣的想法，有些人覺得使用Windows是很落後的事，或是要用vim、gcc、gdb來寫程式才顯得有技術，我自己也是從小玩技術長大的人，事實上我很能理解這樣的想法，或著說我以前也是這樣的想法，但後來漸漸地想法就改變了
在大學時有位組合語言很強的傳說中的教授，他的組合語言課真的很令人印相深刻，他從來不帶課本，一上台就開始畫圖，然後用很粗俗易懂的例子講解，可以看得出他對低階的這塊領域實力有多深厚，有一次他在上課談到
我以前在做賭博電玩時，有人來跟我推銷繪圖晶片，可是我跟他說，不用，我覺得自己寫一個pixel一個pixel畫才有技術
可是後來發現別人用繪圖晶片來畫圖，一下子就做出來了，我還在刻低階的繪圖功能
後來因為這樣做不過別人就不做了
聽了之後仔細想想我自己也是這樣的想法，以前在寫遊戲時最初是用Direct Draw，後來覺得使用現成的函式庫沒什麼技術，在之後重寫的版本中，就自己寫畫圖的函式庫，一個pixel一個pixel去填，半透明混色也是自己去算，甚至想自己寫3D的繪圖引擎，雖然確實在這過程中學到很多東西，但事實上整個寫遊戲的過程中有好一大半的時間是花在底層的這些基礎繪圖功能上，後來漸漸理解，重覆利用別人做好的輪子是很重要的事，只因為覺得 “那樣才叫有技術” 而去自己做別人已經做好的東西是很不成熟的想法，後來我終於理解到
技術只不過是在工程中完成目標的手段，並不是最終的目的
除了技術以外，事實上在整個軟體的工程當中，還有太多值得注意的事，從你學習那項技術需要花多少心力，技術相關的社群，如果你是商業公司還得考慮到有沒有支援商業服務，還有你用這項技術的話能不能找到人來接替你的位置? 你用了這項技術生產力有因此而提升嗎?
以先前提到的例子，用gcc直接下指令編譯，用gdb下指令除錯，你的生產力有因此而提升嗎? 為了從一般的IDE環境下切換到這樣的環境需要多少的學習成本? 如果你找一個人來接續你的工作，他是否有辦法像你一樣熟練地使用這些工具? 如果你要教新來的人熟悉你的環境，你需要花多少時間? 我相信，大部份提到要使用這些工具的人都沒想過這些問題，這很正常，因為他們熱愛技術，但是實際的工程應用這些都會是很重要的問題。
人適應工具
而在這些提到的一些工具中，有個很極端例子，那就是vi/vim，我自己有用vim，因為打大量程式會比較有效率，或在Linux下改程式都得用到，為什麼說vim是很極端的例子，因為它的設技概念與我們一般常見的IDE是相反的，一般的工具都是設計工具來適應人，然而vim卻是設計工具要人去適應它，因為如果需要打大量的字，手一直保持在鍵盤上是最有效率的，所以它設計讓你手都不用離開鍵盤，就能進行所有的操作
Vim cheat sheet 來自 http://www.viemu.com/a_vi_vim_graphical_cheat_sheet_tutorial.html
當然，缺點是它的學習曲線很陡，在一開始你可能打幾個字都會弄得灰頭土臉，身為技術人員如果你覺得打大量的字是很常有的事，這投資是值得的話，學一學vim確實是不錯，但推薦初學者學vim就不是什麼好事
所以，當你很興奮地覺得這個東西才算有技術，或著是開源萬歲之類的理由，推薦給別人時，想想你自己花多少時間學這東西，別人又能因此得到什麼好處好嗎? 而當你開始設計產品時，你想想如果Apple的Macbook廣告詞是
經過三個月的練習，使用我們的系統工作效率提升了50%!!
你覺得還會有人買這樣的產品嗎?
工具適應人
另一種設計的想法，也是主流的設計思維就是讓工具去適應人，大多數你能在市面上看到的產品都是這樣的設計，我們舉一些例子，Visual Studio最近推出了一種新的UI，叫Debugger Canvas，是將整個debugging trace的過程以泡泡視窗的方式串聯在一起，讓你可以很直覺地理解程式呼叫的過程
[yframe url=’http://www.youtube.com/watch?v=3p9XUwIlhJg’]
有這樣視覺化的輔助，除錯的過程會輕鬆許多，在有現代化工具可用的情況下，除了學習以外的炫技理由堅持使用原始的工具，就只是浪費寶貴的開發時間而已
再舉另一個例子，就是git或mercurial在送commit之前，我個人都會對送出的內容review一次，以免將測試用的程式也送進去，例如像是這樣糟糕的例子
def auth(user_id, password):
# XXX: FOR TESTING ONLY!!! DO NOT COMMIT
return True
user = session.query(User).get(user_id)
if user is None:
return False
if user.password != password:
return False
return True
原本的授權檢查，為了測試直接回傳True，不小心把這樣的送出去就不好玩了，使用console看列出git或mercurial的差異通常沒有標顏色都很難看清楚
然而有了Gitk的GUI標上顏色，到底改了哪幾行就相當顯眼
這還只是簡易的例子，真正程式碼在修改不會像這樣只有一行兩行，不使用適當的工具只會弄得眼花潦亂，造成錯誤就得不嘗失
工具應為服務而生
技術與工具應為服務人而生，不是最終的目的，不懂得從使用者的角度出發思考，不懂得從軟體工程的角度出發思考，我想這是很多技術人常見的問題，如果能用不同的角度，放下對於單純技術的追求與炫耀，才能做出更能幫助人們、受人們歡迎的工具。
话说最后的颜色问题能否用source-highlight之后再用less看?(或者说是带source-highlight的less看)
没有怎么用过diff比较代码(不是程序专业的)，所以不太清楚
我觉得total commaner也算是一个需要人去适应软件的例子吧。只是适应的时间比较短。最近想学下Vim，但是总又抑制不住回去用ultraedit的冲动，进步缓慢
把 .gitconfig 裡的diff.color 設成 auto ，console 下就有顏色了
git 已內建許多顏色
(.gitconfig 裡)
[color]
diff = auto
status = auto
branch = auto
log = auto
@ cmchao @ lucky17
感謝分享
其實我是知道應該有方法可以讓console的diff也可以有顏色，只是懶得去找，因為畢竟有gitk可以用，不過偶爾也是有沒有gitk用的情況，但是即使有顏色，要看大量檔案修改，還是GUI捲動起來比較方便，可以很快掃過修改的部份，有疑問可以馬上拉回來，雖然console也能做到，但就比較不直覺，這就是以人去適應機器的例子
工具適應人的哲學有一個非常大的問題，那就是人的直覺想法不見得是處理問題的最佳方法。
以 word 來說，它就是非常直覺，依照你的定義上是很適應使用者的軟體，然而一但文件長度開始增加，很快地直覺式的操作會引導使用者寫出無結構、排版不一致的文件。儘管 word 可以排出很有結構而且前後一致的文件，但其中的操作方法絕對不是短時間內可以學會的。
也就是說，適應人的工具雖然上手快，但是它必然隱藏了許多細節，導致使用者低估解決問題的難度，同時使用者會抗拒更深入地了解工具。
如果說臨時性的需要 quick & dirty solution，的確使用這類工具有其必要。然而作為工程師，多接觸不同工具並徹底了解是有其必要的。
工具適應人的哲學有一個非常大的問題，那就是人的直覺想法不見得是處理問題的最佳方法。
以 word 來說，它就是非常直覺，依照你的定義上是很適應使用者的軟體，然而一但文件長度開始增加，很快地直覺式的操作會引導使用者寫出無結構、排版不一致的文件。儘管 word 可以排出很有結構而且前後一致的文件，但其中的操作方法絕對不是短時間內可以學會的。
也就是說，適應人的工具雖然上手快，但是它必然隱藏了許多細節，導致使用者低估解決問題的難度，同時使用者會抗拒更深入地了解工具。
如果說臨時性的需要 quick & dirty solution，的確使用這類工具有其必要。然而作為工程師，多接觸不同工具並徹底了解是值得的。
to Shan-Yung Yang,
Good point! The application and performance of tools does really depend on viewpoints of different people and expected target. Just like what you said, if the duty of engineers was to make sure things go well, fit the spec and budget/schedule, they should pay lots of efforts on their working pipeline/environment (including editor~) cause it is the only way to make sure you could do things well. Not to speak of being professional~
其實我覺得那是適應的不夠好
另外人跟電腦 誰要適應誰 也不是一定會衝突的問題
有時候只是 技術還沒到位而跟某一方做的妥協
我一直不能理解為什麼Linux那派一直弄不出好的debugger,不提GDB好了, Visual Studio IDE明明就比Eclipse好用很多還很多人睜眼說瞎話說Eclipse無敵XD，好用的工具配上會用的人才能真的提高生產力，前面有人提到工具適應人的問題，其實這篇講的不是那樣，應該是什麼工作適合什麼東西，寫code除錯用IDE，需要自動化的時候用makefile，兩種作法並不衝突，問題在於，反對工具派的認為只要會makefile就好，這和只會用IDE的人一樣是一種偏食，很多習慣用vim+grep+printf的人都有這種問題…
Anjuta, KDevelop, Code::Blocks 都是具有 GUI debugger 的 IDE。如果你覺得 VC 比較好用那也是很合理的，一方面你已經習慣它的界面，另一方面 VC 是付費軟體。
另外很多時候我會偏好直接用 gdb，尤其當我知道 bug 大概出在哪個函式時，breakpoint 放下去五秒後我就可以看到變數值 (gdb command line 支援 tab completion，非常好用！)。開 VC 的話我要先等 20 秒左右吧，intellisense 還會很貼心地幫我做原始碼掃瞄…
只會用 IDE 來 debug 那也是某種程度的偏食呀
@Shan-Yung Yang
我想你沒弄清楚，VC確實是付費軟體，但Visual C++ Express是免錢的，除了較進階的功能以外，該有的還是都有，甚至它還有其它的debugger沒有的特異功能，可以將目前執行的那行回到上面幾行，只要把那箭頭拉到上面的行就可以了
你breakpoint設下去五秒後可以看到變數值，那請問你花了多少時間設breakpoint? 用console工具有個最大的缺點就是你無法忽略很多細節，請問你要停下來除錯的那行行號是多少對你的程式正確或錯誤很重要嗎? 當然不重要，但是你卻得停下思考，找到底是第幾行要中斷，行號是多少，然後回想設中斷點的指令是什麼，如果是條件式的中斷點，是否要用其它的指令，指令又是哪一個? 在這整個過程中，你的心力都浪費在這些無關緊要的東西上面，然而，使用GUI的一個主要原因就是它可以幫你省去這些對你程式除錯不重要的無關緊要的細節，並且能夠給你一個overview，使用IDE debugger我不需要知道那行行號多少，直接add breakpoint即可，要下一步、追蹤進入，按個鈕就可以，在這整個過程中，我可以將心思花在這程式為什麼出錯，可能性有哪些，而不是那些無關緊要的東西
只會用IDE來debug? 我不這麼認為，有必要時我就會用指令的方式來除錯，舉個例子，我的Python伺服器出了一些問題，ssh連過去只能用指令工具，當然這時我就只能下指令來除錯，當然如前面所講的，我得花很多心力，在不同檔案之間切換，思考那個檔名是什麼，查某個函數的行號是多少，打指令設中斷點
所以，我想我看到的東西跟你看到的可能不太一樣，我見到的是以工程的角度來看工具的使用，或許你只看到breakpoint放下去五秒後就可以看到變數值，雖然我不太懂你指的是什麼
@victor
1. 我的意思是 MS 是營利公司，VC 除了免錢的 express 版以外也有收費的 standard/professional，拿 VC 來和慈善開發的 C::B 比較是不恰當的。
2. 設定 breakpoint 大概是兩秒吧…以下是操作方式：
gdb program
break some_function (如果function名稱很長，可以用tab自動補滿)
start
@victor: try gdb’s shortcut — ‘b some_function’ and then ‘s’ 🙂
@someone: can you use your VC to ssh server to debug(without setting up VNC)? Can you use VC to debug other language like python, Erlang,…? Do you think VC’s debugging ability also apply on very complicated problem or problems need to scale up, like map-reduce, complicated async network problem? Ppl in linux think deeper.
Finally, how much time we should spend on learning our tools depends on our self-expectation. If you are aiming for F1 champion, will you save $$ on your car?
嗯，没错，工具应该为服务而生。
一般的用户需要的是满足自身需求的工具，服务，而他们一般不会去关注如何更加有效地满足自己的需求，甚至根本没有这个观念！例如大多数人的电脑知识是相当贫乏的，他们会觉得记事本（notepad）比vim好用多了，省事多了（Vim根本学不会）。对于某些繁琐的操作（例如应该用正则表达式批量修改）他们会不厌其烦地一行一行地修改而且不会去想有更加有效的方法。
所以用户很多时候并不知道自己究竟需要什么，这时就是程序员，设计师出现的时候，为其创造出更好的用户体验，更加傻瓜化的流程等。
但是相对地，我觉得Vim的目标人群是那些对电脑知识有相当程度的人，例如我们Programmer。当我们不知道有Vim的时候也可能想不到文本编辑可以这么神奇，有那么多高级的高效的技巧。（例如我很多同学都是这样）
所以我觉得不同的工具有其不同适应的领域和人群，不可能one tool fits all。
每个人都有不同的习惯和喜好，哪个适合自己就用哪个，不要纠结于技术的先进与否什么的。
就如在我看来CLI和GUI在不同的Context上有不同的优势，CLI可以方便地自动化，而GUI一目了然，容易理解，但是不同人可能有不同的看法。
所以到头来关键在于目标人群的定位，然后才是了解用户需求，站在用户角度思考。
当然如果以后人工智能什么的发达了，我们对电脑说一句它就能自动生成代码时，那么什么都是浮云了。XD
第一次在你博客发言，以上一点愚见。
因为关注Python而发现了你的博客，很喜欢看，谢谢你写了这么多好东西，学到不少呢。
個人有一個想法，就是一定有一個時候，編程這門技術學習簡單到像語文一樣每個人都會那麼些。
個人認為，應該是不同的工具適應不同的情況。但，總體而言，可視化依然是最方便人類學習的。
如console下，很多命令有些人覺得難背，那麼提供每個命令的可視化操作方式的話，就一般人也得以體驗到vim的萬能。當人們要提高操作速度的時候，又有命令行的方式提供快速操作。