軟件

  站立會議，又叫每日會議，是極限編程方法的組成部分之一。每天早上都要來一次站立會議，主要用於溝通問題、方案，以集中小組注意力。    一聽到這個名字可能就會讓人產生反感。每日會議，真是文山會海啊！其實不然。stand-up meeting就是讓參加人員站著開會以縮短時間和提高效率，一般情況下只會持續10分鐘。當然，根據項目人數不同，時間也會有多有少。每日會議的議題十分確定，只用回答以下五個問題就行：    1. 自從昨天工作之後，你都做了些什嗎？     2.

      公司要招聘“Senior Software Engineer - Audio/Speech Code” 人才，如有覺得能勝任者可以把簡曆發給我，我先review一下，然後再推薦，過了我的review，就沒什麼問題。具體要求： To develop, optimize and port various audio/speech codecs on different

     前幾天一個朋友提到我的部落格中空空如也。確實，到園子裡也有段日子了。確實也該放點東西了。要不也太對不起DUDU了。這幾天又比較清閑,將讀書筆記及自己的心得記錄下來     McConnell 大俠說如果設計能實現如下目標，那麼就是非常好的設計了。    一:最少的複雜度        簡單來說，就是要易於理解。McConnell特別還指出了要避免“聰明的”設計。  另外我們在設計某處的時候要能夠安全的忽視其它部分才算合格。   二:易於維護      

        正確性：系統滿足規格說明和使用者目標的程度，即，在預定環境下能正確地完成預期功能的程度。 　　健壯性：在硬體發生故障、輸入的資料無效或操作錯誤等意外環境下，系統能做出適當響應的程度。 　　效率：為了完成預定的功能，系統需要的計算資源的多少。 　　完整性（安全性）：對未經授權的人使用軟體或資料的企圖，系統能過控制（禁止）的程度。 　　可用性：系統在完成預定應該完成的功能時另人滿意的程度。 　　風險：按預定的成本和進度把系統開發出來，並且為使用者所滿意的機率。

使用者例事    使用者例事（User Story）用於描述使用者通過系統完成其一個有價值的目標。使用者例事只是以客戶能夠明白的方式，描述了一個系統的外在行為。而像產品採用何種語言實現、採用何種架構、哪種資料庫等則不應該包含在其中。使用者例事不應該太長太大，一個籠統的使用者例事可以和一些作為補充的使用者例事聯絡起來。只要一個使用者例事最終覆蓋所有需要的細節，那麼它就不需要再進行分解。   

有如下理由：1.軟體發展的趨勢。a。軟體第一期，個人英雄時代，軟體由程式員的感知決定，有很大隨機性。b。軟體第二期，手工作坊，3，5個人，五六條槍，開發快速，代碼品質參差，介面不統一，易用性差，只關注功能實現。c. 工業製品，標準統一，品質高，但是面孔單一，缺少內涵。d。藝術品，每一件如同青花般完美有韻，精雕細作，流暢易用，沒一處不舒服。2.蘋果的成功影響。蘋果的成功不只是技術和戰略的成功，蘋果的一切都做得如此的完美，可以稱作科技藝術家。3.充分競爭的結果，使用者的品味在提高。

Google這個公司現在已經是“家大業大”了，他們總是隔三岔五地推出一些新鮮的服務，讓業界跟著也興奮一把。不過曆年來Google所發展出來的服務和軟體實在太多了，究竟他們已經有了什麼服務？現在就來看看吧。　　Add to

這篇文章是第100篇部落格，該文章將我看過的好書總結一下，對後來人也有一個好的指導。看書和網上搜尋相比，看書更加系統，更加全面，效率也更高，另外建議不要看電子版，看書還是看印刷版的方便看。C語言入門好書：《C程式設計》譚浩強著，該書言簡意該，通俗易懂，非常適合入門學習；深入學習：《C專家編程》；C++語言文法學習：《C++ Primer

核心思想：objdump -d 找到關鍵彙編代碼，然後用ghex2 開啟可執行程式，修改和彙編對應的機器碼,當然前提是對彙編足夠瞭解。下面講一個簡單在linux上的例子：1.   先建立一個簡單的程式， #include <iostream>using namespace std; bool abc(){return false; }int main(int argc, char *argv[]){if(abc()){cout << "hacked" <<

1.B/S方面,  簡要介紹企業內部系統的設計需要注意哪些問題.   然後就提到的效能,安全,可擴充性,可用性等非功能性特性中的一點或幾點深入的討論2.資料庫效能問題  資料庫設計一般需要注意哪些  索引如何設計  如何快速定位在較高負載時造成效能問題的預存程序或查詢語句  你自己一個功能較複雜的預存程序,如何評估它的效能,以及達到什麼樣的標準才簽入到產品中3.設計  關於組件對外提供的介面,需要注意哪些 

 　　軟體測試是軟體開發的一個重要環節，同時也是軟體品質保證的一個重要環節。所謂測試就是用已知的輸入在已知環境中動態地執行系統（或系統的組件）。測試一般包括單元測試、模組測試、整合測試和系統測試。如果測試結果與預期結果不一致，則很可能是發現了系統中的錯誤，測試過程中將產生下述基本文檔： 　　（1）測試計劃：確定測試範圍、方法、和需要的資源等。 　　（2）測試過程：詳細描述和每個測試方案有關的測試步驟和資料（包括測試資料及預期的結果）。

讀了一下覺得很不錯，轉載一下給大家～在IT領域做自由工作者是很合適的。有很多開發人員都有過做自由工作者的經曆。有很多書籍和文章將了如何讓客戶滿意以及如何及時的交付正確的軟體。但是很少文章講述客戶在項目過程中應該如何做。雖然客戶付了錢，但這並不意味著我們要容忍他們非常粗魯的態度和錯誤的習慣。1. 好的軟體一定不便宜

軟體各種版本號碼存檔，不停完善，以備參考，歡迎提供修正。α(alphal)版此版本表示該軟體僅僅是一個初步完成品，通常只在軟體開發人員內部交流，也有很少一部分發布給專業測試人員。一般而言，該版本軟體的bug較多，普通使用者最好不要安裝。β（beta）版該版本相對於α版已有了很大的改進，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過大規模的發布測試來進一步消除。這一版本通常由軟體公司免費發布，使用者可從相關的網站下載。通過一些專業愛好者的測試，將結果反饋給開發人員，開發人員們再進行有針對性的修改

軟體的智能和記憶功能使用者登入介面最好有使用者名稱和ID的記憶，焦點直接定位到密碼輸入框;單據錄入介面最好有儲存和載入預設值的功能;單據搜尋介面可以儲存使用者自訂的各種搜尋條件組合;使用者調整過的GRID的列寬，視窗的位置可以自動記憶;系統可以根據使用者的使用頻度對相關功能進行自動的優先順序排序;系統能夠記憶不同使用者的使用偏好，使用系統的固有模式和常用的自訂設定;減少不必要的重複互動減少不必要的各種操作，能夠點一次滑鼠或敲一次鍵盤完成的絕不作出兩次或多次;提示資訊要適度，太多不好，太少也不好;

1.以偏蓋全，行業適應性差2.缺乏先進的管理思想指導3.閉門造車，缺乏實用性4.以次充好，假冒偽劣5.命懸一線，安全性，保密性問題成堆6.鼠目寸光，軟體適用性較差7.僵化，死板，系統的可操作性差8.千瘡百孔，邏輯錯誤太多，無法合理控制流程9.各個模組分裂割據，整體功能根本無法體現 這9個缺陷原本是拿來說目前國內的ERP行業軟體的，但是拿到我們目前的軟體開發過程中，也是應該盡量避免的事情。記錄在案，以示警戒！

看到51CTO上一篇文章，覺得很適合目前的狀況，收藏起來自省。。。 想成為一名優秀的軟體開發人員需要很長時間的培訓和實踐。但是如果不遵循合適的原則，即便是再好的程式員也會成為失敗的犧牲品。不經意間你就會養成 一些可怕的壞習慣，它們可能會一而再再而三地出現，甚至對於經驗最為豐富的程式員而言也是如此。我認為軟體開發至少存在七宗罪。那麼，就請看看慾望、暴

Java 開源軟體的集合Java Open Source Software推薦這個網站，主要是對 Java 開源軟體做個集中的按功能分類介紹。 不錯的工作。比如你要找哪方面的開源軟體，從這裡索引會立馬知道這個領域有哪些最出名的開源資源。比如我曾經找 Java 的開源 Weblog 系統、Java 的開源 Forum 系統等，經曆不是很好。有了這個網站會好點的。想起來現在的 Matrix專題 功能也是類似的。 我把它定位為 “連結資源”，只是分類與他有不太一樣，採用的一些是 J2EE

一：UML與設計模式　　軟體構架　　（1）IT行業的人才結構與軟體構架師的定位　　（2）軟體構架師應掌握的知識體系　　（3）軟體架構設計的特點、層次、分類　　（4）軟體構架的主要理論、方向和趨勢　　（5）軟體工廠，實現軟體開發的產業化　　軟體生命週期進程模型　　（1）RUP與XP　　（2）MSF　　（3）Agile與CMMI　　使用UML進行軟體架構設計　　（1）需求建模（域建模，用例建模）　　（2）業務建模　　（3）架構建模　　（4）應用建模　　（5）資料庫建模　　（6）測試建模　　（7）利用

“方案”和“可行性分析”屬於前期。MyProcess工作活動工件角色需求需求萃取需求分析需求規格需求驗證需求變更控制與版本管理需求管理計劃需求說明書需求模型系統原型業務分析員系統分析員設計架構設計資料存放區設計詳細設計設計規格設計驗證設計變更控制與版本管理架構設計說明書資料設計說明書詳細設計說明書設計模型架構原型架構師設計員實現編碼規範實體設計編碼、單元測試與並行開發持續整合代碼複審代碼變更控制與版本管理編碼規範實現模型代碼編譯單元代碼注釋程式員整合員測試測試需求測試計劃測試設計測試實施測試執行

在上文中，我介紹了Internet技術，WEB服務在家夠方面給了我們更多的選擇，但軟體設計中採用何種架構仍然是件令人頭痛的事情。 　　兩層系統（圖12）允許使用者介面和應用程式代碼直接存取資料庫和網路儲存的API。應用程式使用資料庫中儲存的資料模型，但是不需要在該模型之上建立邏輯模型。當開發中的系統是一個原型系統或者已經知道其生命週期較短，期間API不會發生變化的時候，兩層應用程式是理想的。典型情形下，這種方式用於小型的應用程式，它們的開發成本和時間都很少。 　　　　 圖12.兩層架構