资深码农给新手的一些建议——项目开发

作为一个资深码农，走过不少弯路。总结了一些新手建议，做成一个系列，欢迎持续关注，本期分享：项目开发中的一些建议

程序员的日常就是开发项目，给大家总结了我个人多年来关于项目开发的一些建议，希望大家少走弯路。

1. 统一开发工具

团队统一开发工具，这一点很重要。

Java开发工具有很多，idea, eclipse, myeclipse, vscode等。以比较常见的idea, eclipse来说，两者的缩进不一样，idea是4个空格，eclipse是tab缩进。

如果团队成员两个IDE都在用，会出现一种情况：小明同学明明只改了一行代码，但是代码评审时却显示他整个文件都改过了，因为他的开发工具跟别人不一样，把每一行的缩进都自动格式化了。

2. 先设计再写码

文档要坚持写，即使没人看。很多小公司并没有一套规范的项目迭代流程，久而久之，项目越来越难维护，业务理解全靠看代码，新人的任务就是看代码。

像我所在的公司，由于是支付公司，所以核心的项目不太敢走敏捷，还是用传统的瀑布模型。需求会有需求评审，设计会有设计评审，代码会有代码评审，测试会有案例评审，上线会有上线评审。当然有时候需求很小，确实是走个过场。但是这套模式确实可以有效的减少生产事故。

文档也是保护自己的一个方式，哪怕是简单的几句话的txt文档。有了文档，团队可以一起评审，一旦评审通过，如果上线后出现漏考虑的场景，那也是整个团队漏考虑，不至于自己担全责

3. 不要随意用框架

现在的Java框架太多了，很多小伙伴都会去学习各种框架，学习归学习，但不要轻易在项目里面实践。

像我公司，项目中用的每一个框架都是公司定好的，用哪个版本也是有规定的。一旦某个版本出现问题，公司会要求所有项目统一升级到高版本。包括服务器版本、JDK版本、容器版本也都是全公司统一。

其实很多框架没太必要，点名Mybatis Plus，用Mybatis+官方的Generator已经够了，我没看出来Mybatis Plus有什么优势。

现在很多架构师都是在做减配的工作，减少项目技术复杂度。

要不要用某一个框架，可以先思考以下几个问题：

1. 是否能简化开发，提高开发效率？

2. 这个框架是否大众，方案够成熟？

3. 团队学习成本是否太高，是否有成员很精通？

4. 是否是必要的，现有的框架不够用了？

4. 不要觉得重写就会更好

程序员都有一个特点，就是看不惯别人的代码。别人的代码，写得跟shi一样。不只是别人，看看自己几个月前写的代码，这么烂，恨不得重新再写一遍。

一个功能，经过五次需求迭代后，代码设计上肯定有很多可以优化的地方，这时候有些小伙伴就会想着重新写一套代码。可以先思考三个问题，再考虑要不要重写一套：

1. 重新写一套就一定比现在的好吗？

2. 你能保证前面五次迭代的功能一个不漏吗？

3. 再过五次迭代，你的代码是不是又看不惯了？

5. 不要存侥幸心理

软件开发有个墨菲定律：“如果事情有变坏的可能，不管这种可能性有多小，它总会发生。” 总结一下就是：可能发生的事，一定会发生。所以不要心存侥幸。

有些同学在做项目的时候，会有侥幸心理，认为有些极端场景不会出现，可以不用考虑。

举个很常见的例子，很多项目喜欢用时间戳来处理业务，精确到毫秒，认为业务量不大，两次业务在同一毫秒发生很难出现，不用处理。其实很容易出现，比如公司防火墙堵一下，把前后两个请求都堵住了，等防火墙通了后，两个请求同时到达应用节点，这时就极可能出现两次业务发生在同一毫秒。

我们还出现过一种神奇的案例：A,B两个接口，业务上是：前端调用A失败时，会去调用B。结果服务端出现B先执行，之后A再执行。说来话长，以后再单独分享这个神奇的生产事故，欢迎持续关注：甲蛙全栈。

6. 评估工时要留BUFFER

项目迭代中，有一个很重要的概念就是工期，一次迭代，设计，开发，测试各需要多长时间，这些工时都需要团队成员来评估。

在项目开发过程中，往往有需求以外的事情需要处理。比如生产突发事故、运营反馈问题、领导要各种文档、报表数据等等，所以不能把自己逼得太死。

当然估时太长也不可取，有偷懒嫌疑。

一般留个20%BUFFER比较合适，比如需要5天，那么可以报价6天。项目经理、产品经理等也都知道这些估工时的法则，所以一般都会接受。

以上说的留BUFFER的法则有一种场景不适用，就是老板说：我明天就要……

7. 要有产品思维

简单的说，就是要站在客户的角度来设计程序。

我们做出来的项目，最终是要给客户用的。所以多想想用户想要什么？怎么操作方便？

比如比较常见的是枚举型设计，举例：“男“和”女”，是做成下拉框，还是单选框。做成下拉框的比较常见，整个项目对枚举类型的操作，全是下拉框。其实做成单选框操作更方便。如下图：

久而久之，自己也算半个产品经理了，又有技术，再来个创意，就可以技术创业了！

8. 需求是可以商量的

做项目很重要的是多沟通，需求是可以商量的。一般可以通过下面三个方面来考虑：

• 需求删减：有些时候，需求提得太复杂了，但是实际业务却用不多，这种需求可以适当的删减，优先保核心业务快速上线。

• 需求拆分：产品经理提需求总是有优先级的，可以将需求拆分成多次迭代，紧急的先上，核心业务先走起。比如常见的报表，属于不是那么紧急，有业务之后，才会有报表，可以放在下一次迭代。

• 需求修改：有时候产品经理提的需求，不一定是最优解，只要你的想法、设计比产品的需求更好，更合理，更简单，产品经理就很乐意修改他的需求。

9. 每天下班提交代码

很多小伙伴不太注意这一点，一个功能，开发了5天，全部开发完后才提交，这种做法很常见，风险很大：

1. 一大堆代码很难调试

2. 领导看不出你每天的工作量

3. 万一突然要请假一辈子，手里的代码咋办？

推荐做法：

1. 每完成一个小功能，提交一次，方便以后代码比对核查，甚至是回退。

2. 每天下班前提交代码，因为你不知道明天和意外哪个先到。

3. 提交代码前要保证编译通过，别找骂！

—————— THE END ——————