如何成为优秀的软件开发者？

1. 人远比技术重要

你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。

2. 理解你要实现的东西

3. 谦虚是必须的品格

你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。

4. 需求就是需求

如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。

5. 需求其实很少改变，改变的是你对需求的理解

分析是一门科学，设计是一门艺术。如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。

6. 经常阅读

在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。

每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。

7. 降低软件模块间的耦合度

高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库。

耦合度低的软件可以很容易被重用、维护和扩充。

8. 提高软件的内聚性

如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

9. 考虑软件的移植性

移植是软件开发中一项具体而又实际的工作，即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。

好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性改变的时候，你的仅仅需要更新那个包就可以了。

10. 接受变化

这是一句老话了：唯一不变的只有变化。你应该将所有系统将可能发生的变化以及潜在需求记录下来，以便将来能够实现。开发出足够强壮且容易维护的软件是你最基本的目标。

11. 不要低估对软件规模的需求

Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。

在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。

12. 性能仅仅是很多设计因素之一

关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。

13. 管理接口

你应该在开发阶段的早期就定义软件模块之间的接口。一旦模块的接口确定之后，模块怎样实现就不是很重要了。从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

14. 走近路需要更长的时间

在软件开发中没有捷径可以走。缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。

你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。避免走捷径，只做一次但要做对。

15. 理解完整的过程

好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。软件开发是一个很复杂的过程，好的设计者必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。

16. 常做测试，早做测试

如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。

17. 把你的工作归档

不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定。

18. 技术会变，基本原理不会

如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。