校园 与 公司

废话

进入团队已经一个月了，今天中午写了实训计划中的总结之后，还有一些感想，特开一篇，做一个较为全面的总结。就像往常，作为以后自己有时间就回过头来看看的文章吧。赠与未来的自己。

正文

人 与 人

这一个月，过的是真的比较快，由其是在后面真的融入团队作业的时候。与前面自己在学校里做一些 Android 或者 Unity 开发，甚至和 在公司的第二个月的实训项目，都有截然不同的体验。大概是由于自己的团队经验太过于青涩，我们天马行空组也是非常年轻，使得当时暴露出了很多问题，我们最终的工作，也是相当于是一个从 4 人众变成了 2 个人甚至是一个人的游戏，组员之间的联动太少。在团队中参与了一次开发之后，觉得交流，以及交流的技巧真的是我现在必要学会的东西，不懂一定要问，就算是自己已经有处理方案，也应该提出来给同事或者主管，根据他们的意见再进行下一步的处理。一个人不可能做完所有的事情，有问题就需要及时的抛出，自己无法解决的，可能对于别人来说就是一个非常简单的问题，但是有人会想，这样解决问题不就是个伸手党吗？什么问题都直接抛出，就坐等答案？不不不。问题有一种原则也就是前面提到的 四象限原则，我们遇到不是紧急的事情的时候，可以自己琢磨，但是不要太久，一小时还没有进展，就需要场外求助了，如果是紧急的问题，我劝你还是好好的想想解决方案，然后就征求同事和主管的意见吧，还要看看问题的波及范围，很多时候，我们的改动不只对我们自身会产生影响，可能会对其他的部分也有影响，而这个影响范围有多大？除了挖掘代码，我们这些新鲜的人就需要向经验老道的同事询问业务了，他们比我们了解这个系统，了解这个系统的业务，比我们慢慢的去挖掘代码逻辑有时候会来的快的多。
我们最离不开的就是人。

我们 与 项目

经过这次项目，我最大的感想就是，一个项目远比你对它的第一映像还要复杂。我们需要怀着一颗敬畏的心看待每一个项目任务。及时从表面上它看起来很简单，我们仍然能够从中写出很多的 bug。
由其是对于项目的迁移的问题，看似很简单，实际上是考验细致程度与耐心，从老代码中迁移到新代码，很容易就会遇到代码逻辑丢失（因为我们是迁移，而不是一律照搬），不可避免的就会出现逻辑的不同，代码的修改，有可能就会导致有些漏网之鱼。每个项目任务，都是不简单的，把一件事情，从最严格的方向，和最悲观的方向来进行处理的想法，一般是会满足大多数场景的。

Code Review

这个其实应该可以写在上面那一条一起，但是我觉的这个是非常重要的，所以还是单独的提出来自成一条。
我们的页面上面是分为两部分的，前台 UI 代码，和后台的逻辑代码，以及后台的业务代码，很多东西，我们从页面体现上直观的看可能会是好的，也有可能是运气好所以我们看到的就是好的，当代码已经大多数满足条件的情况下（或者有一定的代码量的情况下）我们就需要回一下头，对以往的代码（当然是这次任务中的代码），进行一次 Code Review 从这个中间，我们能够检查出漏掉的逻辑，以及以前的逻辑与现在的处理的区别，可能我们在 Coding 的时候没有发现的问题会在这个时候得到体现，毕竟代码迁移的工作就是先搬大体框架，再去深入骨髓。如果是新的一个需求，我们就需要去进行逻辑上的梳理，确定这样做能够完成用户的需求，不会存在多余或者是错误的逻辑以及代码，也可以挖掘出一些潜藏在代码中就能够发现的 bug，而且有时候因为这个错误可能测试用例并没有覆盖到。

I’m coding done?

首先 Coding 不是 Coding，这句话好像有点奇怪，用博大的中华文化来看看吧。Coding 是指的编写代码吗？，以前的我是这样认为的，就是编码完成以及完成页面的基础测试，点击页面不会崩溃，能够正常的交互，执行正确的功能。至于更加深度的测试，那个就属于是测试的范畴了。但是这次项目之后，我觉得，Coding 是 编码 + 测试（虽然不是所有的测试用例都需要测完），但是仍然会覆盖大多数使用场景，除了数据流向等等需要 DB 配合的，或者其他工具的，我们都应该测试，然后 fix 其中体现的问题。然后就是重点，进行一下此条的测试，由于我仍然比较懒，所以我是在 fix 了一定的 bug 之后再做的回归，感觉这个应该影响不大，毕竟大家都是 bug，都是这个时间段出来的。一起回归也是可行的。

Self-Testing

自测，是个很重要的环节，我们需要完完全全按照测试 提供的测试用例来进行测试，以及我们在编码的时候发现的逻辑，我们需要对测试用例没有覆盖到的地方向测试提出来，而不是敷衍了事，这样是对整个团队的不负责，是对自己工作的不负责。当我们编码基本完成之后，我们就是测试。要用苛刻的心态去检查问题，而不是害怕自己的程序被找出问题，能够找出问题修正才是好的，怕的不是我们自己找出问题，怕的是客户找出问题。

需求评审

这个也是很重要的一个环节，这大概是任务部署后一个团队的人真正的第一次全员会议（对于此个项目），从这次会议，能够发现一些需求中体现出来的问题，比较熟悉业务的测试会发现一些需求描述上的问题，开发会提出从实现方面的一些问题，或者是一些以前的问题，或者是这次的技术问题。总之这次会议对于整体的项目流程很有帮助。

用例评审

从体验上来说，这次的项目任务中，我的个人感受，就是在这次会议之中我们爆出了很多的问题，比需求分析的时候多的多，也正是因为这次会议，我在之后才又去清查了代码的逻辑以及页面的UI。可能像 Anna 说的一样，现在需求分析是越来越水了，可能从中体现的问题不是很多，但是从用例评审中就体现出来了，光是我负责的这个很简单的部分，都找出了 7 个待确认或者待修改的问题。

校园 与 公司

好像偏题太多，标题为校园和公司，扯了半天其他的问题，
我们在校园里是怎么样？我不知道大家的体验，就我个人而言，我也算参加过一次团队项目吧，是学校的体质监测系统，我们当时的人手就很简单了，2 人 数据库，1 人 UI，1 人 WebServices。很不幸，我就是那个负责 WebServices 的，所以没有太多的团队交流，顶多是问问 负责数据库，整体流程就是全部在寝室进行开发，以至于最终与 UI 的交接都是我去写的。也就是完全是自己在玩自己的东西。时间上来说也比较宽裕，几个增删改查，不是很复杂场景下的查询，周期是一个月。而在公司就不一样了，时间一般都是比较紧张，因为我们必要覆盖测试，从本地测试到最终的临线测试。技术也不是自己在学校中所学的，虽然我爱好广泛，但是始终是有没有了解到的方面。无论是从应用，还是实现过程，还是交流，与以前学校都是不一样的，而且这个面对的都是用户的检查，也不是一个起步的项目，是一个有用户基础的项目。这才是真的开发过程！！