※ 引述《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，想使用新知识。但到了休假日，也很少真的着手进行。 : 总之我现在稍微有点迷惘，对於程式这条路我觉得我才刚起步，也不想离开。但学海无涯，光上面就太多东西要学。 : 根据我自己的感觉，只知道自己暂时还不太想钻研前端。而对於我上面提到的各种知识，能怎麽安排、规划比较好？谢谢大家。 : ----- : Sent from JPTT on my Sony G8142. --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 59.115.104.120 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1559443379.A.17E.html ※ 编辑: qrtt1 (59.115.104.120), 06/02/2019 10:52:32 (fixed) 你是对的，因为我举的例子，跟想说的概念不太一致 XD 原本想到的是另一件事，但忘了写了。 先前有个程式要算 n-gram 的词条，做一些自然语言的分析。它复杂度挺大的。 虽然 n*m 不是一样的数，但文章数越多，时间越久。差不多能视为 N^2 的复杂度了。 拿着目前有的单台机器时间去估计，跟同事讲干话： 「我算了一下，以目前的文章产生出来的候选词， 在这台小主机，差不多要跑 1 万年吧」 「那麽，我们会遇到 10 个桥本环奈呐！！！ (不自觉地兴奋了起来)」 不过，看看实际上要计划的东西，是要在相近分数的 tf-idf 中做出排序。 没需要真的去做 O(N^2) 的东西。当时间不够找到替代方案时，我们有另一个选择。 把 N 缩小 => 分组做。 改了一下写法，送上 AWS EMR 先把很大的 N 分割成小组，再跑杯具的 O(N^2)。 还是花了 3 个多小时才跑完。 谢谢 @GinginDenSha 挑出问题，让我回想起原本要写的东西xd ※ 编辑: qrtt1 (36.231.142.167 台湾), 06/03/2019 10:34:02 ※ 编辑: qrtt1 (36.231.142.167 台湾), 06/03/2019 10:37:25 ※ 编辑: qrtt1 (36.231.142.167 台湾), 06/03/2019 10:38:57 ※ 编辑: qrtt1 (36.231.142.167 台湾), 06/03/2019 10:39:29 『千年一遇的美少女』xd ※ 编辑: qrtt1 (36.231.145.9 台湾), 06/12/2019 12:13:17