为了账号安全,请及时绑定邮箱和手机立即绑定

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

2020.11.11 16:57 1371浏览
Java架构师-十项全能
点击查看
¥8800.00 6166.00 (历史最低价,仅限618活动期间)
作为一个资深码农,走过不少弯路。总结了一些新手建议,做成一个系列,欢迎持续关注,本期分享:项目开发中的一些建议

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

1. 统一开发工具

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

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

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

http://img2.sycdn.imooc.com/5faba6d90001a98206900690.jpg

2. 先设计再写码

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

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

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

http://img4.sycdn.imooc.com/5faba6d900013a9a04130359.jpg


3. 不要随意用框架

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

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

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

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

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

  1. 是否能简化开发,提高开发效率?

  2. 这个框架是否大众,方案够成熟?

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

  4. 是否是必要的,现有的框架不够用了?

http://img1.sycdn.imooc.com/5faba6da0001f9ad01980186.jpg


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

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

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

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

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

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

http://img3.sycdn.imooc.com/5faba6da00014ffa05000500.jpg

5. 不要存侥幸心理

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

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

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

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

http://img4.sycdn.imooc.com/5faba6da00010baa04000181.jpg


6. 评估工时要留BUFFER

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

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

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

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

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

http://img1.sycdn.imooc.com/5faba6da000170e804580250.jpg

7. 要有产品思维

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

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

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

http://img3.sycdn.imooc.com/5faba6da00015a9e07190333.jpg


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

http://img4.sycdn.imooc.com/5faba6db0001ef3e03900317.jpg


8. 需求是可以商量的

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

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

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

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

http://img1.sycdn.imooc.com/5faba6db0001e87006400226.jpg

9. 每天下班提交代码

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

  1. 一大堆代码很难调试

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

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

推荐做法:

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

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

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

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


点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

10人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消