推 ykjiang:最近發現一個讓人印象深刻的 IDE 203.73.175.152 07/03
→ ykjiang:Code::Blocks Studio 203.73.175.152 07/03
→ ykjiang:雖目前只到 1.0 final beta，就讓人感到對味 203.73.175.152 07/03
※ 引述《cherico (好心人)》之銘言：
: 大家有什麼好工具或是技巧嗎？
: 從一行一行的程式碼能得到一個 overview，真是一件不簡單的事…XD
我狀況不好，睡不著，爬起來亂寫點東西。
以前我非常依賴 IDE, 也用得頗熟，但當我開始玩 FreeBSD 之後，發現
以前所建立的體系完全不適用了。
在花了許多時間調整、思考之後，最後決定完全捨棄 debugger, 不使用
IDE, 單單就使用 editor 來寫程式。
其實最早最早的時候，那時還在唸高中，因為白天都在上課，就沒有電腦
可以用，雖然看書沒問題，但想寫程式就麻煩了，於是也練就了用腦袋來
寫程式的做法，也算是有一些基礎了。
不用 debugger 要怎麼除錯呢? 答案是儘量不要寫出錯誤程式碼，每寫完
一段程式，就要用心檢查幾次，並確認哪些地方是絕對不可能出錯的，到
後來除錯時就可以限定在很小的範圍內。
為此我當時最想寫的就是程式碼的管理工具，我想寫這樣的程式，來管理
這個程式的程式碼，建立起第一個自循環 (好久以前的事，若不是在這裡
提到這件事，也幾乎把高中時最花力氣在搞的軟體自建構理論丟光光了)
讓程式碼的每一個部分都資料庫化地充份管理。
好像又離題了，總之，對於除錯這件事，我的結論是要用整體的觀點來做
系統化的有效管理，不要去依賴除錯工具，這樣我們將永遠也不能學會讓
程式碼寫得嚴謹。
至於如何有效閱讀程式碼，我的結論是，買高解析度的大螢幕才是正道，
沒有任何軟體工具比得上大螢幕的巨大而直接的效用，我現在使用 19 吋
TFT 螢幕，解析度 1280 * 1024, 用 proggy tiny 字型在 EditPlus 下
可以有超過 200 字元的寬度，超過 80 行的高度。
並且我極用力地精減程式碼，使用大量的巨集和 inline function, 它們
基本上都可以寫在一行裡 (200 字元的寬度往往足夠寫下 10 行敘述),
到最後幾乎所有模組，都在一兩個畫面中就完全呈現。
至此，我已不需要任何輔助工具，再怎樣也不會比眼睛一掃來得快，並且
區塊之間，也都會手動加上輔助用的、長短不一的區隔線，不同的長度有
不同的意思，並不會很容易看到眼花。
*
這就是我近幾年來最為推崇的 enpowerment 觀點，只要最底層所能處理的
複雜度加大，整體的複雜度處理負擔，就會等比下降。
從程式碼精簡畫面加大，一直到程式設計者角色的加重，將程式設計觀點，
轉向至軟體製作觀點，不從更高階更抽象的軟體工程來突破軟體瓶頸，而由
最小處著眼，不斷加強改進每個細節。
這是我近年來最大的轉向，不開公司不搞資本不衝撞產業架構，就是從底層
著手，慢慢地做也慢慢地想。
這麼做可笑嗎? 也許你可以翻一翻歷史，看看單單弓箭射程這一件事就決定
多少民族的命運，又或是煉鋼技術的分毫差異，決定多少技術革新的可能，
在重要的事情上，細節就決定了成功與否。
當初那麼多網路公司那麼多聰明人，為什麼都失敗? 因為我們沒有辦法控制
成本，致使燒錢沒有休止，而沒有辦法控制成本的基本原因，就是生產力的
不足，生產力的高低，在收支平衡的決定點上，就是生死之別，只要生產力
高到能讓產業有利潤，就是正循環的成長，反之則是負循環的毀滅。
生產力的高低，也是決定程式設計者是軟體產業底層勞工，還是中堅核心的
差別。而台灣軟體工作人員的生產力，從來就沒有進到產業正循環裡，於是
無論有多少天才多少聰明的人，都改變不了台灣軟體業的失敗格局。
（當然還有行銷一條路，但那是另一回事，不在這裡談。）
*
想要快速得到程式碼的 overview 嗎? 買一個足以做 overview 的大螢幕吧。
--
※ 編輯: reader 來自: 61.222.173.29 (07/02 11:37)