代码提交时机及原则

  1. 一项工作完成，任何时候都应该及时提交代码
  2. 下班前，把还没有提交的代码收尾并提交，提交代码的原则是：不要报错，提交的代码不要影响别的同事的工作，如果工作还未完成，建议在恰当的地方写好 todo，或者在提交备注写好已完成的工作有哪些，待完成的工作有哪些
  3. 第二天可以查看头一天写的 todo，或者查看提交备注，方便及时进入工作状态
  4. 需要达到这样的效果：哪怕第二天开不了机，对工作影响也并不大，换一台电脑，拉取代码，很快就能进入工作状态

提交备注

提交代码，一定要有合适的备注，要能覆盖到所有修改，可编号1，2，3这样来写，这也是方便后期排查问题

及时提交代码的好处

  1. 可以减少代码冲突
  2. 即使有代码冲突，因为每次提交的代码并不多，解决冲突比较容易
  3. 可有效避免：因操作系统崩溃导致代码丢失、甚至因突如其来的硬盘损坏导致辛辛苦苦写好的代码付诸东流

前车之鉴

  1. 24年8月26号，办公室的数据盘（联想 SSD，SATA 接口）挂掉，导致之前的 redmine 数据完全丢失，与工作相关的文档，花了很多精力维护的，说丢就丢了，完全是措手不及的感觉
  2. 24年9月8号，离上次数据盘“灾难”事件还不到两周，家里的主硬盘（三星 SSD，SATA 接口）损坏，无法识别，无法进入系统，再一次体会了措手不及的感觉，好的是，代码都有及时提交
  3. 有过电脑突然无法开机的情况，头一天还好好的，第二天上班开不了机，原因是内存条接触不好，有时候，同一台电脑，发生的频率有一点高~~
  4. 曾经有那么一台配置很超前很前卫的电脑，颜值爆表、肩负重任，承载了主人无限的期望与使命，虽然前几次罢工，都很快恢复了，但是（然而），有一次“熄火”罢工之后，再也没有“醒”过来，直到主人鼓捣时主板被烧掉，最终因主人的误操作“壮烈牺牲”~~

最少代码提交原则

总的来说，是一次提交，包含的代码修改要尽量少

  1. 避免一次提交很多个文件的修改，一个文件也尽量避免一次提交很多内容的修改，这样不方便后期排查问题
    • 建议把功能分成若干个小的功能，一次提交一个相对而言比较完整的功能，如果代码过多，可以分方法来提交
    • 有时候代码有问题，需要回滚的时候，就知道这个习惯有多么的重要
    • 在一大堆代码中排查问题的时候，也会知道这个习惯有多么的重要
  2. 提交代码前，建议利用 idea 或 webStorm 或 vsCode 代码比较功能再逐个检查修改的地方，边检查边写提交备注，备注更精确，另外，在检查过程中把错改的恢复，把有问题的代码取消勾选，留到下次提交
  3. 仅提交某一个功能的修改：提交前打开变更比较窗口，只勾选本次需要提交的代码，不同的功能修改建议多次提交

redmine 上的任务状态

  1. 一项工作完成，任何时候都应该及时修改任务状态，记录工时
  2. 下班前，更新正在进行中的任务，包括：进度、工时，如果工作还未完成，建议提交工作完成情况，比如还有哪些工作待完成，预计完成时间等
  3. 一般来说，只有一个任务是【进行中】，在分配任务的时候，考虑了【最少代码提交原则】（见下面），建议完成一个任务之后，再完成下一个，当然，在着手修改代码之前，可以先看一下相关的问题任务，可以一起修改，但记得分问题提交代码

修改问题

redmine 上的问题，着手修改之前，把状态由【新建】改为【进行中】，方便协作：

  1. 针对【进行中】的问题，提问题的人如果要修改，需要通知问题接收人一声，因为问题接收人看了问题内容之后，可能已经在着手修改代码了，要避免修改问题内容和解决问题的人信息不对称
  2. 方便测试人员了解开发当前在做哪一项工作

代码修改

  1. 涉及到代码格式化的修改，一定是先格式化之后，不再做别的修改，直接提交一版，然后再改别的逻辑。格式化的修改，在排查问题时可以跳过
    • 另外，通过 ide 来格式化代码，往往改动的地方比较多，差异也比较多，如果还混杂着逻辑修改，排查问题难度非常大
  2. html 代码，一般不建议用 ide 的格式化功能，可能会使 html 大乱，一般建议手工调整

提测

  1. 代码完成之后一定是先自测，测试要准确，需要覆盖到修改的地方，否则问题容易被重新打开。重新打开率高会影响到考评
  2. 自测，覆盖所有分支，优先做白盒测试，最后是整体流程测试
  3. 测试无误之后，提交代码。提交代码时，备注内容建议加上问题编号和问题标题，或者可以清晰描述修改内容的文字
    • 如：“@98 当抽奖活动被商家删除，或者商家装修的时候，活动 id 错误，需要在页面弹出提示，提示关闭之后，页面也要直接展示提示信息”
  4. 代码提交完毕之后，再修改问题状态
  5. 负责测试的同事，看到问题状态变为【解决】之后，意味着可获取最新代码着手测试工作了

后端 api 错误代码

返回前端的码，要根据不同情况返回不同的 code，不要有雷同的，方便前端与后端联调查询数据问题

合理使用缓存及静态变量

  1. 禁止用静态变量保存临时数据，哪怕会及时清理也不要，因为后面的人，可能忘记调用清理方法了，会导致应用存在内存耗尽从而崩溃的风险
  2. 系统级别的数据才应该考虑用静态变量
  3. 不常用的数据，一般也不建议用静态变量保存
  4. 与具体业务或商家相关的数据，如果需要经常访问，一般需要用缓存
  5. 缓存 key 前缀，需要统一管理和使用，一般用常量来定义，针对一个 key 需要有对应的设置和清理方法，且在代码上，是设置方法下面就是清理方法

前端元素命名

为了减少命名冲突，需要带模块（业务）前缀，如：winnerListUseNewVersion、tbodyWinnerListBatchFormImportFile

开发工具设置

  1. 确保将tab换成4个空格
  2. 确保将文件的编码格式全部设置成:UTF-8

数据库开发

  1. 不可以在sql里用聚合函数。
  2. 开发时尽量用简单sql语句查数据。对数据的处理逻辑一律放到应用端，避免使用存储过程。
  3. 除非不得已，不要在sql语句里进行多表关联查询。如果非要这么做，请联系项目负责人。

有关枚举的使用

  1. 代码逻辑里有用到某一字段判断的，这个字段如果有多种可能的情况，典型的例子就是状态值，如果还没有枚举，需要维护一个对应的枚举。

  2. 跟这个字段相关的代码不允许直接使用数字，一律要用枚举。示例：

    1
    2
    3
    4
    5
    6
    7
    8
    9
    // 标记为删除
    bigDrawSeting.setStatus(BigDrawStatusEnum.DELETE.getIndex());
    // some code ...

    // 奖品数量不足，活动结束
    if (bigDrawSeting.getStatus() == BigDrawStatusEnum.PRIZE_OUT_OF_STOCK_OR_PRIZE_BOTTOM_OVERDUE.getIndex()) {
        return "<span class='sui-label label-danger'>奖品数量不足或兜底奖已过期，已结束</span>";
    }
    // some code ...

  3. 好处

    • 查看代码时，设计良好的枚举，能够做望文知义，ctrl+鼠标点击，跳转到枚举定义，能看到其他枚举定义，对于理解代码和业务逻辑有很大的帮助。
    • 修改枚举对应的值时，程序的业务逻辑代码不受影响。
    • 业务逻辑发生变化，需要对某一个字段表示的意义做调整，从而需要修改枚举定义时，可以利用 IDEA 等开发工具的重构功能，快速修改使用到枚举的地方，快捷高效。
  4. 其它有多种可能性的代码处理，也需要通过枚举来辅助。

有关 todo，好记性不如烂笔头

建议：

1
2
3
4
5
6
/*
有疑问的，【todo ****】
需要很快解决的，【todo ***】
不影响系统运行，不影响逻辑，优化部分，【todo **】
不确定是否需要优化但逻辑正确的，【todo *】
*/

在上线前，全项目搜索需要很快解决的代码。

1
2
//临时测试 测试完恢复 todo ***
List<TopTmcMessageQueueView> NeedSyncTradeMessageQueueViews =messageQueueViews;

上面的条件不再适用的时候，将todo 删除掉

1
List<TopTmcMessageQueueView> NeedSyncTradeMessageQueueViews = messageQueueViews.stream().filter(o->CommonService.topicsNeedSyncTrade.contains(o.getTopicEnum())).collect(Collectors.toList());

多模块，添加pom父模块

唯一的好处是可以统一管理依赖，其它相关项目不需要管理自己的依赖项。但是弊端也挺多的，如下：

  1. 会导致依赖混乱，如某一个依赖项只有其中一个模块要用到，结果依赖到这个父模块的子模块全部都要依赖它，某一天，这个依赖不再需要了，又不敢随便删除依赖，因为怕别的子模块需要，人手多了，随着时间推移，众多依赖项都不知道哪些是多余的。

    如果让每个模块单独管理自己的依赖，在察觉到有多余依赖时，尽管删除，只要保证这个模块能编译通过即可。

  2. 方便重用某些公共模块，别的项目只要引入这个模块即可使用，而不用管理它的依赖项。

结论

需要根据实际情况作出取舍，建议父模块只保留最基础的依赖，确保这些依赖是项目不可或缺的。

团队是否应该使用同样的 IDE？

  1. 作为一个资深的 windows 使用者和电脑重度使用者，最关键的，是每天跟代码打交道，每天需要看代码，修改代码，同时还需要聚精会神的思考，所以，我们不要让操作键盘和鼠标影响我们思考从而降低工作效率。
  2. 那么，盲打肯定是必须的，不光盲打，而且还要快。正确的姿势是什么呢？双手放到键盘上，目视屏幕，很多操作都是通过键盘的快捷键完成，比如 windows 的日常操作，切换软件界面用 Alt+Tab，打开我的电脑用 win+E，创建新文件夹用 Ctrl+Shift+n 等等。
  3. coding，更是要讲究高效，麻利，那么，正确使用 IDE 的姿势，少不了快捷键的熟练使用，代码自动完成这些应该都不在话下才对。比如想要输入 【System.out.println(“ something “);】，只需要输入 sout 之后，再敲 Ctrl+空格，然后会出现选择框，默认第一项就是我们想要的，只需要再敲回车就 OK 了。IDEA 更快，输入 so 然后默认第一项就是，之后回车就 OK 了。
  4. 那么，如果你跟我一样，自己最常用的是 IDEA，而团队里有成员在用 sts，时不时的有下属有问题需要你去解决，你又不能硬性的要求别人都使用 IDEA，这样因为 IDE 的不同，会非常影响交流效果，因为你去那座位上看代码，会很不习惯，往往会影响你思考甚至可能会影响到你的信心。但是如果你也用跟他同样的 IDE 的话，就好办了，你可以用你自己的电脑跟他交流，这样，打造一个你自己熟悉的跟同事一样的 IDE 环境就显得非常重要了。
  5. 说得有点多哈，其实，在一个团队里，要求都用同样的 IDE 会带来很多方便和避免很多不必要的麻烦。但是这个要求，实施起来有点难度，对于使用怪了 Eclipse 的，要求用 IDEA，对他（她）来说是一件非常痛苦的事情。

建议

可以选自己熟悉的 IDE，可通过日常分享使用 IDEA 的心得，尽量让团队统一使用 IDEA。

技术之外

文字说明

文字信息要准确无误，简练干脆不拖拉，不带个人感情色彩，标点全部大写，不要用叹号

  1. 语气词：尽量不要用，可能会引起商家或顾客的反感，需要谨慎对待。当然，系统里存在少量的语气词，如：来晚了哦，活动已经结束，下次记得早点来
  2. 排版：尽量排放整齐，精练，该有的要有，不该有的，坚决不留（是不是废话？^.^）

产品感

  1. 多站在商家立场思考和体验我们的功能，操作尽量简单，功能设计尽量不要太复杂，要把商家当小白来看待
  2. 同时也要多站在顾客的立场考虑操作的便捷性和参与体验
  3. 提示信息尽量简单明了，不要啰嗦。不要展示复杂的提示信息，复杂的提示信息可以让商家或者顾客点击之后再弹出或者显示出来，复杂的提示一般不会有人仔细看的

业务优先

  1. 技术是为业务服务的，能为业务提供支撑的技术就是好技术
  2. 能带来价值的业务，才是好的业务，不要为了业务而业务，也不能为了技术而技术
  3. 再牛B的技术，如果与业务结合度不高，那么价值就不大，技术的价值与业务的结合度成正比
  4. 再炫酷的软件界面，如果不是商家需要的，那也一文不值

业务架构与技术架构

  1. 好的产品，被用户需要的产品，才有生命力，只注重技术或只注重业务都可能会事倍功半
  2. 只有技术和业务恰当的结合，才能有可能达到事半功倍的效果
  3. 两个方面都重要，好的架构师也是基于一定的业务场景去架构的
  4. 细节决定成败，技术也好，业务也好，除了大的方向之外，竞争力更多的是在于对细节的把控