今天完成的事：

       wiki看了下项目规范，下了excel表看看

明天计划的事：

        继续看看项目

问题：

收获：

通用进项目须知——老大寄语

1。做好自测。

     自测并不仅仅是包括正常流程，还要包括异常流程。

     如果修改密码，要测到：1.密码不一致 2.密码长度不符合，3 密码输入不合法字符 4 密码为空 5.原始密码不正确

     这是目前项目中出现的最大的问题，根本就不明白怎么样才算是一个Story做完了。另外，后端也需要在本地或者是开发环境经常去测。

     不要让别人发现你负责的系统中的显而易见的Bug，这对程度员来讲是一种耻辱。

2.模拟数据。

   模拟假数据，不是模拟垃圾数据。

   假数据仅仅是指数据不真实，并不代表着数据可以随便填 。

   模拟数据的时候要保证数据的多样性，1是要尽可能的模拟正常使用的情况。 2是要尽可能的模拟异常的情况。

   做List要有翻页，金额和时间要有临界值，名称和图片都要能正常访问。

3.前后端分离开发。

    一定要先定接口，接口不一定非要后端来定，前端也可以参与接口的制订。简单沟通怎么实现，然后后端去在Wiki上写接口，前端确认是否需要修改。

    在写代码的时候不需要等待对方的真实数据完成，学会自己Mock数据，也学会自己Mock后端的响应，让自己的整个流程都是通的。

4.尽早集成。

   每日都需要在开发环境把代码全部部署，有问题提前发现，不要到最后才发现根本做错了，集成不进去。

5.公共代码的修改。

   公共代码的修改要提前说，说完之后要通知大家更新，尽量减少代码之间的冲突。

6.代码的复用。

    不可复用的代码也基本上代表着很难调调试。也很难加快项目的进度，随时问自己，哪些代码可以复用，可以定制。像登录，注册，短信，修改密码这些标准化的模块，真心的只需要一份就够了。

    不要每次写的时候都有一份。

    认真想想自己做的项目中，哪些是可以放到公共的基础库里去。

7.新框架的调研

     新框架的调研永远是先下载Demo，再修改成自己想要的样子，再去集成。

    不要一开始就在自己的系统中去集成开源框架。

    先保证有一个正式的可以运行的Demo版本，这样便于出问题的时候及时调试。

8.出错之后的调试。

   1.要看日志，看日志，看日志，函数的输入和输入出必须加日志，IF Else 必须写完整，加日志。

   2.尝试定位出错的模块。 各种各样的办法去减少无关的依赖。学会定位问题。

   3.找出曾经运行正确的代码，或者是可以跑的通的Demo，删减代码来比对。

   4.Mock数据来减少依赖，把Bug复现的代码最小化，多尝试不同的方案。

9.多去思考产品和原型中的交互和逻辑

    去一个会思考的工程师，不要跟我讲产品这么要求的，UI这么画的。做自己认可的东西，做自己虽然不认可但是得到了解释的东西。

    很多细节都是在开发工程师由工程师反馈给产品经理的。

    提出自己的疑问和建议，然后把决定权交给产品经理。

    让自己在做过的项目中都成为一个领域专家。

     经验就是这么来的。

10.不要让别人催促自己做事

     我一点都不希望项目中出现一个人，不停的去问，去催促项目的进度。

     做项目很简单，预估好时间，然后按自己的能力去努力完成，掌握好项目的节奏，不要让项目延期。

     学会估算时间，定时沟通和有异常情况及时交流，不要等。

 11 代码规范

      学会遵循代码规范，写易维护，能看懂的代码，减少耦合度，千万不要去写混成一团的代码。

      呆萌奎和99刚写代码没几天，就已经能写出来我完全看不懂的代码了，出了问题，简直没办法调试，很多时候，效率低是因为代码质量写的差。定位Bug困难是因为自己写的代码根本就没法看。

12 解决问题的思路

     写代码之前，先想好思路，遇到一些理不清楚的问题，提前找别人交流，思路先理清，再去写代码。

13 学会拆解模块

      脑袋里有要有积木的概念，把复杂的过程，拆解成一个一个独立的模块，互相之间必须要解藕。如果有遇到依赖别人的情况，就做好Mock，当真实的接口完成的时候，只需要更改Mock时候的方法，这样能尽可能的减少对他人的依赖。

14 单元测试

      单元测试最重要的是要有单元的概念，你能够把一个复杂的过程拆解成一个个的单元，再做测试的时候就非常容易定位问题。

15 不懂就问

      如果一个问题困扰了你3个小时，你就必须去找别人求助了。不应该在这个问题上花费更多的时间。要学会对自己做的事情有一个强制性的时间点负责任。

16.按天结账

     每天都要提交代码和部署程序，每天都要让自己做的东西是真实的，马上可以见到的。给自己的一天画上句号，不要让自己一天做完了东西，只是把代码提交到SVN上然后没有任何的进展。

17.描述清楚

     给别人提供东西的时候，一定要记得加上备注，把自己做的事情描述清楚，做了哪些，哪些没做，还差什么。不要让别人追着自己问问题。

18.随时重构

     好的代码是改出来的。不是写出来的。随时做好测试，随时对自己当初未想到的逻辑和代码做重构。正常情况下，一个项目至少应该被重构3~5次以上。在前期，比较合理的值是重构10次以上。

    可以遵循以下顺序来。1.先写伪代码来描述业务逻辑。2把多余的代码抽象成当前类的一个私有函数，所有在本类中使用的代码，都调用这个函数。2.将这个函数变成一个公共的Util类，将系统中所有使用到这部分代码的地方都更改为公共的Util 3.将这个Util变成一个第三方的包。将所有项目中有可能使用到这些方法的地方都替换成公用类。

19.提出问题，再给出多个解决方案

    不要把自己的思维局限死，仔细的把自己要做的事情，抽象成一个问题，然后再去想，我有什么样的方案可以去解决。

   每一个方案都去反复的想，他的好处和坏处。他的实现原理是什么样。有没有更好的方案可以去实现。让自己去做选择题。

20.不停归类

      学会分组和抽象，学会屏蔽掉细节，学会将手中的问题或者是一堆东西分组，然后命名。

      如一堆常量，不要堆积在一起，而是要想办法分组。然后事情就简单了，要么是分组不合理，要么是分组多一个，或者是少一个，要么是每个分组下的元素会多一点少一点。

     学会把一些底层的东西抽象成更高层的东西。