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

原博客地址

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

关于之前的一些疑惑

其实呢，之前自己我这块不存在特别多的直接疑惑，毕竟之前本人有过至关的项目实践经验，对有些事情仍是相对了解的。

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

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也发过调查问卷，结果是什么样的大家内心都清楚，能够上知乎看看；就算不说这个，可是全部学生内心都有一条不成文的规矩——不在有老师的群里说真心话，这个应该助教们内心也都清楚的）
• 学生，最了解一线情况，可是大部分的学生，对整个学科是没有特别完整的认知的。（因而，就会总有一部分一瓶子不满半瓶子咣当的学生，基于一线情况和本身那点正确率感人的揣测，斗天斗地斗空气，斗来斗去却毫无结果。雷打的震天响却死活见不到一滴雨，除了自嗨任何事都没见被解决。秀才造反三年不成，说的就是这类人）
• 而助教，做为过来人，具有必定的学科思惟，同时也有不少的机会了解第一线的学生状况。

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

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

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

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