感悟编程
编程首先要的是思想——即实现需求的架构编程其次要的是技能——即完成架构的代码
我的理解：
需求 需求分析 软件设计 项目规划 实施 测试 发布 维护 出现新需求 回到第一条
需求：可以是出现问题需要解决 也可以是创新 需求可以来自于客户 也可以来自你自己的想法 往往这两者是结合而来的 客户也希望你能给他创造需求 最关键是解决需求的办法
需求分析：出现需求 要把需求细化 从发展和应用角度 考虑整体的逻辑和细节的体现和运算形式 需求分析的基础是你对使用者的诉求有足够的了解 对应用目标相关的知识和背景有充分的掌握 对解决问题的能力有更多的方法 需求分析在应用软件领域是软件开发成败最关键的部分 一定要明确
软件设计：当需求明确后 要用软件来解决这些需求 解决的目标是解决所有需求产生的问题 让用户更舒服的使用 让项目实施和维护的成本最低。解决问题需要设计者有足够的软件知识和技能 可以想出最直接最简单的办法 设计好哪里需要灵活 哪里可以作死（没必要做灵活就作死 要不项目会变得不可控 成本翻倍的增加），如何让用户舒服需要对用户习惯有足够的了解 在软件应用设计和实施上有足够的经验，降低成本最主要的是选对开发的技术和方法 设计好整体系统的框架和数据结构 这两点是成本变化的根
项目规划：计算好实施团队规模 设计好要实施的过程 对每个节点的目标在目标和时间上进行详细的规划 团队规模主要取决于上一步的软件设计 团队的选择决定了项目实施的质量和成本 软件开发最好是多人团队来完成 多人开发有多人测试的效果 但多人开发的管理要比单人开发复杂的多 项目实施的过程设计是为以后项目管理更准确的依据
实施：实施团队可能是全职 也可能是兼职或者外包 大小公司都一样 都有擅长和不擅长之处 全职实施者要有对实施目标有足够的技术基础和经验 软件实施最耗时间的部分不是写代码 而是看文档 尤其那些学习能力不足的人 可能会在一个环节上卡死 让目标延期好几倍 或者失败。兼职和外包合作很难掌握 利益关系一般都很模糊 即使明确光靠利益关系也很难保证项目的安全完成 所以尽量寻找长期和熟悉的合作伙伴合作
。实施过程尽量不要更改需求 如果更改需求 项目管理不容易控制 很可能导致项目失控而宣告失败，在新需求产生下 管理者要果断的选择是否满足新需求、是否和何时需要推翻重做 这需要管理者对实施内容和技能有完全的了解。
测试：要尽量虚拟所有用户的环境、习惯、需求进行完整的测试 整个环节至关重要 也很容易忽视 目前软件行业发展速度飞快 产品平台竞争激烈 平台多样化、不稳定的现状 决定了软件研发者不但要对自己的产品有足够的了解 还要对所处的环境有充分的掌控 所以测试过程一定要对使用者所处的大部分应用环境进行测试 尽量增加自己的覆盖面 毕竟平台的竞争激烈 今天平台的覆盖面可能会在短短几个月就被颠覆 在此平台基础上的应用也自然也受到牵连。用户习惯测试 主要测试使用是否流畅 软件应用 以人为本 如果使用者使用起来不方便 你这个软件自然留不下口碑。软件开发结果最主要的是完成需求分析的结果 所以要在开发过程中和完成之后 都要建立可逆的测试方法。软件测试技术和工具日益丰富 早已成为独立的职业 但是人才难觅 难以定量 相关产业少 大多时候是短期应用 所以这部分工作开展起来比较有难度 很多时候需要开发人员本身来完成。
发布：在完成可以让用户使用的第一个版本前 要充分考虑用户获知和学习的过程 要把软件的形象、安装程序、相关说明书准备好 对于中大型项目 这一步都是可以单独立项的 软件开发者和管理者主要关注使用文档 这部分工作从独立的角度来说 工作量比较大 文档要以使用者的角度来审视文档的表达方式 要对软件细节有足够的阐述 以防出现意外时使用者可以寻找到解决方法。大部分文档都是由需求分析和软件设计时产生的文档衍生的 这样更直接 更准确 也更简单。要注意 安装程序环节工作内容很多 在某些情况下 你不但要对自己的系统进行打包 还要对你所处平台和相关补丁进行打包 此外还要考虑如何减少以后版本变更再次打包的重复劳动 这个工作量往往很大 也可能经过很长的时间
维护：需求分析再具体 软件设计再灵活 项目管理再严格 测试过程再准确 也无法保证软件发布后没有问题 人非神 何况在使用过程中会衍生大量的新需求，维护要尽量保证是原开发团队的人参与 效率和质量都会很高 而无法保证持续团队的情况（大多数无法保证） 就要在之前的每个过程中 有充分的记录 也写好每个部分的文档 以便新来人员可以快速掌握和实施维护。产品一旦发布出去 每次更新都不可能及时完整的覆盖每个用户 一旦出现问题用户需要在最短的时间解决复杂的问题 但很多时候这些问题都是突发的、偶然的 所以软件要对错误的反馈尽量全面、管理者要保证维护人员及时的到位、书写和保管好所有过程的文档
出现新需求：当使用者需求大量激增或者出现质的改变时 当自身想增加新科技新方法时 原来的软件结构可能会因为这些而被推翻 那么就重新回到从这个流程的起点。但是为了减少重复劳动 尽量保证原有团队的介入 毕竟文档很难保证写的很好 新人也很难可以短时间内掌握其中的思路，此外 软件积累的价值巨大 毕竟软件属于一次生产 无限复制的产品 如果所处平台没有太大发展的情况下 用老模块能更好的保证质量和减少成本
