目录
1. 业务存在对接多模块 xxxxId ( 请务必使用 varchar )
1. Iot 物联网平台 - machineId ( 对接摄像头异常 )
3. 数据优化 - 数据库行数缩减优化 ( 20.04.22 )
3. RESTful 风格 ( 详参 SpringCloud notes )
1. URI 设计原则 - 简析 ( 高度概括 ) × 10
0. 提示 : 常规情景 UI / 产品 先行 , 非常规需 后端 参与对接
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<IotAnchorVO> checkAnchorByMachineId(String machineId){
List<IotAnchorVO> iotAnchorVOList = new ArrayList<IotAnchorVO>();
LambdaQueryWrapper<IotAnchor> queryWrapper = Wrappers.<IotAnchor>lambdaQuery()
.eq(StringUtil.isNotBlank(machineId) , IotAnchor::getMachineId , machineId);
List<IotAnchor> 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 ( 统一资源定位符 ) 是一种路径 , 可以通过它定位资源并且也可以对它执行一些动作
-
URI 的末尾不要添加
/多一个斜杠 , 语义完全不同 , 究竟是目录 , 还是资源 , 还是不确定而多做一次301跳转？ 负面case:http://api.canvas.com/shapes/ 正面case:http://api.canvas.com/shapes -
使用
-提高URI的可读性 目的是使得URI便于理解 , 用“-”来连接单词 正面case:http://api.example.com/blogs/my-first-post -
禁止在URL中使用
_目的是提高可读性 , “_”可能被文本查看器中的下划线特效遮蔽 负面case:http://api.example.com/blogs/my_first_post -
禁止使用大写字母 RFC 3986中规定URI区分大小写 , 但别用大写字母来为难程序员了 , 既不美观 , 又麻烦 负面case:http://api.example.com/My-Folder/My-Doc 正面case:http://api.example.com/my-folder/my-doc
-
不要在URI中包含扩展名 应鼓励REST API客户端使用HTTP提供的格式选择机制Accept request header 负面case:【北京分类信息】北京免费发布信息网 - 北京58同城 正面case:【北京分类信息】北京免费发布信息网 - 北京58同城
-
建议URI中的名称使用复数 正面case:http://api.college.com/students/3248234/courses 负面case:http://api.college.com/student/3248234/course
-
每个 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 方法是动词。
-
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 资源。
-
搜索、排序、过滤和分页
-
排序(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 方法的请求体中。
-
-
版本控制 例子 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 导出 ( 依赖 ) 异常
320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
