软件开发高手的一些经验之谈"
用户也是人。我们的产品和我们的失败都可能直接影响他们的生活，对你行为的后果要三思。人与人并不相同，人们的思维方式也不同：有时候我们认为困难的东西从商业人士角度看来可能很容易。这是我们必须解决而不是逃避的矛盾。勇于改变需要改变的，接受那些无法改变的，用智慧来分辨其中差异。
软件开发者不“只是写代码”，而是参与开发过程。所以如果公司在使
应用软件开发
软件开发高手的一些经验之谈"
用户也是人。我们的产品和我们的失败都可能直接影响他们的生活，对你行为的后果要三思。人与人并不相同，人们的思维方式也不同：有时候我们认为困难的东西从商业人士角度看来可能很容易。这是我们必须解决而不是逃避的矛盾。勇于改变需要改变的，接受那些无法改变的，用智慧来分辨其中差异。
软件开发者不“只是写代码”，而是参与开发过程。所以如果公司在使用敏捷(Agile)，你必须对其认真对待，起码也要对其保有尊重。代码评审(Code review)是软件开发过程的重要组成部分。对代码评审有所疏忽就不能成为好的软件开发人员。
作为软件开发者，我们对自己部署的代码要负责。我们也负有道德上的责任，不要做不道德的事。有时候对开发人员来说不重要的事情却有极高的商业价值。商业是一个好的角度，不要逃避它。很少有公司关心你的个人成长。如果公司对你目前的水平不满意，他们一开始就不会聘用你。
对截止时间(deadline)负责。如果在截止时间前完成不了，你必须重新沟通新的截止时间。任务有两种复杂性：内部和外部复杂性。内部复杂性不可避免，因为这是任务本身;外部复杂性来自重新架构系统过程中异常决定的后果。要格外注意外部复杂性超过内部复杂性的情况。如果开发者在写代码或架构系统时选择容易而不是好的解决办法，他欠下的技术债迟早有是要还的。
早的软件开发方法是由D．Parnas在1972年提出的。由于当时软件在可维护性和可靠性方面存在着严重问题，因此Parnas提出的方法是针对这两个问题的。首先，Parnas提出了信息隐蔽原则：在概要设计时列出将来可能发生变化的因素，并在模块划分时将这些因素放到个别模块的内部。这样，在将来由于这些因素变化而需修改软件时，只需修改这些个别的模块，其它模块不受影响。信息隐蔽技术不仅提高了软件的可维护性，而且也避免了错误的蔓延，改善了软件的可靠性。现在信息隐蔽原则已成为软件工程学中的一条重要原则。
Parnas提出的第二条原则是在软件设计时应对可能发生的种种意外故障采取措施。软件是很脆弱的，很可能因为一个微小的错误而引发严重的事故，所以必须加强防范。如在分配使用设备前，应该取设备状态字，检查设备是否正常。此外，模块之间也要加强检查，防止错误蔓延。Parnas对软件开发提出了深刻的见解。遗憾的是，他没有给出明确的工作流程。所以这一方法不能独立使用，只能作为其它方法的补充。SASD方法，1978年，E．Yourdon和L．L．Constantine提出了结构化方法，即SASD方法，也可称为面向功能的软件开发方法或面向数据流的软件开发方法。1979年TomDeMarco对此方法作了进一步的完善。Yourdon方法是80年代使用广泛的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，是结构化编程（SP）。这一方法不仅开发步骤明确，SA、SD、SP相辅相成，一气呵成，而且给出了两类典型的软件结构（变换型和事务型），便于参照，使软件开发的成功率大大提高，从而深受软件开发人员的青睐。
软件开发涉及的流程是：需求 、 开发 、 测试 、 发布上线。作图本身是个设计的工作，是个前期工作。那么从软件开发的整个生命周期来说，用到的图的地方是在前期的需求、开发阶段较多。在软件开发这个非常抽象的领域，只要涉及到多人协作，那么通过文字来进行交流叙述是非常晦涩难懂的，需要沟通好几遍才能理解达成一致也是比较常见的情况。那么我们画图，就是为了把不适合用言语表述的内容通过作图的方式呈现出来，让相关协作者有一个共同的具象的参照物。这个参照物可以有它的额外价值，是对软件长期价值的延伸，一份一致、清晰的设计图，可以给后续的软件迭代提供非常有帮助的决策依据。当然保证设计图与系统的一致本身也是件费精力的事情。
（作者： 来源：）
