程序设计时代：这个阶段生产方式是个体劳动，使用的生产工具是机器语言，汇编语言。
程序系统时代：这个阶段生产方式是小集团合作生产，使用的生产工具是高级语言，开发方法仍依靠个人技巧，但开始提出结构化方法。
软件工程时代：这个阶段生产方式是工程化的生产，使用数据库﹑开发工具﹑开发环境﹑网络﹑分布式﹑面向对象技术来开发软件。
软件开发技术的进步未能满足发展的要求。在软件开发中遇到的问题找不到解决的办法，问题积累起来，形态尖锐的矛盾，导致了软件危机。
表现方面：
(1) 用户对开发出的软件很难满意。
(2) 软件产品的质量往往靠不住。
(3) 一般软件很难维护。
(4) 软件生产效率很低。
(5) 软件开发成本越来越大。
(6) 软件成本与开发进度难以估计。
(7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。
说说代码风格，一个良好的代码风格规范是一个软件开发人员最起码的要求，即使程序写得是多么地出色，具有广阔的市场应用前景，但是如果背后是混乱不堪 的代码，那么就会对这个软件日后产生不少的负面的影响，特别是在后期的维护以及版本的迭代上，不规范的代码对于日后的维护人员来说，简直就是噩梦，以至于 最后实在是没办法了，只好是全部推倒重写，当然这个最坏的打算了，所以好的代码规范是多么地重要，特别是在日后开发具有商业价值的项目时，或者是在一个软件项目的团队里工作，代码规范相当重要。
结对编程，对我来说这是一个很有意思的新词，尽管这个词语的出现可以追溯到上世纪，以前不管我们是自己独立地进行项目的开发还是几个人组成一个小团队进行开 发，最基础的还是需要每个人写代码（独立地），但是，在结对编程的模式下，是由开发人员肩并肩、平等地、互补地进行开发，无论是设计、分析、编码、测试。 结对编程最大的好处就是可以使得实际开发出来的代码不断地处于“复审”的过程中，可以及时发现问题，可以及时解决问题，可以极大地避免将问题带到最后的测 试或者是发布阶段。
敏捷（Agile）开发，也是一个很早就提出来的技术解决方案，敏捷是一系列的价值观和方法论的集合，前人通过 不断地实践，总结出来的开发方法及开发过程，对我们现在的开发有很强的指导意义，敏捷开发的原则很多，其中印象最深的就是“经常发布可用的软件，发布间隔 可以从几周到几个月，能短则短”，以及“可用的软件是衡量项目进展的主要指标”，我的理解是敏捷开发强调的是“小而美”，定期地完成一个小版本的软件项 目，比只是最终发布产品要好的多，这样也有利于产品的迭代，敏捷中的Scrum方法论，看起来简直就是无与伦比：要做什么->当前要解决什么 ->冲刺->得到一个增量版本。分阶段地不断递进地解决问题，但是敏捷也有很多的弊端，敏捷宣言不是圣旨，不必完全尊从，就像是Scrum， 实际执行的时候也不是看上去那么美好，在一个复杂的项目中，往往不能带给团队更多的惊喜，所以，敏捷慎用。
具体到软件的设计与实现，从软件工程的角度来看，并不是一上来就是进行实际的编码，而是进行诸如需求分析、写设计文档等相关的编码前的相关准备工作，第一
步就是写设计文档（Design
Document），然后针对这个设计文档进行团队内部的复审，然后再进行开发，如果在编码的过程中还会遇到一些意想不到的问题的时候,和PM进行交流，
写完代码后，按照原先的设计文档和代码指南进行自我复审，重构代码；接下来写单元测试，如果可以，那么可以发布一个简单的小程序，在少数用户的范围内使
用，方便及时地发现问题。好像到了这里，如果没有什么大的架构或者程序上的问题的话，那么一个相对比较完整的软件版本就已经实现了，但是在软件工程中还有
一个问题往往会被忽略，那就是“用户体验”，我们都知道一个界面美观的设计有的时候也会给一个软件增色不少，使得用户的第一个直观的感受就是这个界面首先
是吸引人的，做好一个用户体验，首先需要明确这个软件的受众或者说面向的是什么样的群体对象，根据具体的群体是喜好进行针对性的设计，才能更好地满足用
户。
