【实际开发14】- 进阶 A

目录

1. Java 工程师工作描述

2. 数据库 - 相关经验

1. 数据库表设计

2. 数据库字段设计

1. 业务存在对接多模块 xxxxId ( 请务必使用 varchar )

1. Iot 物联网平台 - machineId ( 对接摄像头异常 )

3. 数据优化 - 数据库行数缩减优化 ( 20.04.22 )

3. RESTful 风格 ( 详参 SpringCloud notes )

1. URI 设计原则 - 简析 ( 高度概括 ) × 10

4. UI | 产品 对接 ( 原型设计阶段 )

0. 提示 : 常规情景 UI / 产品 先行 , 非常规需 后端 参与对接

1. 原型 对接资料

1. 设计文档 - doc

2. 数据库设计 ~ pic

3. 功能分解 - excel

4. 原型基础梳理 - txt

5. 项目维护 ( 自己 )

1. deploy - 发布

1. developer's deploy

6. 项目维护 ( 他人 )

1. 离职同事项目交接 -【湖北省诉求平台】

1. 数据库 ( 字段说明 ) + ( 改动前备份 )

2. 配置信息说明

3. 代码注释 / 入参说明 / map 说明

4. 打包 / 部署 / 线上发布 - 流程说明

2. 交接他人负责的项目 - 经验

1. Questions : 问题 × tips 3

2. Solution : 方案 × tips 10

3. 其他工具类

1. 依赖异常 : 极有可能是 pom 引入依赖版本问题

---

1. Java 工程师工作描述

情景:

 作为一个Java工程师 , 我们在编写求职简历的时候有一个必填项就是工作描述 , 
 不要小看了工作描述 , 面试官可以借此判断你的技术能力和团队合作能力等方面 , 
 工作描述写得好可以极大提高面试成功率

Java工程师工作描述写作要点 ?

 重要性我们知道了 , 那么该如何写呢?
 ​
 Java软件工程师的工作描述书写可以根据以下几点:
 ​
 自己的工作职责 , 自己所承担项目主要负责什么?
         例如 , 有的人负责写接口 , 有的人负责调试等。
 ​
 简单描述一下自己负责的整个项目 , 让面试官有个大致的了解。
 ​
 简短的介绍所用到的相关技术。

Java工程师工作描述范文模板

①笼统的描述自己的工作内容

 1、负责研发公司应用软件的模块设计、开发和交付
 ​
 2、负责编码 , 单元测试
 ​
 3、按照功能组件的详细设计
 ​
 4、对其他软件工程师的代码进行审核
 ​
 5、参与新知识的学习和培训
 ​
 6、修复程序BUG
 ​
 7、参与与其业务相关的需求变更评审
 ​
 8、完成上级交办的其他事宜
 ​
 9、编写技术设计文档

②以项目的形式体现自己的工作内容和技术能力

比较推荐这一种方式 , 内容中主要包括 : 项目开始时间 , 完成时间 , 使用了哪些技术 , 完成了什么功能 ? 多少人的团队 , 你在其中起什么作用等。

如 :

 项目名称:《企业管理信息系统》 时期: 2006/06-07
 ​
 项目描述:
 以B/S方式实现管理网站的功能:企业员工通过企业分配的个人帐户可以搜索企业信息 , 
 查询企业所布置的任务;企业管理者可以通过注册系统帐户来搜索和布置任务 , 而且能对企业的员工进行权限限制等信息和功能。
 ​
 使用技术:JAVA , C , Oracle , Shell
 ​
 开发工具:Eclipse
 ​
 责任描述:系统维护和编码工作(5人小组 , 担任组长)
 ​
 项目总结:遇到的问题及解决方法。

---

2. 数据库 - 相关经验

---

1. 数据库表设计

设计核心表整整一个月 ( 数据库和开发代码一样 , 需要反复迭代 )

项目周期 : 2 周完成的项目也是合理的 ( 类似项目 , 仅是代码复制 )；

在开闭原则前提下 , 删除一个功能 , 都可能需要一周时间 ( 测试一周、保证接近100%没问题 )

设计数据库时 ( 允许错误 , 先写下想到的 )

关系没理清 : sql 语句写不好！

---

2. 数据库字段设计

---

1. 业务存在对接多模块 xxxxId ( 请务必使用 varchar )

---

1. Iot 物联网平台 - machineId ( 对接摄像头异常 )

    /**
     * 校验:通过设备id查询锚点信息(锚点设备一对一)
     * @param machineId 设备id
     * @return 锚点信息列表
     */
    private List checkAnchorByMachineId(String machineId){
        List iotAnchorVOList = new ArrayList();
        LambdaQueryWrapper queryWrapper = Wrappers.lambdaQuery()
                .eq(StringUtil.isNotBlank(machineId) , IotAnchor::getMachineId , machineId);
        List iotAnchors = baseMapper.selectList(queryWrapper);
        for (IotAnchor iotAnchor : iotAnchors) {
            IotAnchorVO iotAnchorVO = new IotAnchorVO();
            BeanUtils.copyProperties(iotAnchor ,  iotAnchorVO);
            iotAnchorVOList.add(iotAnchorVO);
        }
        return iotAnchorVOList;
    }

---

3. 数据优化 - 数据库行数缩减优化 ( 20.04.22 )

方案一:
    订单         配额id     配额key         配额value         数量
     1            1         cup            4              2        ......
     1            2         disk            500              3
     1

方案二:
    1、    {quota_id:1 , quota_key:cpu , quota_value:cpu , quota_num:2}......
    2、总量:{quota_id:1 , quota_key:cpu , quota_value:cpu , quota_num:2}......
    3、余量:{quota_id:1 , quota_key:cpu , quota_value:cpu , quota_num:2}......

    一个租户下 , 一个project下有10个订单 , 一个订单有8个配额 24配额(8个阿里 8个腾讯 8个烽火)
        方案1:80条        240条*20
        方案2:10条        80*20

    一个租户下 , 有5个project , 一个project下有10个订单 , 一个订单有8个配额......
        方案1:400条*20
        方案2:50条*20

    对接混和云
    将quota 和 quota_operation表修改一下

资源配额统计
    方案1:根据 通过租户、project  配额key  进行统计灵活性高
              租户id      cpu总量相加     在表中进行统计        数据量大 , 耗费性能
              project    cpu总量相加                      数据量小 , 快
              
    方案2:根据 通过租户、project、订单id  配额key  进行统计灵活性不高
              租户id    解析map , 拿到cup的key相加    在代码中进行计算      数据量大 , 相对性能高
              project  解析map , 拿到cup的key相加                    数据量小 , 慢

总结 :

1、存在统计的情况下 , 方案一相对更优 , 直接从表中统计计算 , 几乎不耗费性能

方案二 , 需要在代码层面遍历操作数据 , 相对繁琐 , 耗费心梗

2、不存在统计的情况下 , 方案二 , 成倍的较少了数据库里的数据行数 , 数据库性能方面相比更占优势

方案一 , 数据库行数相对较多 , 更容易达到数据库的阈值

---

3. RESTful 风格 ( 详参 SpringCloud notes )

RESTful 风格 , 没有传参数时 : 会报 400+ 错误

而传统URL没有参数时 : 报空指针；

URI设计原则 - 张建斌 - 博客园 URI设计原则

真正能把 RESTful 用好的 , 市面能用好不超过10%；

实际工作中 ( 不使用 powerdesigner ) 逻辑建模、物理建模转换 , 很难设计好数据库；

分模块开发 (user、book、)

后期项目 : 必须要有事务

JDBC 的事务 , 是默认开启的；

springMVC 默认使用 JDBC 的事务 , 故可直接增删改查成功。

事务是数据库的知识点 ( 但 mybatis、spring 都需要去连接数据库 , 所有他们需要与数据库具有部分相同的特性 )

---

1. URI 设计原则 - 简析 ( 高度概括 ) × 10

以下是与 REST API 相关的重要术语 :

• 资源 ( Resource ) 是一个对象或对某物的表示。它有一些相关联的数据 , 并有一组方法进行操作。 例如:动物 , 学校和员工是资源。这些资源都有着删除 , 添加 , 更新操作。

• 集合 ( Collection ) 是一系列资源 , 例如:公司集合是很多公司的集合。

• URL ( 统一资源定位符 ) 是一种路径 , 可以通过它定位资源并且也可以对它执行一些动作

1. URI 的末尾不要添加 / 多一个斜杠 , 语义完全不同 , 究竟是目录 , 还是资源 , 还是不确定而多做一次301跳转？ 负面case:http://api.canvas.com/shapes/ 正面case:http://api.canvas.com/shapes

2. 使用-提高URI的可读性 目的是使得URI便于理解 , 用“-”来连接单词 正面case:http://api.example.com/blogs/my-first-post

3. 禁止在URL中使用_ 目的是提高可读性 , “_”可能被文本查看器中的下划线特效遮蔽 负面case:http://api.example.com/blogs/my_first_post

4. 禁止使用大写字母 RFC 3986中规定URI区分大小写 , 但别用大写字母来为难程序员了 , 既不美观 , 又麻烦 负面case:http://api.example.com/My-Folder/My-Doc 正面case:http://api.example.com/my-folder/my-doc

5. 不要在URI中包含扩展名 应鼓励REST API客户端使用HTTP提供的格式选择机制Accept request header 负面case:【北京分类信息】北京免费发布信息网 - 北京58同城 正面case:【北京分类信息】北京免费发布信息网 - 北京58同城

6. 建议URI中的名称使用复数 正面case:http://api.college.com/students/3248234/courses 负面case:http://api.college.com/student/3248234/course

7. 每个 URL 代表一种资源(Resource) , 所以 URL 中只能有名词 , 不能有动词

   资源在 API 端点中应该总是复数 /addNewEmployee 包含了操作 addNew 和资源名称 Employee

    方法 GET 路径 /companies 是获取所有公司的列表。
    方法 GET 路径 /companies/34 是获取公司34的详细信息。
    方法 DELETE 路径 /companies/34 是删除公司34
    ​
    GET /companies/3/employees 可以取得编号为3的公司的员工列表
    GET /companies/3/employees/45 可以取得编号为3的公司的45号员工的细节信息
    DELETE /companies/3/employees/45 可以删除编号为3的公司的45号员工
    POST /companies 可以创建一个新公司并返回新创建公司的细节信息
    ​
    #结论:路径应该包含资源的复数形式 , HTTP 方法应该定义成各种行为在资源上执行。
    #URL 是一个句子 , 其中资源是名词 , HTTP 方法是动词。

8. HTTP 方法 (动词)

   GET 方法从资源请求数据 , 不产生多余结果。

   例如: /companies/3/employees 会返回公司3的所有雇员列表。

   POST 方法请求服务器在数据库中创建资源 , 这主要用于提交 Web 表单时 POST 是非幂等的 , 这意味着多个请求将会有不同的效果。

   例如: /companies/3/employees 创建一个公司3的新雇员。

   PUT 方法请求服务器更新资源或创建资源(如果不存在的话)。

   例如: /companies/3/employees/john 将请求服务器在公司3的雇员集合中更新或在不存在的情况下创建关于 john 的资源.

   PUT 是幂等的 , 这意味着多次请求具有相同的效果。

   DELETE 方法将请求的资源或实例从数据库中删除。

   /companies/3/employees/john/ 将请求服务器从公司3的雇员集中删除 john 资源。

9. 搜索、排序、过滤和分页

   • 排序(sorting) 例如 , GET /companies?sort=rank_asc 将根据等级以升序的方式对公司进行排序。

   • 过滤(Filtering) 例如 , GET /companies?category=banking&location=india 将根据公司类别为银行以及所处位置为印度来过滤公司的列表数据。

   • 搜索(Searching) 例如 , API 端点应当是 GET /companies?search=Digital Mckinsey。

   • 分页(Pagination) 例如 , GET /companies?page=23 表示获取第 23 页的公司列表。

     如果在 GET 方法中附加了很多查询参数 , 会造成 URI 太长 , 服务器可能会响应 414 的 HTTP 状态 , 表示这个 URI 太长 , 在这种情况下 , 我们也可以将参数传递给 POST 方法的请求体中。

10. 版本控制 例子 http://api.yourservice.com/v1/companies/34/employees 它的路径中有API的版本号。如果有任何重大的中断更新 , 我们可以将新的API集命名为v2或v1.x.x

---

4. UI | 产品 对接 ( 原型设计阶段 )

2021.10.25

---

0. 提示 : 常规情景 UI / 产品 先行 , 非常规需 后端 参与对接

---

1. 原型 对接资料

---

1. 设计文档 - doc

---

2. 数据库设计 ~ pic

---

3. 功能分解 - excel

---

4. 原型基础梳理 - txt

---

5. 项目维护 ( 自己 )

---

1. deploy - 发布

---

1. developer's deploy

---

6. 项目维护 ( 他人 )

---

1. 离职同事项目交接 -【湖北省诉求平台】

---

1. 数据库 ( 字段说明 ) + ( 改动前备份 )

---

2. 配置信息说明

---

3. 代码注释 / 入参说明 / map 说明

---

4. 打包 / 部署 / 线上发布 - 流程说明

---

2. 交接他人负责的项目 - 经验

当时有位三年经验的老员工即将内部调动到别的城市工作 , 他负责的模块交到了我的手上。

计算机专业科班出身 , 并且在校时熟读《Java编程思想》两遍 , 内心觉得不是啥事。等看到代码后 , 直接傻眼了。

代码行数倒不是很多 , 不到5000行的样子。其中一个`for`循环占了大概3000行！你没看错 , 是一个`for`循环。

本身对项目的业务知识不熟悉 , 代码里又各种特殊处理 , 只能一点点啃了。每天用eclipse debug , 两周后 , 逐渐理清了这个循环的基本逻辑。

如果是现在 , 我肯定会先做一些不改变代码逻辑的重构 , 拆分小方法 , 抽取重复逻辑等等 , 当时是不具备这个意识和能力的。

---

1. Questions : 问题 × tips 3

---

1、一开始就往代码细节上钻

 越是复杂的项目 , 这样做越是悲剧 , 你可能花费大量时间从代码上层层往下钻 , 结果却发现对于整体的功能根本无法掌握 , 最后迷失在源码中 , 给自己带来压力。
 ​
 因为复杂的项目 , 涉及的业务和逻辑很多 , 相互之间存在关联关系 , 仅仅靠代码上去阅读 , 效率是很低的 , 而且有些和具体业务结合的代码逻辑 , 你可能很难了解 , 即使看懂代码片段的功能 , 也不知道为什么要这样设计。
 ​
 记住:项目不是一个点 , 而是一个相互关联的面。

2、不做笔记 , 不写测试脚本

 我自己很难看过一遍就记住 , 往往当时理解了 , 但是过几天就忘记了 , 后面需要调试时 , 又得重新做一遍前面的工作 , 费事又费力。
 ​
 笔记和测试脚本 , 是一劳永逸的工作 , 其作用随着时间 , 越来越大。

3、急于求成

 总想着很短时间就完全掌握 , 结果没有把握住细节 , 看似都知道了 , 真正遇到问题却发现还是无法解决。

---

2. Solution : 方案 × tips 10

 

---

1、第一步 , 先用产品

 亲自使用产品 , 多问问产品经理 , 这是了解项目的第一步

2、复杂的项目 , 先从目的和设计入手

 这些内容相当于路标和线 , 能在大方向上给你指明道路 , 并帮你将代码片段串联起来。
 越是复杂的项目 , 其目的和设计占的比重越是重要。

3、掌握名词的概念

 特别是开发人员在开发过程中确定的一些名词 , 这有助于阅读代码 , 将其和具体功能联系起来。

4、优先了解数据流

 大部分项目 , 数据都是核心 , 特别是外部接口 , 尤为重要

5、通过单元测试 , 将复杂项目拆分简化

 项目难 , 往往是因为不了解 , 看着一大堆东西 , 心理上首先就有压力。
 可以通过细致的单元测试进行拆分 , 一方面有助于理解项目 , 另外以后出问题了 , 这些单元测试还可以用于调试。

6、编写文档

 如果项目没有文档 , 或者文档不够完善 , 那么一定要自己补上 , 今后你肯定会再次用到的。
 编写文字不像说话 , 耗费的时间会多一些 , 在打字的过程中 , 你会花费心思去组织语言和思考 , 这会让你发现更多的问题(就像我平时不善言谈 , 但是QQ聊天就比较能说 , 因为打字能给我思考的时间)。

7、循序渐进 , 注意复习

 除非很紧急 , 否则建议每天了解一些 , 然后每天思考一下 , 会发现更多的问题 , 同时一段持续时间的学习 , 相当于有个复习的过程 , 能够帮你巩固这些内容 , 否则很快就忘记了。

8、修改代码 , 查看输出

 这仅限于接口类代码 , 不适合整个项目

9、编写记录日志的函数

 在接口类功能的调试中 , 非常有帮助

10、一个好用的文件查找工具

 EditPlus的搜索功能很不错

---

3. 其他工具类

---

1. 依赖异常 : 极有可能是 pom 引入依赖版本问题

---

1. Iot-emergency 数据 Excel 导出 ( 依赖 ) 异常