軟件

我是如何寫作一本軟體+哲學式的書籍的（上）做好這個決定後，就面臨一個很棘手的問題：怎麼不把這樣一本書寫成散文，這類書很容易想到那寫到那，針對各種東西，發一堆感觸，而後被命名為經驗分享。看到的一些書就是這個狀況，這未必沒意義，但這違背初衷，我是想寫本講本質，把事兒講透的書。而上面的寫法很像有把鎚子就把什麼都當釘子。做播放器的有益經驗給做驅動很可能就是毒藥。就好比說，單純從現象來看，世界各個角落髮生的事都不一樣，但從牛頓定律的角度看，很多事情是一致的。好容易寫個東西，怎麼也得奔牛頓定律去---當時真

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

#好久沒來，以此文章清清雜草吧！眼下比較常用的軟體知識歸類法是以關鍵字為導向的，但感覺這種分類法挺誤人子弟的。比如：· 程式設計語言與程式設計· 軟體工程及軟體方法學· 軟體專案管理· 軟體需求· UML· 建模· 極限編程· 軟體方法/軟體工程· 物件導向· 軟體品質、軟體測試及維護· 軟體過程· CMM(軟體能力成熟度等級模型)· 設計模式· ... ...     “設計模式”，“極限編程”和“物件導向”之所以成為不同的類別主要的原因應該是他們使用了不同的關鍵字，而並非兩者間本質上有什麼區

　　經過近十年的發展，說Java是地球上最受歡迎的程式開發語言一點也不為過。Java賦予開發人員高度的選擇自由，展現「Java Everywhere」的魅力與成效你我的生活周遭已處處可見Java;到火星上走走、eBay大採購、網路銀行轉帳、拿著健保卡到醫院看病、無聊時把玩手機上的Java遊戲…。 　　在生活中，你通常只知道「喔!原來這網站是用Java寫的」、「喔!原來這是手機的Java Game」。若自技術層次拆解，Java Technology可簡單區分為Java 程式語言(language)

我畢業後的第一個職務是軟體工程師,研發部門的,但我的第一個任務,卻是做調研;就因為當時我不清楚研發和調研的細緻區別,不能把角色給轉換過來,所以還鬧了一些笑話,現在想來,還真是挺有意思的.調研應該屬於需求的第一階段:需求的discover階段.調研階段應該完成下面的任務:瞭解客戶現狀,如客戶的資訊化程度,客戶的算機操作水平,客戶的業務模式等;與客戶溝通交流,理解客戶需求等.調研完後,應該出來一份調研報告,一般稱為可行性分析報告初稿.上面的事情應該是由售前人員去完成.需求的discover階段的最後

品質目標每個階段結束之前進行審核，若沒有達到，則認為此階段不能結束。編碼階段結束的標準是：功能全部實現，代碼注釋率≥20％，CodeReview和單元測試達到或超過品質目標要求。 核心部分Code Review缺陷率（個/KLOC）≥3，50K代碼是3×50＝150個缺陷。單元測試缺陷率（個/KLOC） ≥1.5 產品整合缺陷率（個/KLOC） =4 系統測試缺陷率（個/KLOC） =5 發布前的總缺陷率要求≥（3+1.5+4+5）=13.5個/KLOC 不要留給產品整合和系統測試太多的問題，

這個微軟命令列是是什麼意思，就是你單擊"開始-運行..."後彈出的對話方塊程式。同步選取win鍵和R鍵也可以啟動這個程式。我日常工作頻繁使用微軟的這個小軟體。例如我製作了一個包含常用電話號碼的文字檔phone.txt，放在c:/winnt目錄下，要查電話號碼，就按"Win－R"鍵，然後輸入phone.txt，用notepad開啟。這樣比啟動outlook或者lotus

從源碼編譯安裝東東，不是很容易，想想在使用lfs之前，源碼編譯安裝軟體從來沒成功過，甚至出現錯誤都無從下手，只能放棄 經過lfs的洗禮，總算對源碼編譯安裝有了一點認識，可惜當初沒有把這些經驗寫下來 不過現在開始寫也不遲 :)  將編譯中遇到的問題及解決的方法記下來，積累經驗，也可以讓來往的newbie對源碼安裝軟體瞭解一些，多一些成功機率，畢竟從源碼包編譯東東還是有一定好處的 ^_^先說一下源碼編譯的基本方法及源碼編譯過程中幾個重要的檔案，以及重要變數PKG_CONFIG_PATH

最近被兩次問到同一個問題：如果一個軟體需要大量密集的設計工作，導致存在獨立的設計和Team Dev，應如何實施敏捷開發？整體上講，敏捷開發不希望存在設計和開發的分離，因為這樣就會產生“設計文檔”這種東西，而且因為兩個團隊分離，設計文檔一定相當詳盡，而且在交接的時候多半要進行評審，否則很難保證Team Dev能理解並按其編寫代碼，最終還可能會導致兩個團隊的矛盾。在敏捷開發中一般這樣處理這種情況：將設計人員下放到Team

軟體“可運行”了就可以評審且通過了？這是個問題。在多年前參加Scrum Master培訓的時候，老師拿出一個很好的表格，每行是一個故事，每列大致如此：編碼完成功能測試單元測試整合測試壓力測試自動化的測試……這樣在計劃會的時候，PO就告知大家每個故事他的要求是什麼，一方面大家會因此對於要估計的使用者故事有一個更明確的理解，另一方面就是約定了評審會上這個故事的完成標準。 這個方法已經不錯了，不過後來又發現一個更好的：EA（一家遊戲公司）將其所有故事完成標準分為5級，分別是：1.

首先說下什麼叫“完美軟體開發”，想象一下，完美的圓在現實中是不存在的，現實中的圓只能是對完美的圓的迴歸，但完美的圓描述了圓的構成規則，完美軟體開發意義與此相同，它試圖描述軟體開發的規則和鐵律。但既然現實中不存在，探討完美狀態又有神馬意思？好，那我們再來看一個完美狀態：牛頓第一定律說：任何一個物體在不受任何外力或受到的力平衡時，總保持勻速直線運動或靜止狀態，直到有作用在它上面的外力迫使它改變這種狀態為止。這顯然也是一個完美狀態或者說理想狀態，現實中也是不存在的，那這東西又有神馬意義？個人感覺探討軟

如果不是以占卜的方式來預測未來，那麼就必須分析現實，並進行邏輯推演。對於軟體而言，決定其未來的主要因素有三個：軟體的外部要求，內在特徵，人員狀況。除此之外，法律法規，經濟環境等也會對軟體的未來產生影響，但如果把時間尺度放的比較大的話，那麼這些方面的影響則具有一定的偶然性，因此我們忽略這些相對比較次要的因素。軟體的外部要求又可以分為兩個部分：一為使用者的真實需要，一為軟體的商業模式。我們先從商業模式說起。Google經常發布一些免費的軟體，這對軟體行業產生了相當的衝擊。小到做GPS的廠商，大到微軟

#成為專案經理是需要積累的，如果你想快，但不想付出，那求神拜佛比較好。#這系列文章是寫給想成為專案經理，但又願意努力的人的。當我們開發軟體的時候，很多人知道要為目標軟體建模，好開發需求。而成為專案經理自身也是一種需求，為進一步開發其關鍵點，事實上也需要建模---為軟體開發自身建模。專案經理更類似帥才，單項未必是最優的，但在開發軟體時必須統籌全域。而統籌全域的前提則是對軟體開發自身形成了自己的想法，自己的道，這裡的“道”，即是屬於你自己的軟體開發模型。讓我們從最簡單的開始。軟體項目的基本輸入是：人

 這是敏捷生態系統系列的第一篇（之一，之二，之三，之四，之五）。所謂生態系統，就是指互相依賴方能生存的一系列生物。生態系統常常不是單向依賴的，而是互相依賴互相促進。敏捷開發中的實踐也是如此。典型地，當一個實踐很難實施時，一定不要認為簡單的制度可以保證其實施，而是要思考是什麼導致了它的失敗。比如每日立會，如果發現大家都不按時開會甚至不開會，馬上要做的不是要求大家按時開會+開會遲到給大家買水果+統計每月按時比例+……而是要想一想為什麼這些人不按時來，他們一定覺得這個會議不是很重要，會上講的東西聽的東

       本人與大家一樣，原來只是一個普通的程式員，靠給軟體公司打工謀生。後來感覺這樣長期幹下去沒有什麼前途，雖然現在年輕還可以加班加點靠拼身體吃飯，以後年紀大了怎麼辦？聽說很多人自己單幹每年靠共用軟體都可以賺幾十萬，我為什麼就不行？仗著自己技術好，並且當時已經有了成熟軟體的思路，我就辭職出來加入共用軟體這一行當了。通過半年多的日夜苦幹，軟體終於編出來了。由於我覺得自己的軟體功能比較新穎，編程的技術也很好，以為只要一發布就會大家搶著註冊購買，也可以像那些成名的共用軟體作者一樣每月坐拿幾萬元，

           之前一直從事企業軟體的開發，現在混跡於互連網行業。坦白的講這兩個行業還是有其區別的。今天看到以前的同事的微博“產品”是根本。有感而發，希望和大家一起探討。           以下是我的若干觀點：           產品是核心競爭力，核心競爭力來源於產品對業務的支撐；商務程序因行業、企業理念不同而差異很大，如何抓住這些規劃產品功能？軟體公司的規劃需求一般太過理論化；流程操作人員太過片面化和零散化；一般的實施人員認識不夠高度化...          

待軟體需求discover階段完成,也就是可行性研究完成,公司決定進行該項目/產品的開發後,就進入了軟體需求的define階段.define階段包括下面的事情:1)分析項目的風險,編寫項目風險控制報告.在國內,這個報告相當於一個擺設,文檔寫完就放那裡了;為什麼呢,因為控制風險需要成本,國內老總不想要成本,老總想要的只是MONEY&MONEY.2)明確項目的功能需求,整理項目的需求文檔.功能需求文檔可能不只一個,可能每個子系統都有單獨的需求文檔;不確定的功能需求應該用TBD來標誌;功能需求

     在軟體界，有多少因為沒有運用軟體工程的思想而開發失敗的‘案例，其中不乏令人恐懼的失敗，所以，如今軟體工程的思想以及各種促使軟體開發高效、成功的理論層出不窮，專案經理、系統架構師以及各條戰線的工作人員都對其非常重視，同時又有更多的編程大師在思考，有更多的優秀管理人才在實踐！可是，我們是否注意到這樣一些問題：專案經理、開發技術骨幹以及程式員他們是從何時開始編程的？他們在進入團隊開發之前，是否單獨或和夥伴一起開發過軟體？。。。。。。     

License簡稱全稱URLGPLThe GNU General Public Licensehttp://www.thebigfly.com/gnu/gpl/LGPLThe GNU Lesser General Public Licensehttp://www.gnu.org/licenses/licenses.html#TOCLGPLApache LicenseApache Licensehttp://www.apache.org/licenses/CPLCommon Public