软工团队 - 预则立&&他山之石

团队任务计划

细化后的issue：https://github.com/StardustProject/Stardust/issues

他山之石采访记录

采访是的“一不小心就火了”队，队长逸超学长和我们团队的个别成员认识，交流起来也相当的轻松愉快~

项目开发经验

• Q： 我们有看到其他学长写到，项目的开启可以由一个比较有经验的人把项目的架构写好，然后再由其他人进行填充，但是负责安卓端的开发人员都没有项目经验，如何开启一个项目？
  A：我们当时是写着写着就写起来了，就我自己来说，安卓的话，到目前为止，整个项目的结构大概就是activity，adapter，请求代码工具包之类的。具体的话，可以学一下MVP模式，尝试一下。用这种方式的话，整个工程结构、层次肯定比较清晰，但是初期可能会碰壁，遇到很多坑。或者说你们也可以用自己的一套规定。​

• Q： 关于接口方面，有什么建议，需要团队一起制定吗？
  A：接口的话，至于是不是一起定义，如果其他人都不熟悉的话，由熟悉的人一个人来定义也是可以的。另外，接口文档要写好，记录工具的话就不要再用word了，我们自己的经验就是后期文档太乱，多使用协同工具，apizza可以尝试使用一下。

• Q： Android客户端和后台PHP端有使用什么框架吗？
  A： Android端的话好像没有。但是你们Android不是要做图片，一般不自己写，可以用glide，网络请求库的话，现在比较流行的是Retrofit+RxJava。PHP端我们当时用的是ThinkPHP的框架，当然做接口开发的话，也有很多轻量级框架可以用：Lumen、Slim。你们已经搭好的Laravel，比较倾向于全栈方向，属于比较集成的，当然这些框架的选择，只要你们觉得OK，都可以。

• Q： 我们对项目测试还没有一个清晰的概念，学长能说说要如何测试及制定测试计划吗？其中要注意一些什么吗？测试是手动测试还是自动测试，如果是自动测试用的什么工具？
  A：当时的软工项目上，我们没有主要的项目测试人员，项目基本上没有什么测试，写过一个自动化测试测试过登录界面，主要是对接口进行一些测试。你们要做的话，可以写一些单元测试、自动化测试，对每一个功能函数进行测试。对于服务端接口的测试，通过堆栈发起请求去请求接口，进行压力测试。目前暂时可以不考虑高并发问题，项目后期，对于这个问题，可以考虑限制流量方式来解决。

• Q: 看《构建之法》里面说到测试驱动功能，我在结对作业中使用的是测试先行的方式，结果编码量和编码时间都指数爆炸。学长是倾向于测试驱动功能呢还是先写功能再测试？
  A: 一般我写是先写完再测试，好像不管是公司里面还是其他团队都是这个样子。

• Q: 整个Alpha阶段只有10天，编码时间相对紧。在这么短的时间内发布一个release版本，是一个什么概念？
  A: 建议的话就是，你们在做之前要把各自的工作给做好，分工要明确。因为我们之前做的话，最开始分工不明确，而且当时相比我们上一届，4个人，他们人数更少。这种编码的工作不是人越多写得越快，因为你们还要解决各种冲突，包括代码的冲突，还有队员交流这些。所以这个就需要组长好好协调。

• Q: 团队成员基本没有项目经验，学长有没有什么建议？
  A: 这才是锻炼啊！Android端，我的建议就是，learning by doing，就是你要这个功能，就去找，之后想深入了解的话，再去扩展。你们现在做的东西都是会去用而已，比如你们要去实现什么功能，就去把这个控件学一下怎么用，而后面如果要深挖的话，就不是只是会用的程度了，要去了解底层是怎么实现的。所以你们这个阶段没做过什么是没关系的，就是基本上要去学会怎么用，如果有兴趣的话再去深挖。你要写这个东西的话，最要看的就是，他整个逻辑是怎么传递的，如果你搞清楚了的话，顺着那条路慢慢写，最后肯定写的出来。

团队成员协作

• Q： 有出现团队里某个队友进度落后全团队都在等的情况吗？这时候怎么办？
  A： 我们当时的服务端的接口都已经完成了，但是其实我们是在Alpha阶段最后一天才开始对接口的。导致这个的原因主要也是分工不明确。分工模糊，我们那时候项目有四个端，很多东西是重复，比如查看结果是一样的，后面对于重复的界面要用谁的，就炸了，谁也不服谁。

• Q： 学长们都说好基友千万不要在一个团队是为什么？是后期冲刺经常闹矛盾吗（个人能力导致代码无法交付亦或是因为觉得他人写的代码“过丑”）？团队情绪如何把控？
  A： 写代码就会有冲突嘛，主要大家要相互理解。我们当时Alpha阶段，安卓端的开发人员就有三人发生冲突。每个人能力不一样，掌握的技能也不一样，走在前面的人可能需要等待刚开始起步的同伴，这时候就要耐心一点，当然，每个人手头上有可能各种事情，在这种时候要表现出足够的耐心也是比较难的。另外，各种规范要制定清楚，也能减少一些冲突的发生。对于团队成员中代码不优雅的情况（比如四个for），现阶段对于你们团队的情况可能比较次要，先把要做的功能做出来，保证功能能正常使用，标记tag，后期来进行产品的优化，因为你们团队现阶段最首要的任务就是如何在这么短的时间把你们的产品比较完整的做出来。

时间周期安排

• Q： 离第一次的Alpha版本发布只有一个月左右，学长们是怎么解决在这么紧的时间完成大部分的功能的？
  A： 其实你们不要太过紧张，完备规范，明确分工，注释清晰（注释一定要写清楚！！），这样就可以了。

• Q： 是否有发生在某一环项目的实际进度赶不上计划的情况，应该如何调整？
  A： 熬夜啊。
  Q：？？？

其他

• Q: 学长的项目分工的时候，为什么没有一个负责测试的同学呢？
  A: 因为我们那个选导系统功能复杂项目太大，任务做不完，后面测试都比较水。接口是有测的，Android端这边虽然测也是有测，但是单元测试做的就比较少，做了一个登陆界面的单元测试、自动化测试。测试这一块，后面整合系统的时候也没有怎么测。而且中间有个队友去比赛了种种原因，后面分工要磨合很困难。而且有些人不熟，人手也不足，所以就没有做很系统的测试。

• Q: 逸超学长是团队的PM，但是在Alpha阶段也参与了很多编码工作，为什么？
  A: 其实贯穿整个过程，我的编码工作还是挺多的。也是因为这个，导致后面整个组的分工也比较不明确。而且Alpha阶段和Beta阶段是不同人在管，后面磨合也出现一点问题。所以我给你们的建议就是，组长就不要参与编码，专门管控整个项目就好了。你要的是别人完成得怎么样，而不是你也直接参与。

• Q: 那所说的分工不明确是什么样，比如说只分了谁去写服务端，谁去写客户端，而没有分具体谁到某一个模块这种程度？
  A: 对。因为两个人做不同模块，后面协调起来，冲突会比较少一点。如果两个人做同一个模块，一来代码会冲突，二来两个人之间也要互相询问对方的代码。

• Q: 我看到有个学长的博客说到AS的git功能很好用，但后面他又说图形化的界面虽然能提高效率，但根本的还是命令行，觉得命令行更好。git只是一个工具，如果用图形界面开发效率更高的话，为什么要执着于命令行？
  A: 那些图形界面，本质的话用到的还是命令行。但对于你们现阶段的话，为了追求效率，为了完成作业，还是推荐使用图形界面，就是AS自带的git功能。但是你们学到后面的话，其实还是命令行比较好用。因为你选择命令行的形式的话，你肯定对git了解更多更深，对于回退、合并、切换分支，你能知道他们具体的命令是什么样子的。然后图形界面的话，有个优点的话就是，你可以看到那条分支线，合并操作的话也很简单。所以两者各有优点，如果你会用命令行的话，你用图形界面也肯定很好上手。最根本的还是命令行。

• Q: 我看到当时学长们软工的commit注释有类似“整合上届代码，气煞我也，在里面发现了错误”、“队友需要，改了返回数据格式”、“写的快奔溃了，感谢产品不杀之恩Orz”，为什么长这样的pull request也让过了呢？学长们现在在公司做项目是否有一套固定的git规范？对于commit的注释需要甚至详细到操作了哪个类的什么函数吗？
  A: 学长A：你回答，学长B：你是PM你回答，学长A：当时我们对于git基本没有制定一定的规范，所以才导致了这个问题。对于git，可以给你们说说我最近的使用经历。最开始肯定是提交一个最初的master， 然后从master拉出一个dev的分支，按照dev分支这条线，开发人员根据实际拉出一条feature分支，对于feature的命名规范 “版本_开发人员名字_功能描述”，测试好了，再merge到dev分支。

任务分配比例

反思&总结

在采访学长之前，把他们队伍的博客从第一篇起一直看到了最后一篇。看到每日站立式会议照片里的学长们从薄薄的短袖T恤一直到后来厚厚的羽绒服（其中一个学长正搓着手取暖），突然间即使还没开始这段旅程就已经感慨万分。当然，其中也看到了学长们博客中体现出来的一些问题，都带有疑虑的在采访中问了这些不算太正儿八经的不解之处。比如为什么任务分配中没有测试人员、为什么commit注释千奇百怪、为什么Alpha阶段结束后54张issue卡片还剩下多达12张...虽然问题本身看起来有点不是太友好qwq，但正是通过这些得知了一些非常真实的感受和真实的情况，包括后来还问了不少技术上的问题，太多很细致的问题就没有一一在上文列出，总之受益匪浅。

以及一些自己的反思。问了自己很多次，为什么所有任务无论多早开始，都会在deadline的最后一秒甚至后一秒后两秒后三秒完成？这个千古难题其实之前在线下就问了学长，学长的回答是安啦，都是常态。但是屡次如此，还是觉得有点难受。

听说逸超学长去了美团，然而接受采访的时候身上穿的还是美图的文化衫 （逃