Java开发工程师职业规划
Java开发工程师职业规划
Ⅰ 前言&个人介绍
走上软件开发这一条路对于我是坎坷的也是不曾设想过的，刚入大一那时我学的是电子商务专业，并且这个专业伴随我整个大专生涯。那时候我预想的是毕业继续深造本专业或是作为一名电商平台运维人员从事电商行业。但是在大一下学期，学校开设了HTML5开发这么一门课，我写下了人生中第一句“hello word”，对于代码所构成的世界我感到异常的神秘与兴奋，加上后续课程的学习，从HTML5到了JavaScript再到JavaSE、JavaWEB、MyBatis、Spring……（这些技能可能对于软件技术专业的同学来说可能不值一提）
到了大二快结束的时候学校发布了两个省级技能竞赛，其一是电商类的数据分析，其二是计算机类的Python程序设计。对于当时本专业小有“成就”的我自然是选择挑战自我，果断选择了后者。
在大三集训时，我们专业开始了校招，当身边的朋友一个个陆陆续续都拿到了offer，宿舍也是剩下我一个人的时候，我时刻在想要不要继续下去，途中也跟老师反映过退出的想法，不过最后还是坚持下来了（劝回来的），并且出乎意料的拿到了一等奖。
因为错过了学校的校招，当第二年三月份社招面试时，第一次经历了社会的毒打，许多的技术都是我未曾听说过的，好不容易拿到了一家Java公司的offer因为种种原因又不太合适，就拒绝了入职。最后只找了一家非开发公司。到了四月份各大高校开始了免试生的面试，于是就重返了校园，从电子商务专业跳到了软件工程专业。（跨度是不是很大）
Ⅱ 学校阶段学习路线规划
1）技术路线图
图片来自：https://cloud.tencent.com/developer/article/1826717 腾讯云开发者社区@Guide哥
2）在校计划
-
大三上学期：
- 学完springboot+Vue+Linux+Redis+复习HTML5响应式和进阶部分
- 学完如上技术后，完成一个个人项目
- 准备软件设计师中级
-
大三下学期：
- 回归底层，继续深入学习Java，最好能学习JVM、数据结构、Java并发、设计模式（这些在短时间内也只能学到皮毛）
- 学习中间件技术，微服务，分布式（重点倾向学习）
-
日常计划：
背单词，尽量利用时间学高数
往往说到和做到是两回事，只有通过不断的鞭策自己才能学到新的东西！
3）课程学习
- UML：学习该课程后，希望能掌握UML的基本概念模型，能够熟练使用UML建模工具，理解UML的多种图，例如用例图、类图、顺序图、通信图、状态图、活动图、组件图、部署图等。
- 计算机操作系统&计算机网络：该课程理论性较强，知识点巨多，许多知识点与软考重合，需要花时间进行梳理。
- Oracle&JavaWeb：实操性较强，书中的案例需要实践才能掌握的更深刻，希望学完之后能就够整合这两者，做出一个小项目。
总结：不学就得挂科，总之都得学，还需要付出更多的时间与精力。准备在以后的课堂之余，要拿出至少两个小时的时间进行整理当天学过的课程内容。（比电子商务难多了）
Ⅲ 个人感受
现在的开发已经不像十几年前以前一样“纯粹”，从以前的mybatis逆向工程到现在的代码生成器或是开源项目（如若依），更或者是低代码平台，这些方式方便了程序员的开发，极大的提高了开发效率。但总是用别人开发好的库和二开项目，难免会对自己的工作产生怀疑。如果不去钻研“为什么”而是一直在重复造“轮子”难免会遇到程序员危机。
到底来还是需要底层的理论作为支撑，以前的学习只重实践，渴望看到效果。当学完新的就忘了旧的，现在还只停留在很表面的一层，只知其然不知其所以然。在Java这一条路上，还有很长的一段路要走。
路漫漫兮其修远兮，吾将上下而求索！
Ⅳ 提问和反馈
-
当第一次听到UML这个单词时，我想到的只有两个词：“画图、统一建模语言”？对于UML的认识只有一个及其抽象的概念，那么UML究竟是图还是语言？能干什么？
解答：UML是统一建模语言，这句话太官方了似乎还是不好理解，换一种说法就是UML是一种图形化的语言，用图说话的语言。我们学的很多计算机语言是用代码来写的，UML的不同之处就在于它是用图形来表示的。当一个复杂的系统用文字表达不清楚的时候，UML图的作用就凸现出来了。就像建造一幢高楼一样，最重要的是先要有一张蓝图，有一个模型，然后再去准备各种必需品。UML对于软件开发来说，正是蓝图式的存在。
-
教材p7面向对象方法的概念提到了泛化，实现泛化关系的机制为继承。那么继承与泛化有何关系呢？
解答：书上的解释是：泛化(generalization)是类元的一般描述和具体描述之间的关系，具体描述建立在一般描述的基础之上，并对其进行了扩展。我的理解是
继承关系，继承关系是泛化关系的反关系，也就是说子类是从父类继承的，而父类则是子类的泛化 -
UML扩展机制的构造型的作用是什么
解答：用来扩展建模元素，增加建模元素的语义，或者将已有的元素模型进行修改或精化，创造出一种新的模型元素。比如如果你觉得类和类之间的关联关系太普通，想表示几种特殊的关联关系，可以用构造型定义你的特殊关联关系。
-
4+1架构的组成，以及各部分功能
解答：4+1视图分别为：场景视图、逻辑视图、物理视图、进程视图和开发视图。
-
逻辑视图
- 对系统进行面向对象的分解
- 面向终端用户
- 建模软件的功能组件（类、包等）以及功能组件之间的关系
- 解决功能关注点
-
开发视图
- 对系统进行子系统分解
- 面向开发者/项目经理/产品经理
- 建模开发组件（模块、子系统等）以及它们之间的关系
- 解决软件的组织、重用、可移植性等关注点
-
物理视图（部署视图）
- 映射软件组件到硬件节点
- 面向系统设计师/部署工程师
- 建模系统部署的硬件节点（服务器、路由器等）以及它们之间的关系
- 解决可伸缩性、性能、可用性等关注点
-
进程视图
- 对系统进行进程分解
- 面向系统设计师/集成工程师
- 建模任务组件（进程和线程）以及它们之间的关系
- 解决性能、可用性、容错性，数据完整性等关注点
-
场景视图（用例视图）
- 将一切集成到一起
- 遴选在架构方面有重要意义的少数用例
- 穿越所有的视图和层，调用所有的软件基础设施
- 作为架构可用性的证明
- 作为其余用例开发的示例
总结
视图 逻辑 进程 开发 物理 场景 组件 类（Class） 任务（Task） 模块，子系统 硬件节点（Node） 步骤，脚本 连接器 关联、继承、聚合等 消息传递、广播、RPC等 编译依赖，with子句，包含关系 通信媒介、LAN、WAN、总线等等 容器 包 进程 子系统（类库） 物理子系统 Web 涉众 终端用户 系统设计师，集成工程师 开发者，项目经理，产品经理 系统设计师 终端用户，开发者 关注点 功能 性能、可用性、容错性，数据完整性 组织、重用、可移植性、产品线 可伸缩性、性能、可用性 可理解性
参考文章：https://git.yyang.io/about_architecture/definition/4-plus-1-views.html
-
-
UML为什么要使用面向对象方法
解答：
- 从认知学的角度来看，面向对象的方法符合人们对客观世界的认识规律。
- 面向对象方法开发的软件系统易于维护，其体系结构易于理解、扩充和修改。
- 面向对象方法中的继承机制有力支持软件的复用。