The Martian Principles for Successful Enterprise Systems: 20 Lessons Learned from NASAs Mars Exploration Rover Mission
暫譯: 成功企業系統的火星原則：來自NASA火星探測車任務的20個教訓
Ronald Mak
- 出版商: Wiley
- 出版日期: 2006-05-01
- 售價: $1,280
- 貴賓價: 9.5 折 $1,216
- 語言: 英文
- 頁數: 138
- 裝訂: Paperback
- ISBN: 0471789658
- ISBN-13: 9780471789659
海外代購書籍(需單獨結帳)
相關主題
商品描述
Description
- For the first time ever, the senior architect and lead developer for a key enterprise system on NASA's ongoing Mars Exploration Rover mission shares the secrets to one of the most difficult technology tasks of all-successful software development
- Written in a conversational, brief, and to-the-point style, this book presents principles learned from the Mars Rover project that will help ensure the success of software developed for any enterprise system
- Author Ronald Mak imparts anecdotes from his work on the Mars Rover and offers valuable lessons on software architecture, software engineering, design patterns, code development, and project management for any software, regardless of language or platform
Table of Contents
About the Author.
Preface.
Acknowledgments.
Introduction.
Part 1 The Martian Principles.
Principle 1 Don’t reinvent the wheel.
Someone Else Has Already Solved Your Problem.
Understand What Your Added Value Is.
Use Commercial Software Whenever Practicable.
Principle 2 You won’t do better than what’s already been done.
Adhere to Industry Standards and Best Practices.
Seek User Groups, Chat Forums, Online Documentation, Books, and the Like.
Do Not Gum Up the Plumbing.
Principle 3 Your customers don’t know what they want.
Do Not Push Too Hard on the Requirements.
Do Rapid Prototyping and Lots of User Testing.
Customers Are the Best Testers.
Principle 4 Get something working as soon as possible.
The First End-to-End Thread Is Critical.
Working Code Builds Confidence.
Always Build on Top of Working Code.
Principle 5 Use sound software engineering practices.
Use a Component-Based Architecture.
Use Design Patterns.
Get All the Development Team Members to Agree.
Principle 6 Don’t trust the client applications.
Be Very Paranoid—They Are Out to Get You.
If You Do Not Break It, They Will.
Principle 7 Plan to make changes.
Do Not Hard-Code Values.
Use External Editable Parameter Files.
Implement a “Read Parameters” Method.
Maintain Client Parameter Files Centrally on the Server.
Identify the Parameter Values.
Principle 8 You can’t predict the future.
Make Each Service Dynamically Reconfigurable.
Create Field-Replaceable, Plug-and-Play Services.
Hot Redeployment Allows Reconfiguring without Rebooting.
Make Each Service Loosely Coupled.
Take a Peek into the Future.
Principle 9 Don’t tie your services into knots.
Keep Your Services Independent of Each Other.
Services Should Treat Other Services As Equals.
Principle 10 Build early, build often!
The Major Challenge Is Not Code Development but Code Integration.
Use a Source Code Repository.
Maintain a Separate Environment in Which to Build and Deploy.
Principle 11 “What middleware?” should be your greatest compliment.
The Middleware Should Be Invisible to Users.
Good Middleware Creates Ideal Virtual Worlds for the End Users.
Principle 12 Expose the invisible.
Put Hooks in the Middleware.
Do Runtime, Real-Time Monitoring.
Principle 13 Log everything.
Do Not Turn Off Logging in Your Production Code.
“Log Mining” Reveals Usage Patterns.
Principle 14 Know the data.
Learn the Data Usage Patterns.
Create Appropriate Application and Middleware Data Models.
Map to Practical Physical Data Models.
Adapt to Third-Party and Legacy Data.
Principle 15 Know when it will break.
Do Lots of Stress Testing.
If You Do Not Find Out What the Limits Are, Your Users Surely Will.
Principle 16 Don’t fail due to unexpected success.
Missions May Last Longer Than Expected.
Data Repositories May Grow Larger Than Planned.
Part 2 Project Management and Software Engineering.
Principle 17 Strong leadership drives a project to success.
A Good Architect Must Also Be a Good Leader.
Any Architecture Is Only As Good As Its Implementation.
Strong Project Management Is Necessary for Success.
Project Milestones Are Opportunities for Demos and Rebalancing.
The Project Milestones Near the End Allow You to Get Your Project Done on Schedule.
Principle 18 Don’t ignore people issues.
Software Projects Are Not Democracies.
Agree to Disagree, but Then Move On.
Scale the Project According to the Team Members’ Abilities and Experience.
Do Not Be a Slave to the Latest Project Management Methodology.
Foster Good Communication Plus Teamwork, Teamwork, Teamwork.
Remove Team Members Who Cannot or Will Not Perform.
Principle 19 Software engineering is all about the D’s.
Discovery.
Diplomacy.
Definition.
Design.
Development.
Debugging.
Documentation.
Deployment.
Dmaintenance.
Principle 20 The formulas for success aren’t complicated.
Successful Architect = Good Designer + Good Developer + Good Leader.
Successful System = Good Architecture + Good Software Engineering.
Keep It Simple!
Index.
商品描述(中文翻譯)
**描述**
- 這是首次由NASA持續火星探測車任務的主要企業系統的資深架構師和首席開發人員分享成功軟體開發這一最具挑戰性的技術任務的秘密。
- 本書以對話式、簡潔且直截了當的風格撰寫，呈現從火星探測車專案中學到的原則，幫助確保為任何企業系統開發的軟體成功。
- 作者Ronald Mak分享了他在火星探測車工作中的趣事，並提供有關軟體架構、軟體工程、設計模式、程式碼開發和專案管理的寶貴經驗，適用於任何軟體，無論語言或平台。
**目錄**
**關於作者**
**前言**
**致謝**
**導言**
**第一部分 火星原則**
**原則1 不要重新發明輪子。**
- 別人已經解決了你的問題。
- 了解你的附加價值是什麼。
- 在可行的情況下使用商業軟體。
**原則2 你不會做得比已經做過的更好。**
- 遵循行業標準和最佳實踐。
- 尋找用戶群、聊天論壇、在線文檔、書籍等。
- 不要堵塞管道。
**原則3 你的客戶不知道他們想要什麼。**
- 不要對需求施加過大壓力。
- 進行快速原型設計和大量用戶測試。
- 客戶是最好的測試者。
**原則4 儘快讓某些東西運行。**
- 第一個端到端的線程至關重要。
- 可運行的程式碼建立信心。
- 總是基於可運行的程式碼進行開發。
**原則5 使用健全的軟體工程實踐。**
- 使用基於組件的架構。
- 使用設計模式。
- 確保所有開發團隊成員達成共識。
**原則6 不要信任客戶端應用程式。**
- 要非常偏執——他們是想要你的。
- 如果你不破壞它，他們會。
**原則7 計劃進行變更。**
- 不要硬編碼值。
- 使用可編輯的外部參數文件。
- 實現“讀取參數”方法。
- 在伺服器上集中維護客戶端參數文件。
- 確定參數值。
**原則8 你無法預測未來。**
- 使每個服務可動態重新配置。
- 創建可現場更換的即插即用服務。
- 熱重部署允許在不重啟的情況下重新配置。
- 使每個服務鬆散耦合。
- 瞥見未來。
**原則9 不要把你的服務綁成一團。**
- 保持服務之間的獨立性。
- 服務應該平等對待其他服務。
**原則10 早建設，常建設！**
- 主要挑戰不是程式碼開發，而是程式碼整合。
- 使用源代碼庫。
- 維護一個獨立的環境來構建和部署。
**原則11 “什麼中介軟體？”應該是你最大的讚美。**
- 中介軟體對用戶應該是不可見的。
- 良好的中介軟體為最終用戶創造理想的虛擬世界。
**原則12 曝露不可見的東西。**
- 在中介軟體中放置鉤子。
- 進行運行時、實時監控。
**原則13 記錄所有內容。**
- 不要在生產代碼中關閉日誌記錄。
- “日誌挖掘”揭示使用模式。
**原則14 了解數據。**
- 學習數據使用模式。
- 創建適當的應用程式和中介軟體數據模型。
- 對應實際的物理數據模型。
- 適應第三方和舊有數據。
**原則15 知道何時會崩潰。**
- 進行大量壓力測試。
- 如果你不找出限制，使用者肯定會。
**原則16 不要因意外的成功而失敗。**
- 任務可能比預期持續更長時間。
- 數據庫可能比計劃的更大。
**第二部分 專案管理和軟體工程**
**原則17 強有力的領導推動專案成功。**
- 一個好的架構師必須也是一個好的領導者。
- 任何架構的好壞取決於其實施。
- 強有力的專案管理對成功至關重要。
- 專案里程碑是演示和重新平衡的機會。
- 專案結束前的里程碑讓你能按時完成專案。
**原則18 不要忽視人員問題。**
- 軟體專案不是民主制度。
- 同意不同意，但然後繼續前進。
- 根據團隊成員的能力和經驗調整專案規模。
- 不要成為最新專案管理方法的奴隸。
- 促進良好的溝通和團隊合作，團隊合作，團隊合作。
- 移除無法或不願意執行的團隊成員。
**原則19 軟體工程全在於D的。**
- 發現。
- 外交。
- 定義。
- 設計。
- 開發。
- 除錯。
- 文檔。
- 部署。
- 維護。
**原則20 成功的公式並不複雜。**
- 成功的架構師 = 好的設計師 + 好的開發者 + 好的領導者。
- 成功的系統 = 好的架構 + 好的軟體工程。
- 保持簡單！
**索引**
