※ 引述《ponyufang (yufang)》之铭言： : 我是从设计转前端工程师，原本只会切版。 : 最近转职後遇到的瓶颈，不是在写程式本身，而是对很多程式以外的东西不了解。 : 比如说node.js、git等等，刚进公司是同事帮忙架环境，我只能看着他操作，却不懂意思 : 。 : 爬了一些文章，才好不容易知道要怎麽使用终端机，还有学会git 指令，但觉得自己还是 : 一知半解，好像没有真的了解原理。 : 我回到家想用自己的电脑操作看看，但是一直不成功。 : 想装node.js，查了文章之後又看到homebrew、npm等等的，照着步骤做又会有问题，觉得 : 主要还是不懂这些东西在干嘛。 : 不知道是不是自己对很多电脑的基本概念不懂，我自己本身周遭没有相关背景的朋友可以 : 询问，公司的同事都是资管、资工背景出身，有时候询问他们问题，都无法得到明确的答 : 案，他们无法理解我为什麽不懂这些，所以都只会回答就是这样、就是那样。 : 我觉得很困惑，不知道有没有朋友跟我有过一样的经历，可以给我一点指引。 : 是不是要从哪里着手去把基础的东西学起来？ : 可能这样问会被骂，但希望有人可以给一点意见。 当初 javascript 这个程式语言开发出来是为了可以在浏览器下完成一些工作 node.js 就是让你可以在浏览器之外还可以执行 javascript 程式码的一种环境 npm 则是 node.js 内建的一个工具软体 你应该有软体常常在更新的概念，前阵子你安装一个软体来用，过了一个月这软体出了 新版的，结果你更新成新版之後使用上出了很多问题，你就想说那不如移除之後装旧版 的来用，於是你就到作业系统提供的管理已安装软体的介面移除该软体，再去下载旧版 的来安装 以上就是手工的作法，而 npm 则是让你可以透过下指令让电脑帮你完成同样的事情， 更好的是你可以编辑 package.json 档案来让 npm 完成更多其他的工作，不过 npm 管理的软体只限於能在 node.js 环境下执行的软体 homebrew 也是类似的功能，不过专门用来管理执行於 Mac 中的软体 而 git 则是版本控制软体 以前若你想备份一个档案是怎麽做的？ 复制起来存到某个资料夹，对吧？ 若这个档案会随着时间被人编辑而一直增加内容，而你又想保存旧版本的内容，好让 你可以在某个时间点能够再从这个旧版本重新开始，是不是开始每次存档时就另存新档 ，并对档名加上一些可以辨识版本的资讯？ 上面描述的就是很手工的版本控制方式，而各种版本控制软体就是为了同样的目的， 但却可以透过下指令让电脑来帮你完成同样的工作，效果还更好 在你还不熟并试着安装这些工具来使用时，记得把你做过的事情，遇到的错误讯息， 一步一步记录下来，当你卡住时，这些记录下来的资讯可以帮助别人快速判断问题出在 哪里，而且日後你若忘记了也能重新照着这些步骤来做 在你开始写程式之後，会发现常常要安装一堆工具软体，这些都是为了帮助程式设计师 可以更快速、更正确地开发软体 例如未来你可能会需要写测试，所以需要安装一些测试框架，像 jest 或 jasmine 可能会需要流程自动化，所以需要安装 gulp 或 grunt 或其他的软体 可能会需要统一程式码风格，所以需要安装 eslint 之类的软体 可能会需要更进一步的整合所有流程，所以需要安装 jenkins 之类的软体 会不断重复做的事情，就交给电脑帮我们做，这就是安装这些工具软体想达成的目的 -- 「看在上帝的份上，我们不能当着孩子的面枪杀他的父亲！」 「那我们就连孩子一起干掉！」 「第一枪打中的是那个天真的孩子，第二枪是抱着孩子的母亲。第三枪 停顿了三秒，当难以致信的父亲擦拭着脸上爱子的脑浆从震惊中醒转 过来，慢慢的转头看向停车的地方，分辨出是谁在攻击他後，第三颗 子弹才将他的脑壳打飞。」 ─摘自〈狼群〉 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 122.121.179.216 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Web_Design/M.1524927299.A.953.html 测试框架我也还在摸索中，jenkins 没实际使用经验，只有看别人文章後的一些理解 以下仅供参考 测试自己写出来的函式，也就是想知道呼叫这个函式之後，产生的结果是否正确 例如你的函式接收一个引数之後会回传一个二维阵列，你想知道回传的二维阵列的值 是否跟你预期的一样，所以你就直接呼叫此函式，并传入一个值当引数，然後设定另一 个变数存放你预期的结果，接着拿预期值来跟回传值做比较 若是不靠测试框架，就要另外撰写程式码来逐一比较两个二维阵列的值是否都相等 有了测试框架，只需要一行程式码就能完成这种多层阵列或物件的比较 更进一步的，有时只想知道某个函式是否有被呼叫，或是被呼叫了几次，或是传入的引 数数量与内容是否如同预期，测试框架都有提供相关的语法 一个软体的完整开发过程，不只有编写程式码而已 写完或改完一个功能之後要测试，测试完要把这功能整合进完整的产品之前，还需要检 查程式码风格是否一致，若不一致就不让你提交(commit)，更严格一点的还要先经过同 事的审查才让你提交 成功提交之後又要重跑一次整个产品的整合测试与各种单元测试，都没问题之後，接着 把产品部署到有可能的使用者使用环境，像是各种行动装置或桌上型电脑，各种浏览器 版本、各种作业系统版本等等 每种装置或平台要能正常使用产品，都有各自的前提，把这些前提都满足了才能正常执 行，之前有看过票选工程师最爱讲的话第一名：「在我的电脑上可以正常执行阿」 当产品需要部署到这麽多不同装置或平台时，若要确保每次部署都不会出问题，最好能 自动化，并自动回报是否出问题了 开发->测试->部署，每做一点修改，就重跑一次这个流程，这就是 jenkins 要做的 实际上提供了更多的功能，像是提供测试覆盖率的精美报表，也就是实际上会执行的 程式码有哪些被测试程式验证过了，有哪些还没 每当改完一个功能，就验证一次，这样可以在出错时快速判断出是哪边可能有问题 这就是为什麽要写测试，即使测试无法把所有可能的错误抓出来，但绝对能降低花在 除错上的时间，而且测试最好都要能自我回报，也就是不需要用肉眼去比对结果是否 正确，而是在出错时主动告知在哪个地方发生错误了 前面提的测试覆盖率达到百分之百也不代表就没问题了，但不足百分百的意义是还有 哪些不足之处可以加强 程式设计师花在开发功能的时间跟除错的时间，通常都是除错的时间占多数，当产品 越来越庞大，若没有足够的验证机制，每次花在除错上的时间只会越来越长 更进一步的还有 docker，也就是每个装置或平台的执行环境用容器包起来，然後测试 跟部署流程就在容器里面执行，每次开发完就启动所有容器，每个容器内可能就从安装 相关的作业系统、产品测试与正常执行的必要前提，安装完之後接着执行测试与部署流 程，最後回报结果。有时则是从已经准备好各种前提的容器开始运作 docker 比虚拟机器好的地方在可以执行的数量多上很多 ※ 编辑: art1 (122.121.179.216), 04/29/2018 07:12:24