作为一个资深码农，走过不少弯路。总结了一些新手建议，做成一个系列，欢迎持续关注，本期分享：项目开发中的一些建议
程序员的日常就是开发项目，给大家总结了我个人多年来关于项目开发的一些建议，希望大家少走弯路。
1. 统一开发工具
团队统一开发工具，这一点很重要。
Java开发工具有很多，idea, eclipse, myeclipse, vscode等。以比较常见的idea, eclipse来说，两者的缩进不一样，idea是4个空格，eclipse是tab缩进。
如果团队成员两个IDE都在用，会出现一种情况：小明同学明明只改了一行代码，但是代码评审时却显示他整个文件都改过了，因为他的开发工具跟别人不一样，把每一行的缩进都自动格式化了。
2. 先设计再写码
文档要坚持写，即使没人看。很多小公司并没有一套规范的项目迭代流程，久而久之，项目越来越难维护，业务理解全靠看代码，新人的任务就是看代码。
像我所在的公司，由于是支付公司，所以核心的项目不太敢走敏捷，还是用传统的瀑布模型。需求会有需求评审，设计会有设计评审，代码会有代码评审，测试会有案例评审，上线会有上线评审。当然有时候需求很小，确实是走个过场。但是这套模式确实可以有效的减少生产事故。
文档也是保护自己的一个方式，哪怕是简单的几句话的txt文档。有了文档，团队可以一起评审，一旦评审通过，如果上线后出现漏考虑的场景，那也是整个团队漏考虑，不至于自己担全责
3. 不要随意用框架
现在的Java框架太多了，很多小伙伴都会去学习各种框架，学习归学习，但不要轻易在项目里面实践。
像我公司，项目中用的每一个框架都是公司定好的，用哪个版本也是有规定的。一旦某个版本出现问题，公司会要求所有项目统一升级到高版本。包括服务器版本、JDK版本、容器版本也都是全公司统一。
其实很多框架没太必要，点名Mybatis Plus，用Mybatis 官方的Generator已经够了，我没看出来Mybatis Plus有什么优势。
现在很多架构师都是在做减配的工作，减少项目技术复杂度。
要不要用某一个框架，可以先思考以下几个问题：
- 是否能简化开发，提高开发效率？
- 这个框架是否大众，方案够成熟？
- 团队学习成本是否太高，是否有成员很精通？
- 是否是必要的，现有的框架不够用了？
4. 不要觉得重写就会更好
程序员都有一个特点，就是看不惯别人的代码。别人的代码，写得跟shi一样。不只是别人，看看自己几个月前写的代码，这么烂，恨不得重新再写一遍。
一个功能，经过五次需求迭代后，代码设计上肯定有很多可以优化的地方，这时候有些小伙伴就会想着重新写一套代码。可以先思考三个问题，再考虑要不要重写一套：
- 重新写一套就一定比现在的好吗？
- 你能保证前面五次迭代的功能一个不漏吗？
- 再过五次迭代，你的代码是不是又看不惯了？
5. 不要存侥幸心理
软件开发有个墨菲定律：“如果事情有变坏的可能，不管这种可能性有多小，它总会发生。” 总结一下就是：可能发生的事，一定会发生。所以不要心存侥幸。
有些同学在做项目的时候，会有侥幸心理，认为有些极端场景不会出现，可以不用考虑。
举个很常见的例子，很多项目喜欢用时间戳来处理业务，精确到毫秒，认为业务量不大，两次业务在同一毫秒发生很难出现，不用处理。其实很容易出现，比如公司防火墙堵一下，把前后两个请求都堵住了，等防火墙通了后，两个请求同时到达应用节点，这时就极可能出现两次业务发生在同一毫秒。
我们还出现过一种神奇的案例：A,B两个接口，业务上是：前端调用A失败时，会去调用B。结果服务端出现B先执行，之后A再执行。说来话长，以后再单独分享这个神奇的生产事故，欢迎持续关注公众号：甲蛙全栈。
6. 评估工时要留BUFFER
项目迭代中，有一个很重要的概念就是工期，一次迭代，设计，开发，测试各需要多长时间，这些工时都需要团队成员来评估。
在项目开发过程中，往往有需求以外的事情需要处理。比如生产突发事故、运营反馈问题、领导要各种文档、报表数据等等，所以不能把自己逼得太死。
当然估时太长也不可取，有偷懒嫌疑。
一般留个20%BUFFER比较合适，比如需要5天，那么可以报价6天。项目经理、产品经理等也都知道这些估工时的法则，所以一般都会接受。
以上说的留BUFFER的法则有一种场景不适用，就是老板说：我明天就要……
7. 要有产品思维
简单的说，就是要站在客户的角度来设计程序。
我们做出来的项目，最终是要给客户用的。所以多想想用户想要什么？怎么操作方便？
比如比较常见的是枚举型设计，举例：“男“和”女”，是做成下拉框，还是单选框。做成下拉框的比较常见，整个项目对枚举类型的操作，全是下拉框。其实做成单选框操作更方便。如下图：
久而久之，自己也算半个产品经理了，又有技术，再来个创意，就可以技术创业了！
8. 需求是可以商量的
做项目很重要的是多沟通，需求是可以商量的。一般可以通过下面三个方面来考虑：
- 需求删减：有些时候，需求提得太复杂了，但是实际业务却用不多，这种需求可以适当的删减，优先保核心业务快速上线。
- 需求拆分：产品经理提需求总是有优先级的，可以将需求拆分成多次迭代，紧急的先上，核心业务先走起。比如常见的报表，属于不是那么紧急，有业务之后，才会有报表，可以放在下一次迭代。
- 需求修改：有时候产品经理提的需求，不一定是最优解，只要你的想法、设计比产品的需求更好，更合理，更简单，产品经理就很乐意修改他的需求。
9. 每天下班提交代码
很多小伙伴不太注意这一点，一个功能，开发了5天，全部开发完后才提交，这种做法很常见，风险很大：
- 一大堆代码很难调试
- 领导看不出你每天的工作量
- 万一突然要请假一辈子，手里的代码咋办？
推荐做法：
- 每完成一个小功能，提交一次，方便以后代码比对核查，甚至是回退。
- 每天下班前提交代码，因为你不知道明天和意外哪个先到。
- 提交代码前要保证编译通过，别找骂！
—————— THE END ——————
