系统分析设计--结题篇

这个作业属于哪个课程	课程的链接
这个作业要求在哪里	作业要求的链接
团队名称	卓越code
这个作业的目标	回顾作业，展望未来
GitHub地址	Vchopin

问题解答以及新产生的问题

  第一次博客中提到很多问题（“构建之法”--第一次作业-阅读与准备工作）,课程结束也该有个了断了。也许现在的认知还是不能够很全面的回答问题，但是一学期新的磨炼，让我对这些问题有了能够回答的权利。

问题一 “深度优先”还是“广度优先”？

  其实，这个问题对于不同的人会有不同的答案。没有最好的，只有最适合的。从这门课程的意义来说，有的人精于管理，而有的人更喜欢技术。那么对于拥有一身管理的人来说，就是能够尽可能多的熟悉技术，并粗略了解其实现的难易程度，也就是虽然我不会做，但我能够找别人来做。而对于喜欢钻研的人来讲，他就更喜欢一条道走到黑。我喜欢Java，那么我不仅要用Java做项目看，我以后还要靠Java养活自己。这种人如果不钻研透彻一门技术，他自己也会觉得心里不舒服。也就是我一定要自己做出来。这个问题在我们团队实践过程中也体现的淋漓尽致。所以，川哥，好好考虑自己要走哪个方向吧！

问题二 团队模式的选择

  首先上一个概要表格吧

团队模式	解释	优点	缺点
窝蜂模式	像小朋友踢球一样，球在哪里，人就一窝蜂跟在哪里	欢乐而随意	这种团队模式很难存活，并不是一种好的团队模式
主治医师模式	像在手术台一样，有一个主刀医师，其他人负责协助主刀医师	一个软件团队中，有首席程序员，负责主要模块的设计和编码，其他人尽可能从各个方面支持他的工作	这种模式可能逐渐退化成“一个学生干活，其他学生打酱油”
明星模式	主治医师模式运用到极点	对“明星”个人的成长进步可能会有所帮助	团队模式强调的是团队的作用，而不是个人的独角戏，这种模式显然违背了团队模式的初衷，效率也很低
社区模式	由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量，大部分人不拿报酬	“众人拾柴火焰高”，成功案例：开发和维护Linux操作系统的社区，成功案例往往需要严格的代码复审和签入的质量控制	“只烤火，不拾柴”，“拾到的柴火质量太差”
业余剧团模式	团队中各人扮演各人的角色	在业余玩票、培训的环境中，每个人都可以尝试不同角色，大家可以比较平等地讨论	在竞争性强烈、创造性要求高的团队，不会存在完美主义的民主气氛。
秘密团队	有一些软件项目在秘密状态下进行，别人不知道他们具体在做什么	团队内部有极大的自由，较高的热情，没有外界的干扰。	不可能成为普遍模式，只会针对个别项目。
特工团队	软件团队由一些有特殊技能的专业人士组成，负责解决一些棘手而有紧迫性的问题	效率高	对成员的知识面要求十分广，较为针对技术人员，不可能成为普遍模式
交响乐团模式	各司其职，想交响乐队一样	各司其职，重在执行	呆板
爵士乐模式	与交响乐模式存在相当多的对立	领导给出一个主题，然后成员们百花齐放，各显本领，快收尾时再总结	人员不能太多
功能团队模式	具备不同能力的同事们平等协作公共完成一个功能	效率高	每个小组必须与其他小组就编程规范达成一致
以上表格很明显的区分了各个团队模式应该怎么做，应该做什么。优缺点我也基本罗列出来了。很显然，还是那句话，每个团队模式对应在不同的场景下面，但是很多团队模式也有非常明显的问题，直接限制了大型项目开发和团队管理。如果选用了不合适的团队模式，可能会产生负效率。

问题三 "测试危机"

  通俗的来说，软件测试是不可能引起危机的，至少这个危机不可能是我这种凡人应该考虑的问题。通过这门课程，我也基本理解了软件测试的范围和原理。测试，就是要把软件全部地方，不管大大小小，看得到的，看不到的，都要进行测试，不管你是两个数相加的这种简单的功能还是机器学习智能算法，都得进行测试，相当于“王子庶民同罪”。软件开发人员就应该和测试人员不是同一个人，这样才能更好的完成对软件的测试，不然可能会自带无数隐形bug。

问题四 软件工程的创新

  软件工程本就是不断发展着的，就在我敲下这篇博客的时候，软件工程又在他的世界前进了好几年。人类社会对于如何评判一个事务的创新不是看的它的外观（它也确实没有外观），而是它是否符合人类的价值取向。说到底，软件工程就是一种思想，就像马克思主义一样。它依赖于人类的思想而拥有他自己的形态。我认为它已经创新了，对于上世纪的函数式和面向过程编程来说，现代软件工程已经是很先进的思想了，任何事物都是一直处于发展中的。能够降低人们做软件项目的效率就是它进步了，对人类有帮助的就是创新了，这就要看人类对它本身的看法和理解了。但是我认为它创新了，于是它就创新了。

问题五 系统重构的“修昔底德”

  在国际政治上面，修昔底德陷阱指一个新崛起的大国必然要挑战现存大国，而现存大国也必然会回应这种威胁，这样战争变得不可避免。对于软件结构也是这样，如果新的软件工程思想出现，那么根据原有老的思想建立的工程项目就必然有一天会被进行重新建立。这个时候，重构就成了必然。要做好重构，那就必须拥有一套原有系统。所以原有系统存在的意义就是对重构打下基础，作为重构的目标以及重构后需要实现的最低需要。通过这学期的学习，我也同意作者的说法，重构是减少代码冗余量的最好办法！此时的重构，不仅属于原来项目的维护阶段，也属于新项目的开发阶段。

新学习的技能

  学啥啥不行，吃饭第一名。通过这次小组合作开发项目，感觉只是学会了破解PHPStorm。但是仔细想来，这次项目总共用到的技术有ThinkPHP，Ajax，Bui，Bootstrap,Mysql,Apache,Windows Server,微信开发者工具，Json，GitHub...等等，仔细想想确实没有多少新鲜的。但是在完成个人博客作业的时候，学会了VS中的对C#进行单元测试。最最重要的是，VSCode成为我停留最久的开发器了。但是发现MarkDown还是挺好用的。这应该是这门课学到的最大技能。
  此外，在个人能力方面，也基本了解了结对编程，并在开发项目的时候广泛使用这种方式。团队协作能力得到进一步提示，如何管理好一个团队也渐渐在我的头脑中有一点点的想法了。这应该算整门课程最有意义的地方了。

体会总结

  这门课持续得是真的久，我感觉要是全部课程都采用这种模式，学生不还得累死。这种模式的初心我觉得是很好的，不仅能够锻炼自己的编程能力，更重要得是从管理上面学习到一些技能，不说完全掌握，应该能够萌发一下软件管理和团队管理的意识和基本操作了。根据我的观察，其实结对编程很多同学根本没有结对，都是自己编，编完叫队友过来摆拍，但是其实这也是“周瑜打黄盖，一个愿打一个愿挨”，也没有什么好说的。只是想证明，有些时候，这门课程可能太过注重于对博客内容的审核，而没有真正检查到过程。而要检查到过程，本身也是一件非常困难的事情。一边授课，一边写博客，这种形式我可能是还没有适应，给我的感觉就是条条框框很多。能不能达到老师和助教们心中的那种效果，我想，时间已经给出了答案。最后，感谢陈老师的细心指导和助教们的辛苦评审，以及一些看不见真身的幕后工作者。

放松下吧