ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 讀解軟件工程的25條建議

讀解軟件工程的25條建議

原创 Linux操作系统 作者:Flourish2004 时间:2009-04-01 16:30:17 0 删除 编辑

1. 人遠比技術重要; 多花點時間到軟件需求和設計一個使用戶能很容易理解的界面上.

2. 理解你要實現的東西; 好的軟件設計人員把大多數時間花費在建立系統模型上.

3. 謙虛是必須的品格; 從同事,客戶口中獲取足夠多的新東西.

4. 需求就是需求; 成功的軟件取決于時間,預算和是否滿足用戶的需求.

5. 需求其實很少改變, 改變的是您對需求的理解.

6. 經常閱讀;  在這個每日都會發生變化的產業中, 您不可能在已取得的成就上陶醉太久.

7. 降低軟件模塊間的耦合度. 解釋耦合度 : 模块间的耦合度是指模块之间的依赖关系,包括控制关系、调用关系、数据传递关系。模块 间联系越多,其耦合性越强,同时表明其独立性越差。降低模块间的耦合度能减少模块间的影响,防止对某一模块修改所引起的 “牵一发动全身”的水波效应,保证系统设计顺利进行。 
    高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

    你可以通过以下方法降低程序的耦合度:隐藏实现细节,强制构件接口定义,不使用公用数据结构,不让应用程序直接操作数据库(我的经验法则是:当应用程序员在写SQL代码的时候,你的程序的耦合度就已经很高了)。    耦合度低的软件可以很容易被重用、维护和扩充

8. 提高軟件的內聚性
   如果一个软件的模块只实现一个功能,那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

    判断一个模块是否有高的内聚性,看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词,则说明你需要将该模块细化。    只有高内聚性的模块才可能被重用。

9. 考慮 軟件的移植性; 好的軟件設計者把那些特有的實現細節打包隱藏起來, 那些特性改變時,更新包即可.

10. 接受變化; 應該當將所有系統將可能發生的變化以及潛在需求記錄下來, 以便將來能夠實現.     通過在建模期間的考慮這些假設的情況, 您 就可能開發出足夠強壯且容易維護的軟件.

11. 不要低估對軟件規模的需求;  internet 給我們最大的教訓是您 必須在軟件開發的最初階段就考慮軟件規模的可擴充性.

12. 性能僅僅是很多設計的因素之一. 性能不是優先級最高的因素, 必須具有可靠性,可用性, 便攜性和可擴展性.

13. 管理接口;  應在開發階段早期就定義好軟件模塊之間的接口;

14. 走近路需要更長的時間, 在軟件開發中沒有捷徑可走. 縮短你的需求分析時間, 軟件建模節省一周, 節省一天的測試時間    缩短你的在需求分析上花的时间,结果只能是开发出来的软件不能满足用户的需求,必须被重写。   

在软件建模上每节省一周,在将来的编码阶段可能会多花几周时间,因为你在全面思考之前就动手写程序。

    你为了节省一天的测试时间而漏掉了一个bug,在将来的维护阶段,可能需要花几周甚至几个月的时间去修复。与其如此,还不如重

新安排一下项目计划。
    避免走捷徑, 只做一次但要做對 (do it once by do it right )

15. 別信賴任何人; 包括產品供應商,顧問和承包商, 商業味太重; 而程序員自認為比其它人更優秀.

16. 證明您的設計是在實踐中可行,

17. 應用已知的模式;

18. 研究每個模型的長處和弱處;

19. 在現有任務中應用多個模型;

20. 教育您的聽眾; 要保證團隊有一個通用的設計語言,才能真正合作, 需求建模, 用例和用戶界面模型;

21. 帶工具的傻瓜還是傻瓜; 并不是有了優秀的工具就代表你很優秀;

22. 理解完整的過程, 好的設計者需要考慮全局,從長遠考慮如何使軟件滿足用戶需要, 如何提供維護和技術支持.

23. 常做測試, 早做測試;

24. 把您的工作歸檔;

25. 技術會變, 基本原理不變;

 

 

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/183242/viewspace-582745/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 好玩的東西
请登录后发表评论 登录
全部评论

注册时间:2009-01-06

  • 博文量
    149
  • 访问量
    170138