程式者的胡言亂語
星期二 六月 30, 2009
手機應用創新開發與線上軟體商店研討會投影片及檔案
請於此處下載投影片（關於DirectShow的部份已更新，不限Windows Mobile）
至於我小改並在偷懶的情況下略為整理的DirectShow.NET for Compact Framework及範例程式也可下載了。
有時間，我會把DirectShow.NET for Compact Framework修的更完整一點，再重新發佈，目前是很偷懶的版本，看了source code看倌們就知道了。
Posted at 11:20下午 六月 30, 2009 by Chien-Hsing Wang in General | 迴響[0]
用cegcc編譯出來的DLL無法在Windows Mobile 6.1上的機器載入
這個問題發現好幾個月了，但這次又有人問起，臨時找不到，所以我一定要筆記一下，不然再遇到又會忘記。基本上就是Windows Mobile 6.1上的記憶體管理機制有一些改變，導致某些DLL無法被載入。有一個workaround，請參考這邊：18. DLL doesn't work with Windows Mobile 6.1。
目前看到的受害者都是試著把ffmpeg弄到Windows Mobile上跑的人。錯誤訊息會像是「'MyProgram' is not a valid Windows CE application」或是「不是一个有效的PocketPC应用程序」之類的，總之，如果你在LoadLibrary後去取GetLastError()值，會取到c1，也就是ERROR_BAD_EXE_FORMAT。但問題並不出在EXE檔本身的格式，而是DLL的問題。
Posted at 04:43下午 六月 30, 2009 by Chien-Hsing Wang in General | 迴響[0]
星期四 六月 04, 2009
取消Windows應用程式在存取違規時的錯誤視窗
在Windows裡，若應用程式對記憶體做了非法的存取，便會跳出一個錯誤視窗，其標題是「XXXX.exe發生問題，必須關閉，謹此致歉。」最近遇到一個情況，不想讓這個視窗出現，找了一些方法想要取消它的出現，包括試了API hook想要攔到CreateWindow系列的API，都無功而返。後來朋友找到一個方法，才是真正的解決之道。原來Microsoft有一個叫做SetErrorMode()的API，傳入SEM_NOGPFAULTERRORBOX做為參數，即可取消此種類型的錯誤視窗。這API或許很少人知道吧，哈哈 XD
Posted at 04:17下午 六月 04, 2009 by Chien-Hsing Wang in General | 迴響[6]
星期五 五月 22, 2009
漫談開發流程 － 半吊子的輕量級開發
在前一回中，我們提到了徒具形式的開發流程。許多團隊的開發流程，看似井井有條、制度完整，但流程中所規劃的活動，卻無法在開發參與者的進行下，達到它應有的效用。很容易讓程式員產生一種負面的印象
－ 開發流程下的活動不過只是表面文章，只是敷衍了事、徒做虛功。也讓許多開發者，對於開發活程中的活動是敬而遠之。
因此，在光譜的另一邊，也有著一類團隊，他們盡可能的裁減他們所需的開發流程活動。這樣子的團隊，多半是以程式員為主的團隊，對他們來說，程式撰寫以外的工作幾乎都會被歸類為
”overhead（額外負擔）”，就像我們很常見到的，程式員視紙上作業為overhead，因為寫在紙上的東西，往往不能直接轉換成為程式碼，而且有時候甚至和程式碼的產出一點關係都沒有。對他們來說，開發想要更有效率，就要盡可能的減少overhead。當然，文件的撰寫肯定是他們首先要打倒的萬惡罪魁，非到萬不得已、山窮水盡的局面，絕對不讓團隊成員撰寫任何文件，也不會安排任何的文件撰寫活動。我甚至看過，有些團隊的管理者，認為版本管理的活動，是一種對開發者的overhead，因此，雖然他們也建置了版本管理的伺服器，但是，開發者卻不利用版本管理伺服器來進行版本管理的活動。這某種程度算是管理者體貼開發者的一份心意，因為管理者也希望讓程式員專心的撰寫程式碼，盡量的避免其他的活動干擾到這個最主要的工作。對這類的管理者來說，追求制度不過只是形式上的表面功夫，事實上，裡子更勝於面子，產品應該以更有效的方式開發，而要達成這目的，應該盡量的摒除對程式員施加的各種overhead。
尤其近來輕量級的開發方法大行其道，這更讓這類的團隊找到一個依靠，當中有許多人宣稱他們自己是輕量級的開發方法，因為他們摒除了許多開發流程所帶來的overhead，所以他們認為自己的開發方式輕盈無比。我曾經聽過不只一位朋友說過類似的話：「我們採取的開發方法是XP（eXtreme
Programming），我們的釋出週期很短、需求也變更的很頻繁、甚至也沒有太詳細的需求記錄文件、我們幾乎不做細部設計。」這看起來，應該算是誤解了XP，而且只從XP裡頭挑一些對程式員來說算是甜頭的東西出來實行。
怎麼說呢？XP有十二項施行的準則，其中有許多準則是互為支持的。例如，倘若你希望小版本的持續釋出（也就是說需求能夠變更的更為頻繁），你得強化單元測試以及重構。因為當你的需求變更的頻繁時，自然造成程式碼的變更頻繁，倘若沒有足夠的單元測試做為後盾，那麼變更頻繁的程式碼，勢必頻繁的造成副作用，對程式的穩定度造成很大的衝擊。同樣的，倘若沒有持續的進行重構，那麼程式碼最後也會形成疊床架屋的情況。
小版本持續釋出是甜頭，因為需求的提供者可以更快的看到自己所許下的願望被實現。允許需求變更的更為頻繁是甜頭，因為這使得需求提供者能更快的反饋他對開發產物的修正意見。但是，許多號稱是採XP開發方法的團隊，都不做單元測試，他們也不持續的進行重構，因為這兩個工作都是苦差事。單元測試是苦差事，因為在XP強調的測試先行之下，還沒撰寫程式碼之前就得先寫好測試案例，而且每個程式碼單元，都應該搭配著相對的測試案例。要一般的程式員養成撰寫測試案例的習慣，簡直比要他們撰寫文件還要命。重構也是苦差事，不僅許多程式員不具備重構的技巧，即使具備了重構的能力，也抱持著「做好的事，何必再改變」的心態，對於整理程式碼漸漸產生的遺毒，始終興趣缺缺。像單元測試及重構，在許多人的認知裡，都是對程式員的某種
“overhead”。所以，許多團隊柿子挑軟的吃，他們的眼裡只看到可以抄捷徑的地方，卻沒有在意，這些輕量級的開發方法之所以能抄捷徑，是因為有其他的配套。好比，XP之所以允許對需求的描繪盡量精簡，是因為施行準則中有一則是要求客戶駐點，也就是說，客戶（需求提供者）和開發團隊位在同一個地點，因此，客戶能夠很快的看到系統的面貌及行為，也能夠面對面的和開發團隊溝通，減少了所需的文件。倘若沒有客戶駐點的條件相配合，那麼過於精簡的需求描述方式，就會產生極大的危機，因為開發團隊對於需求產生誤解的機會就大上許多。
徒具形式的開發流程固然可怕，但半吊子的輕量級開發，也是兇險異常。這樣子的開發表面上似乎提昇了效率，但是，骨子裡卻暗地的付出許多隱形的overhead－不論開發團隊是否有意識到。例如，因為節省了需求規格文件的撰寫，但又沒有搭配客戶駐點的條件，使得開發團隊不能準確的捕捉客戶的需求，時常在開發完成後，客戶才發現不合預期，因而引發了更多修改的請求，反而白白浪費開發的力氣。又例如，因為允許頻繁的變更，但又無單元測試及重構的活動與之相對應，因而導致程式修改的副作用頻繁發生、程式品質也降低，程式碼架構也漸漸趨向疊床架屋。表面上開發團隊節省了一些功夫，但是無形中卻可能損失更多。
有些開發團隊由於團隊中的程式員技巧高超，所以即使缺乏了某些相對應的配套活動，整體造成的衝擊相較而言有可能不那麼大，因此顯現出來的負面效應也不會太明顯。但這不意謂著抽掉這些活動，對所有的團隊來說都是適宜的。
開發流程是用來輔助開發團隊邁向完成開發目標的一個工具。正如前文中所提到的，開發流程中的活動某種程度來說，算是一種額外的成本，但也是一種投資，我們希望投入一些額外的力氣，使得我們開發的整體成本降低，品質也能維持。這個額外的成本，理想的情況下，我們自然希望能夠降到最低，但又能維持整體成本最低、品質不變（或變的更好）。而輕量級的開發，便是希望能夠降低這投入的成本。
降低因為開發流程活動而造成的損耗，大方向是對的。但是，究竟能節省那些活動，必須根據所面臨的環境、開發的標的物為何、以及開發的限制條件（包括人力的多寡、人力的素質）來決定。
當你的開發團隊決定採取較為輕量化的開發時，最好還是先對一般較為重量級的開發方法有基礎的認識。所有開發方法的發明及設計，都有其動機。開發方法中的活動安排，也都有其原因。你在輕量的開發方法下能略去某些活動，多半都是因為你有其他的條件或是輔助的活動可以相對應，而不致於引發問題。
開發團隊在選用一個開發的流程時，無論輕重與否，都應該根據目前所處的環境以及專案所面對的開發目標，設定所使用的開發流程所應具備的條件。例如，你的開發流程究竟要不要管理需求的變更？你必須知道，若要管理需求變更，究竟會付出多大的代價（好比你可能需要有額外的活動審核需求變更、確定需求變更可能造成的衝擊、並且重新評估開發時程），但可以得到多少好處。倘若不管理需求變更，那麼可以省掉多少力氣，但又會增加多少潛在的風險，而這些風險以專案的環境及條件是否可以降低或是接受。
總的來說，我想表達的是，我們想省掉一些功夫，是因為我們知道因為有某種因素的存在，所以我們可以省去。或者，是因為我們因為某些資源的缺乏（例如時間、人力），也意識到可能會有的風險，而在判斷這風險是可以接受的情況下決定省去。但絕對不是在我們不知道究竟會引發多少負面效果的情況下，冒然的取捷徑。
Posted at 11:31下午 五月 22, 2009 by Chien-Hsing Wang in General | 迴響[0]
星期三 五月 13, 2009
漫談開發流程 - 徒具形式的開發流程
一個人自己寫著自己心中構想的程式，沒有時間壓力、自由自在的寫著，突然腦中靈光一現，想要做些改變，也都任由自己動手，不需要考慮到別人，也毋需為別人負責，這大概是全天下最單純的軟體開發形式吧？
不過，大多數人參與的軟體開發專案，恐怕都不是這樣子的形式。大多數的情況下，每個專案都會有使用者端的代表，決定開發產物最終的面貌，有著既定的開發時程，規劃開發進度及截止的期限。通常也都會由多人同時參與，各自扮演一個或是多重的開發角色，並且透過彼此的溝通與合作，一同完成專案的開發。
正因為大多數的軟體專案開發，相較於個人化的程式寫作複雜許多，必須處理具有不同專長的各種角色參與、協調指派多人一起協同工作，並且在期限內完成開發目標、準確的滿足使用者的需求。因此，才會有各式的開發流程（development process）被設計出來，用以指引開發團隊如何在開發的過程中進行角色的分工、如何規劃開發的各個階段，以及每個階段的里程碑設定、在每個階段中，每個角色應當從事那些工作，以及如何與團隊中的其他成員合作，以便達成每個階段的任務。
老實說，我知道的許多程式員對開發流程都沒有什麼好感。我想這中間有很大的原因是因為在許多開發流程的運作下，程式員的工作自由度大減，同時增加了許多程式設計以外的工作。許多程式員心中對開發流程有個刻板的印象，認為在開發流程的運作下，只是多出一些徒具表面形式的文件及表單，程式員不僅得完成原本就應該撰寫的程式碼，同時還得花費力氣去填寫這些文件及表單，而這類的紙上作業，更是眾多程式員最為深痛惡絕的呀！
建立軟體開發流程，其原始動機當然是為了改善軟體開發的生產力及品質，以便在花費最小的情況下，準時的交付產品。但是，似乎許多團隊在採用他們所挑選的開發流程後，反而不見生產力及品質的提昇，但卻引發了一些問題，而在這些問題中，程式員最在意的，當然是額外的人力資源消耗。程式員或許很喜歡寫程式，但喜歡寫文件的程式員恐怕是鳯毛麟角的稀有動物了。
當然，我認為這問題並不出在開發流程上頭，關鍵還是在於人如何看待開發流程。
就從管理者開始說起吧。有些管理者可能的迷思，是他們將開發流程看待成為一種制度化的工具。某種角度來看，這樣的想法倒也沒有太大的錯誤，但是，有些管理者會認為，開發團隊採用愈是繁重的開發流程，引入愈多的系統或是表單，產出愈多的書面文件，就代表開發團隊本身制度化的程度就愈高。而對管理者而言，制度化是一件重要的事，什麼事都應該要制度化，制度化代表著他的管理上軌道，所有被他管理的一切，都在這軌道上依照該有的秩序在運行著。在這種思維下，很容易產生像「CMMI對軟體開發的成熟度分為五種等級，那麼當然是等級愈高愈好」的認知。
對一名程式員而言，當管理者對於開發流程是如此看待時，那無疑是一場災難。此時，建立開發流程的目的，是在於打造一個從管理面來看「看似井井有條」的完整制度時，便不再是針對開發本身的目的去建立流程。
在開發流程中勢必投入的一些活動，而這些活動並不是撰寫程式碼，因此，嚴格來說，不算是對最後產出有直接貢獻的活動。因此，從某種角度來看，這些活動也算是一種額外的成本。
但事實上這樣的成本，其實算是一種投資，因為我們希望透過這些活動的進行，能夠達成引入開發流程的原始目的，也就是縮短開發時程、減少投入的人力及資源，維護良好的品質等等。既然是投資，總不會希望投入的成本大過於最後能回收的收益吧？但事實上，許多團隊施行他們所選用的開發流程後，不僅未蒙其利，反而身深其害。這其中的原因又是在那邊呢？問題終究還是因為許多工作僅僅只是表面功夫，徒具形式罷了。
舉例來說，許多流程設計了需求規格文件的撰寫工作，而這個工作有一個重要的目的，也就是記錄、描述規格使用者的需求。達成這個目的後，開發團隊便可以依據這份文件，理解使用者心目中所想像的系統，究竟是長成什麼樣子。而使用者可以憑藉著這份文件，去了解開發團隊在一次或多次的需求訪談��程中，他們所理解的系統，究竟又是長成什麼模樣，並且可以進一步的進行確認。
這樣的文件，對開發來說，當然是相當重要的一份文件。許多專案的開發，之所以遇到瓶頸，最終都是源自於需求管理上的問題。需求管理的基礎是了解需求，而了解需求代表必須和使用者對於系統的最終產物建立起共識。倘若缺乏了這一層共識，開發團隊自己開發自己想像中的空中樓台，等到使用者開始進行測試時，才驚而不喜的發現，原來開發團隊開發的系統，竟然不是自己想要的。這時候，就得花費更多的力氣來進行矯正。你可以想像，之後必須要付出的代價究竟有多高昂了。所以，需求訪談的活動、需求規格文件的撰寫、以及需求規格文件的確認，算是我們對於開發的一項投資。沒錯，它是會帶來額外的人力負擔，但它所預期帶來的回報，便是開發團隊得以降低日後因為沒有精確掌握需求所付出更為驚人的人力消耗。
但是，一般來說，我們所看到的，大多是徒具形式的需求規格文件。他們或許排版整齊，看起來該有的章節一應俱全，但很可惜的，因為撰寫的人並不是以詳實記錄使用者需求並做為與開發團隊溝通為基礎的方式來進行撰寫，他不過只是依據著文件的樣板，一個蘿蔔一個坑的填些東西進去，讓這份文件看起來像是樣樣俱全（這實在是我們時常可以觀察到的殘酷事實）。但這份文件之所以需要存在的真正目的，除了記錄之外就是溝通－不僅要完整、精準描述欲開發的系統長相，更要藉此減少使用者和開發團隊的認知差異。
但徒具形式的文件，卻無法達成上述的目的。這麼一來，撰寫的人花了大量的時間撰寫這份文件，這份文件卻發揮不了它應該要發揮的效果。開發團隊花費了成本，卻無法回收投資。
徒具形式是最可怕的，因為它比不去做還要糟糕。而一些團隊在施行開發流程時，很容易陷入徒具形式的陷阱中，他們講究要去執行流程中所規劃的活動，以便讓他們看起來像是極具制度化的在運作著。例如，他們執行流程中所規範的文件撰寫活動，但卻又不去理解流程中之所以規劃此一活動的真正用意，最後的產出，不僅不能讓這份文件發揮溝通的效果，而且還白費了力氣及時間。這對於生產力、以及開發預算都是很大的傷害。
這或許正是許多開發人員，對於「開發流程」多半有著一些錯誤觀感的原因之一。事實上，開發流程是輔助開發團隊的工具，而不是障礙。倘若，對開發團隊構成了障礙，那麼，勢必需要認真思考，究竟是在那一個環節出了差錯了。
Posted at 12:26上午 五月 13, 2009 by Chien-Hsing Wang in General | 迴響[3]
