※ 引述《csjs87 (思念的季节)》之铭言：
: 各位年薪三百万的大神们好，小弟不才又上来请益了。一年前为了选择资策会的课程在版上发了问，有幸获得许多人的回复。
: 从资策会毕业、顺利找到工作也一阵子了，现在月薪37k，主要是协助开发后端。但我碰到一些对于自己不足的地方，想再次请教各位。
恭禧转职成功 :D
: 一、
: 因为公司没有一套完整的教育训练或是架构的教学，所以即使我有尝试在我负责做的小工具、api中尽量使用"我认为的oop观念"、"solid的开发原则"。但还是不晓得是否正确，同事们大多也都很资浅，加上没有太多时间帮我看（专案忙）。我要怎么检视自己的code是良好、容易维护的呢？
大部分都是如此，但不用灰心。因为，过去接受训练的型式，
常让我们以为有替一些人排好课表、找几个固定的主讲人，
拿着讲义坐下来好好听课才算是教学或者训练。
有些公司比较有机会做到这种典型的课程式教育训练，
即使公司的大小有关系，但主要还是公司主要用到的技术的范围
这些范围内的东西，依产业或职位不同，变化的速度也不同。
若是没几个月就变了一轮，那么做个制式的训练教材就是不划算的事了
若东西一直没变，那就可能是所以 tech stack 都锁定了
像一些会被严格稽核的金融系统会有这样的特性。
(举金融为例，不代表它全都如此，金融也是一直导入新技术的。)
多数的公司在这二个极端之间，
所以特别准备通用的教育训练就不那么容易了。
在没有固定模式的训练材料，大致会怎么训练人呢？
大多是以处理 issue 跟参与 pair programming 为主。
issue 以特定 bug 并明确是 reproducible 为佳，
因为只要学会如何启动系统，能开 debugger 来看问题为主
(或是硬加 log message 来用)
(或运气好，已有 unit test 基础建设)
在 trace 的过程中，你可以渐渐理解正在开发、维运的东西怎么工作的
若是公司没有教材，你就有机会成为生出教材的那个人
像是你可以用 sequence diagram 来表达从启动到结束需要经过哪些
大小元件或 method call。你可以有不同粒度的版本。
或是 component diagram 来表达几个大元件的依存关系。
做好后，拿着它与其他同事解说，请他们给你 feedback
你可以观察并意识到，自己哪些部分理解了，哪些部分误解了。
而误解的原因是单纯看错了，还是缺乏了某个基础知识，
或是过去人为决定的设计，让你无法以目前的直觉适当地理解它。
这样互动并修正自我认知的流程才是真正的学习。
由其他的的回馈，你可以知道自己说出来的东西，是否跟别人的理解相同了。
这样渐渐你可以内化这些知识，成为理解你工作领域的人。
: 二、
: 偶尔会看版上或是104征才需要什么样的能力，为将来不管跳槽或是谈薪水更有筹码。我印象中常看到的有云端架设相关（aws、azure）、程式设计上（单元测试、graph api）、其他（CI/CD、Docker容器、TDD）。虽然都有查过也大致知道是什么，但也仅此而已，更不晓得知识还很浅薄的我有没有误会什么。
这些都是好东西，但你得有基础概念辅助才行。
基础概念包含‘三’的部分，但远比‘三’本身更多，因为所列的这些工具
还包含了方法论、哲学观与工作文化的转变，如果你没有吸收到相关 mindset
那你只是单纯学习了新的工具而已。
你其实该在意的是，如果我会 OOO，那么在 XXX 的时机适不适合。
在工作流程中，引入了 OOO 后，对于所处的工作环境是否有好的影响
基于 XXX 的概念准则，为什么 YYY 是个好/坏主意。
其实蛮多社群都有相关的 talk，或上 youtube 找相关影片看。
多跟人互动，理解他们为什么选择，站在什么样的视角去做选择
比单纯像集点一样，把工具集一轮有用得多了。
: 三、
: 最后是一些比较底层的资料结构、计算机概论这类都几乎是0知识。虽然计概有自己看台大开放课程的计算机概论，是多少有学到一些，但又好像不是我现在急迫必要的知识。听说资工有本圣经恐龙本，看过目录发现，很多都是我常常看到的陌生词汇。I/O、thread、Process等等，我觉得好像不看懂这些我就很难更精进。
OS 部分，其实没有离这么远。但是直接看教科书挺硬的。
至少 process 与 thread 对应到你使用的语言、工具时相关问题要理解。
像是怎么处理 race condition 的问题
(其实第 0 步是，培养识别 race conditon 的眼光)
在没学习之前，应该要有的敏感度是：
‘这程式，有时候会对，有时候有不对。没什么特别的规律’
那么对应到语言的层次，大部是使用 thread 后出了问题。
你会开始在意到你的资料是否得在 mutlithread 下共用，
开始关心 library 有没有标示 thread-safe。
再进一步，怎么写出 thread-safe 的共用元件，
(像是多数支援 multithread 的语言都有的 volatile 关键字)
(它影响者你 shared variable 的 visibility)
或是走向 immutable object 与 functional programming
等避免状态改变造成的困扰。
另外，资料结构算 Big-O 不会算没关系，大多的复杂度都查得到。
(至少写了几层 loop 这种 N*M 要看得出来)
它是用来协助我们处理选择障碍与实作优化的帮手。
像是你要在一堆资料中，找 1 个东西存不存在，并取得对应的值：
在 List 与 Set 中选择，你对照一下时间复杂度，应该是内心有谱的。
像有些给入行工程师的考题，都喜欢考你某 2 个容器的实作，
为什么选 A 而不选 B，若题目改成 ..... 那么选 B 就是比 A 更好
这也是为什么资料结构能处理许多选择障碍的问题
另一种情境是优化，你手上有个已经实作的好成品，它是用某个资料结构
你要试着去安排你的资料，以发挥这个资料结构的特性，获得较好的结果。
(这是常见的数据库的 indexing 的问题了，
如果某些大大有开课的话，快去抢票先)
: 其实我本身不是“非常”热爱写程式的人，我会在写code的时候为解出bug感到开心，也会边骑车边想程式的事，看到好像很神奇的新技术新闻也会很兴奋，也想做side project，想使用新知识。但到了休假日，也很少真的着手进行。
: 总之我现在稍微有点迷惘，对于程式这条路我觉得我才刚起步，也不想离开。但学海无涯，光上面就太多东西要学。
: 根据我自己的感觉，只知道自己暂时还不太想钻研前端。而对于我上面提到的各种知识，能怎么安排、规划比较好？谢谢大家。
: