軟件

　　軟體工程課我的觀念轉變　　之前瞭解到鄒欣老師教過的軟體工程課都是大四或研究生的課，我還曾抱怨過。　　我曾想過大三的代碼量還不夠很好地學習軟體工程，而且以我的理解這門課是將一定數量的程式員很好地融合進同一個工程的學習，類似於“介面的構建”。而現在連類內部的方法（個人對程式設計語言的掌握）都沒搞清楚，我們的資料庫等專業課還正在學，要很好地在工程中合作必然阻礙重重。　　有一段時間我一直都是這個想法。　　其實自第一天學C開始，我就一直聽到人們在說像learn by

 　　為期一學期的軟體工程課終於結束了，總結這段時間來軟工課的學習生活，我深有體會。　　第一感覺就是這課的作業微多，忽略大大小小的閱讀作業的話，個人編程一次，結對程式設計兩次，團隊作業一次。上過這課才覺得以前的什麼JAVA、C++這些一學期一個大作業的課都弱爆了。為期一周的個人編程完全是在趕工中完成的，雖然最後好不容易按時趕完交上了，但是程式出來的結果卻沒有那麼理想，沒來得及最佳化也沒進一步審閱，結果出錯連連，但是自己真的已經花費了很大時間和精力了。　　第一次作業剛提交，第二周結對程式設計作業就

 第一部分——找BUG        

文章目錄  Team homework #2: innovation in new application domains.   這是現代軟體工程課的作業列表, 老師可以根據情況選用, 建議要保證每周都有作業。 團隊作業 Team Homework: 適合團隊完成的作業 這些作業都要團隊的成員互相配合才能完成,  團隊可以選出一位同學完成作業的具體寫作和發部落格部分, 大家可以輪流完成。 一個團隊通常由 5-7名隊員組成,

組員：劉牛頓 郭立軒測試軟體：必應繽紛案頭版本：1.1.165.0環境：win7普通版，x32，Intel(R) Core(TM) i5 CPU，4GB

from http://codecanvas3706.spaces.live.com/blog/cns!5A77585898179960!205.entry [當學生的時候, 最好犯一些錯誤,  經曆一些失敗.  不經曆一些慘痛的失敗, 難道要到工作的時候才失敗麼?

互連網時代對於創新者來說, 既是一個偉大的時代, 又是一個糟糕的時代。 你有很多機會做出影響世界的產品,  但是, 似乎任何想法都被別人想到過了, 做出來了, 上市了, 移植到各種平台上去了…  那麼我們後來人除了羨慕別人生得早, 還有什麼機會呢?  但是往往不經意間, 在同學們熱衷於偷菜, 三國殺的時候,  又一批新的想法, 新的技術蜂擁而至, 別人又想出了新的點子, 新的商業模式.  我們的菜偷了不少, 三國殺玩了好幾個通宵,  但是想法還是沒有 …在《現代軟體工程》 這門課裡,

有同學問我這個問題：“你正在做一個項目，這個項目有一項關鍵的feature需要實現，這個feature有一定的技術難度，你調試了很久，都沒找到實現的途徑，這時你已經在這個feature上花了很多時間了，而且無法預期解決需要多長時間。在這種情況下，你會怎麼做？”  一種典型失敗的情況是：第一天：我正在做一個關鍵的feature, 看起來不難，做好了會很有面子。。。第三天：就是搞不通，就這樣過了三天，其中“murphy's

在前一個部落格裡 (典型使用者), 我們講了怎麼收集, 分析和驗證使用者的需求。 這裡我們講 spec – specificationSpecification, 又叫spec, 有兩種:    a) functional spec, 軟體功能說明書, 主要用來說明軟體的外部功能, 和使用者的互動情況 (把軟體當作一個黑盒子)    b) technical spec, 軟體技術說明書, 又叫 design doc, 設計文檔, 主要用來說明軟體內部的設計 (把軟體當作一個透明的箱子)有同學說,

敏捷開發, 誰不會呀, 不就是沒文檔, 出活快, 使用者說啥都能改?下面是一個笑話,  王屋村的大牛說 - 我最近轉手接了一個活, 完事能掙四五萬, 我拿過圖紙一看, 不就是蓋一煙囪嗎? 我們是敏捷 (Agile) 的團隊，要文檔作甚? 馬上開始幹活！    都快蓋好了， 客戶來檢查，把我打了一頓！我冤枉啊！   原來, 圖紙看倒了，人家讓挖口井。不過, 我們是敏捷的團隊, 被客戶打了也要擁抱變化, 好不容易砌好的煙囪不能這麼廢了, 要不斷重構, 代碼重用。 於是我們在地上挖了一個大坑,

很多大學裡是把軟體開發相關的專業劃入工科的，這給人一種錯覺，讓人認為軟體開發也是一個工程學科，就像土木建築，動力機械那樣。但這從根本上錯了，土木建築，動力機械的背後有確實的科學定律作為支撐，而軟體開發的背後基本上什麼都沒有，遠不是一種“科學”。也正因此，“軟體工程”的現實意義也就遠不如“土木工程”，“動力工程”。 每個人對“科學”的定義可能不同，但在這裡，我們可以做一個簡化版的定義：當有一組在限定條件下顛撲不破的定律做支撐時，相應的知識，我們可以稱之為科學，科學自身可以體現為一種確定性。比如說：

在眾多軟體相關的知識中，軟體工程絕對是很特別的一個。很多人很鄙視軟體工程，說：我一看到軟體工程的書就直接略過；與之相對應，很多人很推崇軟體工程，會花很大的心思去研究敏捷、CMMI等。剛入職場的程式員大致上是討厭軟體工程的，因為這東西離自己的實踐有點遠，並且主要是添加束縛。 但既然更加複雜紛繁的曆史都可以總結出規律，軟體開發沒道理就總結不出可以遵循的規律。也許真的事實是：並不是軟體工程沒有用，而實在是很多軟體工程的書籍理論飄的太高，落地上有困難。 軟體工程一個很大的困境在於，它總是試圖以軟體整體為

軟體開發是個奇妙的行業。你可以說它複雜，但與此同時，隨便有個人，只要接受點培訓就可以做軟體開發。你也可以說它簡單，但據統計世界上一半以上的軟體項目會以失敗收場。 強調軟體複雜的最有代表性的觀點來自《人月神話》：Brooks認為複雜性是軟體的根本特質，而非偶然特質。強調軟體簡單性的觀點則時見於國內某些MIS開發公司以及外包公司：他們大多時候會把需求分析（業務分析）的權重抬的很高，而把設計編碼的位置壓的很低。 這種迷思其實不難打破，但在此之前要對軟體的特質做一點考察。 軟體自身是一種固化的思維，其必

（接前一篇，繼續）   第五重：技術變化快，積累上不去  設想一下，一個10年前的高手，這10年他什麼也不學，那他今天會是什麼樣的一個狀況。 我個人估計是快被淘汰了。 這是個極端的例子，但回顧一下軟體的發展曆程你會發現，新技術的出現是爆炸式的。 在DOS的時代裡，軟硬體的距離非常近，你只要會一種語言，瞭解基本演算法和資料結構，再瞭解電腦硬體的知識，你就可以寫大部分的程式。 接下來軟體和硬體間的層次越來越多，Windows加上一層，Java虛擬機器加上一層，瀏覽器加上一層，Flash等再加上一層，

軟體開發沉思錄--ThoughtWorks文集(china-pub首發)（來自軟體界思想領袖們的經驗心得）。看試讀的兩章：第五章充斥著狗屎，第十三章卻瑕不掩瑜。第五章的一個問題在於討論的大多數問題都是虛的：比如在Java與Ruby的比較中提到的落單方法。這樣的話題根本沒有真理可言，而作者卻毫無顧忌地認為它（沒錯，“它”）的觀點就是對的。但這還不是傷害性的；下面就這個例子說一下狗屎從何而來。仔細看Java版的isBlank函數，其中對null的判斷，對length的判斷，對每個元素（這裡是字元）是

軟體名稱: HowTired (看看你的勞動強度)版本: 1.0 beta開發環境:Windows Server 2003 + .Net Framework 1.1C# + Win32 API功能:1. 監視滑鼠的點擊次數, 左鍵, 右鍵2, 監視滑鼠一共移動的距離3, 監視鍵盤的敲擊次數, 詳細統計到每個鍵.4, 開始運行以後最小化到工作列, 開始監視不足:1. 由於程式一直駐留後台, 導致所佔資源越來越大2. 準備加上一個每天日誌的功能, 記錄每天的勞動程度3. 有時候會造成系統特別的慢,

聽了北京INTETA第三次活動的講座以後，最近對一些開發過程中的品質控制相關的東西感興趣，找了NUnit、NAnt、Draco等等相關的資料看了看，雖然都沒有深入瞭解，不過對於目前公司的開發流程的改進有了一些新的想法。按照我的想法，對於我們目前的團隊規模（項目都很小，一般就是2、3個人，最多的時候是5個人），開發流程可以這樣做：需求調研：是一個重點，雖然不至於要搞得非常清楚，但是對於要實現的商務程序、客戶的具體需求是一定要搞清楚的；目前的幾個項目都在這上面吃了大虧，甚至於由於設計無法修改而推翻重

幫LP找了一個osCommerce做網上商店，給自己在家裡的機器上裝了一個Plog寫日記；都是基於PHP+MySQL的開源項目，在Windows下運行都很順利，而且都找到了簡體中文語言套件，用起來很方便。工作中還用到了TortoiseCVS、Mantis、CommunityServer等開源軟體，有些有現成的簡體中文語言套件，有些需要自己手工修改，有些則只能使用英文版的軟體（只能對原始碼進行翻譯；雖然有原始碼，但是對原始碼進行一點點的翻譯工作量太大，而且這種翻譯方法在原始碼升級後就又要重新來過）

軟體架構引言之專案管理的問題 很多朋友都有過或者正在管理一個或者多個軟體項目，那麼我的文章就從這個問題開始：如果單純從表象來說，軟體專案管理過程中暴露的最大問題是什嗎？ 不同的人的會有不同的答案，但是大致這樣的答案我想大部分人都是會認可的，那就是“進度拖延”。進度拖延當然是表象之一了，其他諸如品質不過關、功能不完整等等，我覺得都是和進度拖延密切相關的。很多專案經理都想去做那些認為是十分必要的事情，比如計劃、測試等，但是“沒有時間”。為什麼會沒有時間？等到項目總結的時候，我們總會羅列出一大堆的理由