希望每一位2017殚精竭力的“Java程序猿”在2018宏图大业
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了希望每一位2017殚精竭力的“Java程序猿”在2018宏图大业相关的知识,希望对你有一定的参考价值。
2017年,做得越多觉得自己不会得越多,有种殚精竭力的感觉。这一年在技术上的思考和实践的比较多,也大胆的尝试做了跨角色跨职能的架构。也有点什么都想做的冲动,所以反而有些事情没做好、没做精。
初悟编程
这一年并没有花多少时间在写代码上面,倒是CodeReview的代码不少,有种跳出“不识庐山真面目,只缘身在此山中”,反而更注重代码的质量、可阅读性、可维护性。之前一直写Java,今年也写了两个月Vue,后面又写了段时间React Native ,有跨语言的对比后,对编程有种得心应手的感觉。
规范
命名即思想,往往是想明白需求后命名会很自然,反过来看着不舒服的命名至少说明可能存在很多问题:
职责不清楚
职责不单一
需求理解不正确
思想或者算法不够简洁直接
规范是其实是用来解决问题的手段,而不是约束。
增加可维护性。不需要额外再做翻译。几个人写出来的代码是一样的。虽然说没有永远是对的,但是总有相对正确的写法。
减少写代码的成本。不用一直在思考重复的内容。
避免一些低级的debug。
提升性能。
有规范的前提下,可以通过自动化的方式来解决重复的劳动。
IDE 的代码片段插件
标准的Demo的场景
代码生成器
JAVA开发规范
推荐
《阿里巴巴Java开发手册》
《重构》
树状编程
很多小伙伴是线性的编程方式,写一个方法,要把所有的细节放在里面。这种方式的弊端
关注点太高。必须知道所有的关注点才能完成这个方法。
回来不断的切换思维
如果改动一个地方,需要从头索引定位
不方便协作
如果把编程方式换成树状。写一个方法,考虑同一个层次的需求点,然后在进一步细化需求点。这里比较难的是怎么判断是同一个层次的抽象。
推荐
《代码整洁之道》
防御式编程
很多小伙伴是线性的编程方式,在正常的逻辑里会有各种特殊情况判断。这种弊端:
在一开始写程序的时候很容易只考虑正常,然后后面随着发现问题,不断的添加各种if处理或者代码,破坏原来的结构。然后就有代码坏味道。
正常的逻辑和异常、特殊的逻辑耦合在一块,思考关注点高。
防御式编程:把所有异常、特殊的情况都处理完,代码最后只考虑正常的逻辑。而且要永远认为程序是不安全的,不要人为的假设是正常的。
推荐
《代码大全》
用自然的语言写代码
一直发现一个很奇怪的问题:很多人会把一个自然的需求,通过自己的加工,然后加上自己理解的算法,最后会很复杂的代码把自己弄晕了。在写复杂算法代码和复杂sql的时候特别明显。
其实需求明确后,用自然的语言转为伪代码,最后的伪代码,只是根据不同的语言特性,纯翻译一下。
进阶Java
以前只停留在会使用Java语法的阶段。后来发现在高性能、高并发或者架构设计上的时候,只是了解语法是力不从心的。
java虚拟机
内存。跟踪内存泄露,调优应用。
类加载。解决类冲突。
字节码。不入侵业务的添加监控。远程调试。
多线程
锁。
线程。
异步。
力荐
《深入理解Java虚拟机》
深入面向对象
面向对象是一种抽象简化问题思想方式。同时它通过经典的特性:封装、继承、多态来解决在面向对象抽象简化过程中常见的问题。
漫淡面向对象——POJO对象
漫淡面向对象——算法|设计模式
漫淡面向对象——抽象问题域分析
提升面向对象的方式,多想!多想!多想!快捷提升的方法
领域驱动设计
UML
设计模式
力荐
《Thinking in UML》
《UML基础、应用和案例》
《领域驱动设计》
《Head First设计模式》
《大话设计模式》
使用面向切面
是一种减少重复代码,减少关注度,降低复杂度的不入侵业务的思想方式。可以让业务更简单、更专注,能够降低复杂度。比如下面的应用场景:
权限判断
数据聚合
数据格式
自定义标签引擎
事务
日志
统计
监控
数据收集等
缓存
这里指的并不是springMVC或者应用级别。指的是整个系统的各个环节或者解决问题的思考方式。如:有的缓存,可能会放在代理的节点再加一中间层。监控可能会放到容器级别通过代理去实现。
推荐
《spirng in action》里对于AOP的描述
《JavaEE互联网轻量级框架整合开发》里面对于AOP的描述
形成架构原则
其实架构本身就是一种思维方式和能力。是对技术规划,选择,以最优的资源真实解决问题,同时又能在扩展和后续的一种平衡之术
推荐
《软件构架设计——程序员向架构师转型必备》
《软件架构师12项修炼》
定位问题
明确要架构的边界和要解决的问题,是架构的第一步也是很重要的一步。
可以从下面4个维护去思考,找到问题。
重复。可以通过封装和自动化或者工具化来解决。
关注高。通过封装和分层,流程和规范约定来解决。
复杂高。通过封装工具和分层和规范约定来解决。
耦合高。通过分层、分步骤和规范约定来解决。
规划
根据解决问题会有多少收益比。节约时间/花费时间:来明确做事的优先级。不要根据技术的好坏和牛逼与否。解决问题才是关键。
合理的拆分,会让后期落地更可控。
水平拆分。分层
垂直拆分。分步骤
迭代的思维。一步到位和每次验证实践步伐太大,都容易造成夭折。
先有再完美。
伤其十指,不如断其一指。
毕竟是商业,生产环境,所以要求稳。
小范围试验。一般来说找用户容忍度高的,商业价值影响相对小的去试验。
做好回退的方案或者备用方案。
设计
设计是为了把风险降到最低,对一些风险高的地方提前准备和集中解决,以免后面落地的时候返工、甚至推翻重做。不是所有的内容都需要设计,这样就是过度设计。
开源
优先使用第三方,尽量不要重复造轮子。直接使用开源的第三方,需要考虑下面的问题。
生态(社区)
先进性
成功案例
活跃性
扩展性
易用性
合理性
优缺点
自研
如果找不到适合的轮子。可以通过下面的方式去思考,分析,分解设计要做的事。
分而治之
分层
分步骤
职责清晰
抽象、建模
设计模式
思想
面向对象
面向切面
面向插件
面向服务
实施
质量
代码质量
软件质量
需求质量
研发
核心代码
算法
关键节点的实现(复杂度高的)
指导
有现成的解决方案
验证
演示是最好的办法。一来能show一下成果,二来群众的眼睛是雪亮的,发现问题的角度更不同。
优化
在解决完问题后。还需要从易用性、扩展性去考虑。
文档化
文档
Demo
易用性
暴露出去需要使用者知道的参数越少越好。
常用的一些场景对应的参数越自然赵好。不要让用户思考太多。
扩展性
在不需要知道太多细节的情况下,更方便的扩展
落地跨职能架构
今年一共落地前端Web(Vue),后台(SpringMVC+mybatis),混合(React Native)以及优化应用架构。每种架构对应的领域技术和需要的能力有所不同。但是架构原则几乎是一样的。具体的后面再补充
前端Web架构(Vue和React,其实抽象上是一致的,细节不太一样)。
混合架构(React Native)。和前端的架构绝大数雷同,只是额外需要考虑和原生交互和移动端原生等问题。
后台架构(Java和Nodejs,涉及到的领域也是一样的,细节和语法、工具、周边不太一样)
应用架构。通过项目管理,版本管理,自动化持续集成等方式把一个产品以更快、最优方式转成互联网可以提供服务的服务。
服务化架构。今年主要对分层职责定义,服务边界定义更明确了,数据聚合和设计,只是通过jar包的方式解决,下一步可以实践使用服务化和微服务相关的技术落地。
优化效率
多一个技能,能节省后面很多的时间,时间质量会越来越高。后面会专门花点时间做些这方面的专题。
办公
typora(markdown)
everything(找文件)
xmind(帮助思考、固化和解决问题的神器)
licecap(制作gif图的神器)
excel (在一些转数据的场景,帮了大忙,有的写sql或者程序要几个小时甚至几天的,用excel几乎几分钟内就完成)
...
客户端
redis-desktop-manager
navicat
SecureCRT
...
IDEA
Intellj idea
webstorm
Vim配置
notepad++
...
开发辅助
jd-gui
fiddler
chorme控制台
beyond compare
...
网站
github:管理知识和资源
百度网盘:管理资源和软件
为知:管理网文
doit:时间管理
worktile|teambition:项目管理
....
了解大数据
是一种分布式计算的解决方案和生态圈。
和传统的数据库的建模和理解是雷同的。
了解了能解决的问题,以及企业对大数据的诉求有哪些。
团队招聘
明确要招过来的人职责是什么,具体工作和定位是什么。然后就是怎么验证他们是否符合这些能力。
开放式问题
封闭的答案往往,不能体现一个人的能力而且容易是背出来的。
了解知道的知识面和关注度
思维是否清晰
是否真实解决过问题。
比如:现在服务一个页面访问是404,其他都是正常的,怎么公定位问题。
有价值的问题
很容易知道关注度还有就是层次。
比如去年最有价值的事,去年做过最难的事。如果面试小伙伴上来说最难的是写统计sql,或者画ui,或者写购物车的交互难等,其实很容易看出来他实际的定位以及处于的阶段。
往下深挖三级
往下继续问三级或者连环问三个以上的问题。不用关心答案是否正确,不用去验证它。特别是在跨职业面试的时候非常好用。也能知道面试者的知识体系和掌握水平。如果最后他的问题通过三级,他的话比较接近自然语言和细节,那就说明掌握得还不错。一般来说,要么有明确的细节,要么有明确的衡量标准。
比如:你怎么预估一个项目?(求职者会说一堆,然后说一个风险系数)继续问,风险系数你怎么确认的,有什么衡量标准?(求职者又说了一堆,然后说考虑团队的稳定性的战斗力)继续问,怎么明确团队的战斗力?
相对多彩的生活
越努力越精彩。滑雪、高尔夫、泡温泉、张北草原、攀岩、承德避暑、键盘控、文具控........有点遗憾的是陪伴家人的时间还是比较少。主要也是因为一些事限制自己,没有明确的目标,时间黑洞比较多,所以只能用加班的方式来完成了。
宏图大业
2017年过后,有种什么感觉呢——尴尬!感觉高不成,低不就,后面反思了一下,还是因为没有很扎实的迈入高端的职业生涯里,所以计划2018年沉下心来,优先攻技术。
另外越来越觉得资源很重要,解决问题的途径并不仅限于自己,能解决问题就是本事,所以想扩大圈子,也想做些自己的事,虽然我也没太想明白要做什么,但是总归还是要开始做些。
有的时候感觉自己的激情越来越少,一回头发现原来是因为生活
实战微服务
搭建环境,熟悉相关的技术栈。
用于生产环境。整理出遇到的问题。
整理系列的知识体系并且固化。
实战大数据
搭建环境,熟悉相关的技术栈。不涉及到具体的大数据的分析算法。
用于生产环境。整理出遇到的问题。
明确大数据,大概能解决什么问题场景。
整理系列的知识体系并且固化。
推荐
一个挺不错的Java架构交流学习群:688583154里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多:
完善应用架构
希望真实的落地到具体的应用和生产环境中,并且完善细节。现在比较尴尬,一说都知道,有的也在用,但是没有做到极致。
技术解决方案
消息队列
全文索引
日志系统
企业解决方案
工作流
权限(数据级别)
经典应用系统
企业后台系统。(系统功能,功能,CMS,工作流,以及一套完善的后台框架)
代码生成器
扩大圈子
越做到后面,越发现如果想自己做事业,就越需要资源。
好友
校友
同事
特定群体(同乡、同行等)
营销自我
一来对自己的知识和成长有一个持续性的积累,减少因为时间的折损。二来增加自己的影响力和资源。三来促进自己知识成体系,摆脱野生程序员的窘境。
博客(网站)
github(知识管理和更新)
平时的积累和总结,系统出视频。
出国旅游
世界这么大,想出去走走。需要更明确的预算和计划
健康身体
减肥。也是今年的一个遗憾,都减下来了,又因为一些事情反弹上去了。主要还是要保持一个良好的心情和合理的饮食和生活习惯。
看病。拒绝安慰自己,有不舒服的都去看看,并且支持把小毛病看怎么处理下。比如原来的牙疼哈。
锻炼身体。一周去二到三次健身房,二周到户外做的有氧运行。
赚钱
今年的目标是能存50W以上的大洋。以便明年能在北京安个家
以上是关于希望每一位2017殚精竭力的“Java程序猿”在2018宏图大业的主要内容,如果未能解决你的问题,请参考以下文章