【作业】软件工程课程总结博客

原博客地址

【软工作业&思考】关于软工的一些概念性理解暨第一次阅读作业

关于以前的一些疑惑

其实呢，以前本身我这块不存在特别多的直接疑惑，毕竟以前本人有过相当的项目实践经验，对有些事情还是相对了解的。

既然如此，那在这里笔者就简单说下之前的问题在本学期中所面临的一些真实状况。

PM做开发和测试之外的所有事情

这块的话，我们团队整体做的还算可以。分工相对明确，大家都有一定的热情和积极性。并没有出现寡头垄断的情况，所以自然也不存在后续的崩盘之类的。

猪、鸡和鹦鹉的故事

这部分的话，我们团队内各自对这个项目，以及这个项目中自己的得与失，还算是基本拎得清的。总而言之整体上合作愉快。

新的问题

如何与技术段位差距较大的人相处或达成一致

笔者之前的话，其实在多个技术团队做过事情，基本上没啥问题。

但是，之前的团队不管怎么说，协作者都是有着相当完善的工作经验的。而在软工课程中所面对的这个团队确实一群完完全全的学生。于是在很多地方就存在了思想上的冲突：

• 我：
  • 这个项目应该如何计划才能做的更大，效益更好？
  • 这个地方代码应该如何维护才能未来更方便？
  • 这个地方需求如何设计才更有效益？才能用最小代价换取最大收益？才能在市场上占据一定的主动权？才能在和学校有关部门交涉的时候有足够的筹码？
  • 学期结束后，我们应该如何把这个项目进行安置，才能让其真正的稳定而不至于人去楼空人周茶凉？
• 学生：
  • 这个项目如何才能拿到更高的分数？
  • 这个地方应该怎么写才能更快地写出能跑的程序？
  • 这个地方需求如何设计听起来才最让老师信服以便给个高分？（没错，划重点：听起来）
  • 学期结束后，我们的项目应该如何处理才能让我多拿几分？

这样的矛盾其实很显然，虽然我某种意义上大概能理解为啥很多人会有这样的学生思维（实际上很早以前的我也差不多，只不过经历的比较早而已），但是很多时候为了更长远的利益，却又不能妥协。然而讲道理却又不是什么时候都能行得通的，毕竟视野深度和广度存在明显的代差。

于是在这样的情况下，如何和具有代差的人相处并做好事，就是一个亟待思考的问题了。

管理层如何让下属，甚至是高阶下属，在利益上达成共同体，是否有什么一般性的思路

正如笔者在前面的博客中所写：

世上只有利益上相互依存的关系，才可能是稳定的关系。

同时，基于上面一点的论述，不难发现技术段位差距较大的人，已经容易存在眼界和视角上的代差。那么在现实的组织架构中，一个高层管理所能看到和察觉到的问题，可就和下层的人相比起来差别大了去了。

所以，在这样情报严重不对等，甚至很多时候连深层的信赖关系都难以达成的情况下，能依赖的唯一纽带就是共同的利益关系。或者也可以说，正是因为很多的下层人员与上层所共同考虑的问题也基本只有利益（996事件中，大部分基层程序猿的发声，基本逻辑都是如此），所以利益也是最靠得住的一种纽带。

那么问题来了，在这样严重不对等且没有信赖关系的情况下，利益共同体该如何达成？是否有一些一般性的思路。

先说说个人目前的一些粗浅认识，思路有两种：

• 充分换位思考，了解对方利益诉求
  • 这是最开门见山的一种思路，也是解决问题最直接的一种手段
  • 但是这样的方法存在一些操作性上的问题
    • “子非鱼安知鱼之乐”，你再怎么去试图理解他们，但你毕竟不是他们。
    • 所以，实际上很容易发生即便换位思考，依然不得要领的情况。意识是客观存在的主观映像，所谓换位思考思考出来的，与其说是对方，倒不如说是对方+自己。
    • 而且事实证明，在这样的情况下，被换位思考的那一方还基本上不会买账。就好比，人家要一个苹果你给人家拉来一车梨。
    • 最典型的一个反面教材——世界上有一种冷，叫做你妈觉得你冷；世界上有一种食欲，叫做你妈喊你回家吃饭
• 既然没有信赖关系，那就建立信赖关系
  • 这个办法需要多一步，但是实际上如果能实现的话效果会很好
  • 实际上，很多成功的领导者，甚至政治家，所做到的事情也正是与自己目的路上核心位置的人员全都建立了信赖关系，并以此为突破口，再以利益关系作为稳定因素，加强安全性（典型例子：刘备、司马懿、希特勒等）
  • 但是这件事依然存在一些难点：
    • 对于所有的人，如果都要建立起信任关系的话，那实际上成本实在太高了（尤其对于高层领导，对下层所有的人都直接联络感情？听起来不太现实）
    • 而且实际上，很多人也并不在意这层信赖关系。最典型的就是现在常说的“社畜”，他们就是赚钱，工作时间以外的任何事别来烦我。画大饼？那是啥？你们做领导的不是最喜欢骗我们么？责任？那是啥？有钱重要么？信赖？那是啥？本大爷不对你们这群黑心坏领导宣战都是给你们脸了，还信赖，要我们同流合污？脑回路很清奇对吧？但是他们还真就是这么认为的，这种心态极其普遍。
    • 当然，能遇上好沟通善解人意的人，当然是极好的。但是很显然，现在的社稷国情下，不能把这类偶发事件当做全部，更不可能只靠这个过日子。

综上，实际上在上下级这一层的关系维系上，是存在这样一个很尴尬的僵局的。所以，这块应该还是需要一系列更成熟的思路和解决方案。还望不吝赐教。

如何和一般性的其他人或者团体达成利益共同体，是否有什么一般性的思路

同样的，实际上在合作方之间，也会存在这样的一层问题。

简单来说，人家也有人家的利益。人家不可能因为你胡吹出来的那点所谓的“情怀”、“信仰”，就来和你谈合作，因为人家也是人，也得吃饭，也和你一样没有太多的时间做无意义的事。

和上面一条基本类似，此处不再做详细描述。

做中学总结

需求

首先，需求层面，需要从两个角度来分析：

• 甲方。在很多的情况下，需求方只能说出大概的需求（比如，我想做一个场馆数据系统，我想做一个用来刷航概的app），更细的，即便问他们，他们也不知道。但是对于甲方而言，如果你把一个产品摆在他的面前，问他合适不合适，对不对，这样的问题他们是能给出明确答案的。
• 乙方。对于程序猿而言，很多时候只有知道明确的需求才能进行工作。然而如上文所言，甲方是不可能做到直接给出这样的明确需求的。于是这个时候，PM的一个重要职责就是在甲方和程序猿之间建立一个桥梁，将甲方需求转化为开发需求。同时也需要在和甲方沟通的时候，对程序猿们有充分的了解（比如大致了解哪些东西可做，哪些东西好做，哪些东西不可做）。

设计

在需求层面基本明确的情况下，那么设计也就该提上日程了。

设计也分为几个层面：

• 产品设计。产品设计主要是将需求进行一个整合，和上问的需求分析转化基本类似。
• 架构设计。架构设计则是在已知的详细需求下，思考如何构建一整套的代码，以及软硬件资源配置。同时，需要从架构层面来考虑后续的可维护性。

实现

实现这块，则需要在整体架构设计相对明确的情况下进行。

此外，在实现的过程中，最好伴随着主干功能的实现，一并将单元测试也进行实现。

除此之外，还需要在开发实现的过程中，注意后续的可维护性（实际上个人感觉开发与维护这块本身就是一体的）。

课程心得

本学期对我而言，实际上只相当于把以前做过得事情再次弄了一遍。唯一一点比较重要的差异，在于这次的团队配置和以前大不一样（前文有说到）。所以能总结的内容其实很有限。

不过实际上，笔者也在思考这个课程的一些得与失。同时，笔者也在这个学期当OO的助教，对有些问题也算是有那么一些略微的认识，在这个部分我就着重说下这方面的问题吧。

思考与建议

课程周期短，相关内容体现不足

首先，这个课程是一个只有一学期的课程。而且一学期时间，涵盖了三个阶段，包含了那么多个环节。

老实说，以我之前做创业项目的实际体验来看，除特殊情况外，一般不会有周期如此之短的事情。

而且这样的短周期还会带来另一个问题，那就是很多要素的重要性的体验严重不足。例如：

• 维护前后期的重要性。如此短的一个项目，即便一路无脑硬冲，也基本上不会出啥问题。而且实际上在一学期内，根本也不太会遇到真正的大范围业务需求变更这样伤筋动骨的操作（正常的PM应该都会去极力避免）。所以实际上这一块与现实存在一定程度的脱节
• 与用户的深入互动。同样，这个课程项目，作为一个“课程”项目，在很多组的眼里，还完完全全是个摇分树而已。即便要求了用户指标，他们所做的事情也大都不过只是所有人朋友圈转一转，各个大群发一发而已。而用户用来到底真实感受是怎样的？没有有问题？严重问题还是只是体验问题？问题出在哪里？怕是很多组根本就没有做过详细的调研。对于继承项目，尤其有这样的问题。笔者所在的组还好，最起码很明确用户群体，也有过与相关组织进行直接沟通。但是其他一些组，可就难说了，据我所知，拿来代码 --> 编写代码 --> 群里转转 --> 截个图 --> 交作业这样流程的怕是不在少数。而这么一个循环弄下来，他们真的能有多了解用户呢？知己知彼百战不殆，大环境都摸不清楚的团队，除了能在学校赚点分之外，出了学校是做不成什么事情的。

实际上，在OO课程哪边，也一样存在类似的问题。OO和软工的一个共同特点，那就是有些内容是很概念化抽象化的，与其说是技术技能倒不如说更像是概念机能。在短周期内想做到这件事，并不容易，甚至一定程度上，软工比OO面临的形势只会更加严峻。

在这样的环境下，如何把握好整个周期，如何把有些该体现的内容充分体现出来，让学生在学习过程中把这些内容落到实处而不是流于形式，则是需要课程组好好考虑的问题。

相关指导偏向于抽象

如题，很多的指导还是偏向了理论，和实际操作的结合有一定的错位。这就导致一些组或者个人，到了一定阶段会开始陷入很大的迷茫，而且还没有办法通过理论课的讲解来进行补足。

其实，这件事说来并不能全怪这门课程。学生在学习这门课程之前，实际上一些前置知识还是比较匮乏的。比如一些考虑问题的基本方式，以及一些架构布置方面的基本功（这块2016级及以上会表现的比较明显，因为OO这块的整体学习质量不够好；相比之下2017级，也就是明年开始，因为今年OO大规模课改，同学们的这块能力会有明显的好转）。于是实际上，我们的指导需要分为几个阶段：

• 起步阶段
  • from personal development to team-working
  • from programming to coding, and then to developing and producting
  • from doing homework to exploring and creating
• 步入正轨
  • 引导学生们真正开始思考有些问题，而且一定需要他们去进行实打实的操作，而不是博客写几个字重复几句套话就了事。

其实OO也有类似的一些过程：

• 起步阶段
  • 教会大家Java基本语法
  • 教会大家多线程基本知识
  • 教会大家基本的调试与测试技能
• 步入正轨
  • 面向对象
  • 设计模式应用
  • 契约式设计，Java modeling language
  • 深层次设计工具，UML绘图

今年所采用的模式，是两部分交织着进行。在第二单元多线程结束后基本完成起步阶段的教学，但是正轨部分实际上第一单元就开始了。保证学生做到不至于营养不良，也不至于营养过剩，饭一口一口吃，事情一点一点做。到了起步阶段完全结束的时候，一多半的同学已经具备了完整的架构思维，剩下的就是不断优化追求卓越了。

所以建议课程组也在这个问题上多下一些功夫，要切实了解起来学生的真实情况。

助教与学生之间直接互动偏少

如题，实际上助教在同学这边的存在感实在是很低（相比于机组和OO课程而言），一整个学期除了通知消息之外基本见不到助教出没，甚至通知消息也都是高阶助教一个人在不断的通知。

助教，其实是个很微妙的职业。说微妙，其实原因如下：

• 老师，了解整个学科，但是不容易了解学生的一线状况（不要说老师没去了解，之前OO也发过调查问卷，结果是什么样的你们心里都清楚，可以上知乎看看；就算不说这个，但是所有学生心里都有一条不成文的规矩——不在有老师的群里说真心话，这个应该助教们心里也都清楚的）
• 学生，最了解一线状况，但是大部分的学生，对整个学科是没有特别完整的认知的。（于是，就会总有一部分一瓶子不满半瓶子咣当的学生，基于一线状况和自己那点正确率感人的揣测，斗天斗地斗空气，斗来斗去却毫无结果。雷打的震天响却死活见不到一滴雨，除了自嗨任何事都没见被解决。秀才造反三年不成，说的就是这类人）
• 而助教，作为过来人，具备一定的学科思维，同时也有很多的机会了解第一线的学生情况。

助教的这一特点其实很微妙，老师、学生，都整体上缺乏某一方的资源，而助教却完全有这种可能打破资源时空分布不均的困局（甚至部分比较厉害的助教自己一个人就能完整的掌握两头的情报）。

于是，个人认为，助教的一个职责就是——充当起师生情报传递的桥梁。

如果追求更深层次的话，那就是——基于双边的情报，优化双边资源配置，一达到一个全局更优的解。

所以，其实建议助教们看到这句话也能好好思考一下。我相信助教们也都应该是有志于改进整个课程的人，那就好好思考思考我说的这些，想想看自己到底该做点什么，而不是只是一味充当苦力，或者干脆只是一个传话筒子（而且搞不好还是单向的）。