軟體的庖丁解牛能力 || William’s Blog

軟體的庖丁解牛能力

2006 年五月 8 日 (星期一) 7:17 pm
分類：閱讀, 電腦
標籤：軟體開發論

昨天的一場讀書會，我在投影片中特意引述了一段 Peopleware 第 29 章的話：

工作流程愈是獲得改善，工作內容就愈艱難……一、沒有被替除掉的工作，就是更加知識密集、需要更多技術與經驗……二、經過改善的工作流程，讓你能夠面對更艱難挑戰，而你也會面對這些挑戰……

當工作流程獲得實際改善，我們也同時需要更多更有能力、更有經驗的員工。

有人要我針對「沒有被替除掉的工作，就是更加知識密集、需要更多技術與經驗」舉幾個例子，當時我直接想到的是：抽象思考與 modeling 技能、API/framework/library 學習及掌握，以及 software asset 的情蒐／評估／萃取／修改／重構能力。後者引起了一些討論。

不過這方面的議題，完整的論述文獻並不多見。

早年學界及產業界的相關論述，雖然曾探討過一些 code reading、code inspection、code review 層面，但多半都是針對軟體除錯而做的，較少將 software asset 視為一個具有獨立完整意義的個體來對待。近年由於 agile 方法論的推波助瀾，refactoring 技術受到重視，但層次仍然過於微觀，沒有宏觀到 asset 層級。

單就操作面來說，逆向工程 (reverse engineering) 比較接近我所談的議題，但它有點像黑魔法，大家都偷偷地做，但不太願意公開討論，因此難以形成系統論述，累積群體智慧。

記得小時候，組合語言盛行，沈文智《軟體技術抽取方法與實務》一書展現了這方法的魔力；現在 open source 盛行，剖析原始碼是合法的舉動，應該更要有去污名化的公開論述才是。

前陣子 Qing 寫了兩篇文章：〈Google 時代的程式撰寫〉及〈開放原始碼的回收與再利用〉，整理了些不錯的經驗。以下則是我找到的一些相關資訊，給有興趣的朋友參考：

ISESE ’04 論文: Comparing code reading techniques applied to object-oriented software frameworks with regard to effectiveness and defect detection rate
書: Reversing: Secrets of Reverse Engineering
書: Working Effectively with Legacy Code
書: Reverse Engineering of Object Oriented Code
書: Code Reading: The Open Source Perspective

◤建議您一併閱讀以下文章：

著作授權方式：Creative Commons 條款。

追蹤留言回應：以 RSS 2.0 方式。
文章永久網址：
» http://william.cswiz.org/blog/archives/2006-05-08/code-reading/
引用通告 (trackback)：
» http://william.cswiz.org/blog/archives/2006-05-08/code-reading/trackback/

本站歡迎您以合乎創用CC 的方式，將文章選錄至網路書籤或社群網站，也別忘了將您寶貴的意見（尤其是延伸的評論、補充、彙整、反駁等）留言在本站。謝謝！

16 項留言回應給 “軟體的庖丁解牛能力”

1 同人留言：
2006 年五月 9日於 8:34 pm
敢問何謂「沒有被 “替” 除的工作」？
2 william 留言：
2006 年五月 9日於 9:57 pm
同人兄是在問「替」這個字是不是筆誤嗎？這是從譯本《天才當家》摘錄出來的，意思是替換、替代、replace。
3 Godspeed Lee 留言：
2006 年五月 11日於 9:57 am
跑去 Qing’s blog 看了一下…

比較起來，我們這些 firmware programmer 似乎還停留在上古時代，除非是一些用的比較多的 IC，不然即使是 Google 也找不到什麼像樣的資料，反而還是得從傳統管道 -> 找代理商或原廠 FAE 要 sample code…

就拿要價 3x 萬的 RVDS (用來開發 ARM SoC 的一套 C/C++ 編譯器) 來比，光從操作介面來比，恐怕會笑掉 Windows Programmer 大牙，更何況
Visual Studio 的價錢搞不好只要他的 1/30。

扯遠了

這兩年因為工作上的需要，必須研究前人的 source code，我用的方法跟 Qing 很類似，我是先畫出 call graph，然後把最獨立的 function 剪裁出來，然後再跟其他片段慢慢組合…

這其中 grep 跟 indent 等工具是少不了的，另外就是 refactoring，但是 C code 的 refactoring 似乎很少人提及，只好照經驗法則來作

題外話 2: 公司最近在找人，居然找不到幾個熟 C/C++ 的人，這幾年大家都學什麼去了?
4 william 留言：
2006 年五月 11日於 11:37 am
一方面大概是因為 firmware programmer 比較小眾，限制較多，一方面可能是商業利益吧，不太有 OSS-like license 的文化。

以我的直覺來說，C 的結構單純，導致可用的 refactoring 招數非常少，不外乎都是善用 wrapper 技術，把內部一團雜亂糾結的東西包上一層模組化、資料抽象化的乾淨外殼，方便外部程式使用。至於要深入 black-box 多深，要不要分析得很 white-box，那就看專案需要、時程壓力及個人興趣了。

我中 C++ 及 OO 的毒太深了，遇到高度倚賴的 C source，往往想把它 refactoring 成 C++ class 才肯罷手。

最後，關於你所提到的「公司最近在找人，居然找不到幾個熟 C/C++ 的人」，嗯，以資工而言，雖然大一大二仍然會教些 C/C++，但除非有在玩系統程式，否則高年級大概都去碰 Java 了吧。
5 b6s 留言：
2006 年五月 11日於 1:33 pm
講到 C/C++ 沒幾個人熟，實在是因為現在大概很難找到機會熟了。

Ruby on Rails 嘲笑 Java 的時候，故意把 J2EE 相關的書堆得很高，與當時只有兩本書的 Ruby/RoR 相比。
C/C++ 苦就苦在，想堆都沒得堆。

而且 J2EE 能堆那麼高，有部分原因是選擇很（太？）多，光是 apache 自己就好幾個。

C/C++ 的話，單就書店裡的書看來，除了 VC 家族之外，好像就沒別的方案了。而且這些語言層次的東西學完，能接著看的卻都是在語言層次上更深入的，像是 STL，generic type。實務上，除了靠 effective 系列提醒自己別在語用上犯錯，再搭配 design patterns 和 agile principles，好像也沒有更進一步的東西了？

於是問題來了，如果老闆今天要我用 C++ 甚至是 C 寫個東西，如果沒有前輩，還能靠誰？
orz
6 Godspeed Lee 留言：
2006 年五月 12日於 11:51 am
b6s 說的很有道理，假如沒有目標，C/C++ 會越學越累，
開發小程式又懶得用 C/C++，結果就是…
所以說一定要先有想做的軟體，不然光學工具是很乏味的

台灣以硬體製造為主，firmware 的工作機會是很多的，最貼近
機器的語言除了 Assembly 之外就屬 C 了，最近碰到一堆想轉
firmware、embedded system 的朋友，結果很少人有用 C/C++
開發過專案的經驗…

我最近倒是蠻喜歡一種用法的，把 C++ 當 C 寫，用 STL 作記憶體自動管理，
這樣寫起來比寫純 C 痛快多了，可能有人認為這種用法是邪道，不過小弟覺得
生產力的增加比架構優不優雅重要多了

頗蠻認同 Joel 的看法，對程式員生產力影響最大的是記憶體自動管理，
而不是 OO… XD
7 小魚留言：
2006 年五月 12日於 7:36 pm
若是在 embedded system 上的 CPU (非 DSP)
寫應用程式的話應該還是以 C 為主
不過要熟 inline assembly 就是了
多媒體？那還是特殊硬體 + 手寫組語的天下吧

系統級的語言 SystemC
需要的是 C++ 的功力啊
尤其是 template
另外看到同事的 system model proposal
“ㄟ你這是用 C 寫 C++ 喔”
這麼喜歡用 virtual function 從頭繼承到尾
為什麼不用 template + policy

不過怕自己學藝不精半桶水
還不敢回
8 Yukuan 留言：
2006 年五月 13日於 3:33 am
C 可以用的 refactoring 雖沒有 OOPL 多，但在實務時也重要：

Add Paramater
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Decompose Conditional
Extract Function
Inline Function
Inline Temp
Introduce Assertion
Introduce Explaning Variable
Move Module Variable
Move Function
Parameterize Function
Remove Assignments to Parameters
Remove Control Flag
Remove Parameter
Remove Setting Function
Rename Function
Replace Magic Number with Symbolic Constant
Replace Parameter with Explicit Function
Replace Nested Conditional with Guard Clauses
Replace Parameter with Explicit Function
Replace Temp with Query
Separate Query from Modifier
Split Temporary Variable
Substitute Algorithm

算一算其實也不少，只要把 C++ 的 class 概念，用到 C 的 module 上，很多原理都是共通的。
9 同人的生活派對 » 軟體開發能力的自我組織引用：
2006 年五月 13日於 6:35 pm
[...] 在William’s blog看到軟體的庖丁解牛能力中提到：有人要我針對「沒有被替除掉的工作，就是更加知識密集、需要更多技術與經驗」舉幾個例子，當時我直接想到的是：抽象思考與 modeling 技能、API/framework/library 學習及掌握，以及 software asset 的情蒐／評估／萃取／修改／重構能力。 [...]
10 Tai 留言：
2006 年五月 15日於 8:37 am
我是一個唸機械的人，因為自動化 pc based 的關係，反而在工作上去學了 C/C++ (雖然有人是用 VB)，大都是用 bcb 開發 (入手容易)，所以最近我這在找人時，反倒有不少畢業生是在實驗室玩 C++ 的!
11 ShepJeng::Blog | links for 2006-05-08 引用：
2006 年五月 16日於 12:32 am
[...] 軟體的庖丁解牛能力 [...]
12 William’s Blog » 工作流程愈是獲得改善，工作內容就愈艱難引用：
2006 年五月 16日於 1:55 am
〈軟體的庖丁解牛能力〉一文開頭提到，我在讀書會曾以一段 Peopleware 第 29 章的話做為 software process 議題的開場白。在寫這篇文章時，我並沒有企圖還原這段精闢引言的完整內容，因此，對於沒能現場聽我解釋、手邊又沒書可看的網友，可能需要發揮一點想像力，才能自行串連起原作者想表達的意念。

為了避免一再被問到，乾脆把這段引言的原文貼出來吧。請慢慢收看。 [...]
13 Yukuan’s Blog 引用：
2006 年五月 24日於 12:57 am
Programming as a Specialist Doing…

William 在〈軟體的庖丁解牛能力〉中引述了 Peopleware 第 29 章的話：
[...]
William 後來特地在〈工作流程愈是獲得改善，工作內容就愈艱難〉附上了這段話的原文，有興趣可以自行參閱。 [...]
14 同人的生活派對 » 軟體開發的團隊綜效引用：
2006 年十二月 22日於 11:42 am
[...] 記得我在《軟體開發能力的自我組織》中一文曾提過的：「專案實施Inspection時，成員的設計能力及software asset變得與日俱增，而且在團隊溝通上助益也很大」，就是一種共用件的有效運用，Inspection本身就是一種增進軟體品質的一種共享程序；同時透過團隊相互觀摩的良性循環，讓有經驗的開發人員分享設計與開發技巧，而達到共享人員的目的；最終的目的其實是要慢慢地形成如William所說的軟體資產（software asset）的目標，這不正是共享元件嗎？ [...]
15 同人的生活派對 » 讓 Application Log 更容易實現引用：
2007 年二月 9日於 1:44 pm
[...] 採用這種架構設計可以讓 Developer 不用去理會系統層面的問題，因為它們是由其它的關注點所負責，springframework 以 proxy 實作 AOP 機制，只要定義好主要關注點界面，就可以任意加入或移除所需要的横切關注點－而它們是可以被重覆使用的，它們是系統的的共享元件。 [...]
16 同人的生活派對 » Software inspection 不是只有檢驗而已引用：
2007 年三月 15日於 9:22 pm
[...] William 所說的軟體資產（software [...]

William’s Blog readings, ideas, feelings, photos, etc. by William Yeh