之前看构建之法老段让我写的随笔

（表达能力有限……写得不好，谨代表一点想法）

    不得不承认，在校所学的软件工程和真正意义上的软件工程有很大的差距，很多时候软件工程的学生都会误以为自己所学的就是编程，其实不然，如果一个毕业以后只懂得如何编程，如何实现软件功能，那只能说他只学了这个专业的一半不到，只能算是一个底层的程序员，不是一名合格的软件设计师。
    对于大三的学生来说，要实现一个软件的功能基本都不难（要么是web程序要么是窗体程序，只要有学过基本语法）。但是要做好或者说合作快速的完成一个项目，那就比较困难了。而同时，学会如何合作完成一个完整的大型项目又是一个很核心的技能，毕竟毕业之后我们所需要面对的项目不再是几千行的代码量，而是上万上十万行甚至上百万行的代码量，一个人基本是无法按照指标完成的，必须多人合作，这就涉及到软件工程，需要按照软件工程的思路以及指导才能保证快速而又精确的完成这样的大型项目。
    而构建之法中，我认为主要提出两个重点，一个是关于合作编程，另一个是关于开发结构。合作编程主要讲述了团队编程的一些经验以及模式，而开发结构主要提出了对一些传统的开发模型的一些看法以及可变思路，以及对新颖的开发模型（敏捷开发）的一种理解。
    开发结构方面我无话可说，毕竟萌新一个，没有太多的经验。但我认为书中所说的很有启发意义，目前很多公司对软件的需求都是不停的在变化，最简单的来说像之前接过一个借贷公司的单子，对方要求修改公司网站，起初我认为很简单，毕竟这只是修改而已，有个原型还不好弄？最初的版本修改完成之后交付给公司审核，公司突然又提出一个新的要求，因为公司推出了新的业务，要求要把借贷业务和新的业务分离开，那好吧，只能在进行二次加工，由于要增加新的版面，从而又要新增一个界面控制器……反反复复处理了很久才给出终稿。的确，该公司原本的系统做的不好，但是我也做的不对，我在起初对整个项目需求分析的时候就想得太简单，天真的以为老板会在第一次商议时就把所有需求都摆出来……所以导致了瀑布模型后来的混乱。这就是目前的一个实况，很多需求方实际上都不清楚自己真实的需求，所以很多小团队都觉得“卧槽，客户要求怎么不tm一口气说清楚！”从而不停的改写，而书中的敏捷开发正好的完美解决这样的问题。
    而合作编程这一块又恰巧是校园课程中的一个短板，可以说合作编程基本都是靠学生自己摸索出来的，老师也很少提及。而事实上，合作编程看似简单，却没那么容易掌控，更何况目前除了小程序，基本都是合作编程。一个团队完成一个项目，很容易变成一个人在写，其他人打酱油这种状态，而如果认真去分工的话，又很容易在最后桥接部分发现一大团的不匹配什么的，多个人之间要存在那种默契，太难了，需要很长时间的磨合期才能做到。而现实中出现这样的队友几率太低，大学中你的队友还能跟你一起写四年的代码，工作后你的队友随时可能跳槽。所以合作编程，需要有个书面的协议或者文件，来规定相互之间的工作规范，现在常用的就是uml图以及开发手册，相对来说uml图会比较直观一些（也比较好看）。