＠公司名称：（请尽量写正确的全名） 波丽斯科技 (应该已经不在罗，只是写写菜鸟时的回忆) ＠工作地点：（约略就好～） 最初在师大附近，後来搬到万芳社区， 辗转又移过地方，现在只在我的回忆里。 ＠工时状况：(不计标点符号100字+) 这是间 Web 2.0 时代的 startup 公司。 （伴随着胜投拿不完的王建民与我的菜鸟工程师回忆） 早上 10 点到晚上 7 点，没什麽加班的记忆。 这主要是配合师大附近午餐人潮过多，避免浪费时间等待而做的选择。 单纯就工作时间比正常工时晚一小时，没有 loading 太重的情况， 任务分配的大小适中，通常一二个工作天都能完工。 feature 的规划都有资深架构师与创办人讨论为主， 也会询问在场开发者的意见。 只要决定後 mockup 图与 feature 说明不久就会出现在 mantis 上， 接到 issue 後，只要针对不理解的部分去提出， 或是询问施作细节，该如何做比较适当。 由於需求明确，专业结构清晰，几乎不会发生停滞的状态。 若是停滞，那多半是没有 idea 或是有些 feature 还在犹豫该如何规划。 基於这些先天的优良条件，回想起来， 在开发上实在没有长期持续性的加班的经验。 ＠工作内容：(不计标点符号100字+) 开发 Web Application。 最初的工作被分派到 business logic 的部分， 也就是除了「有画面的东西」之外，为我主要负担的部分。 专案是使用 appfuse generator 产生的， 那时使用的是 Spring + WebWork + Hibernate 使用 Ant Build Tool。 专案简单来说分为（记忆中的）： Web UI ---------------------+--------------------- Manager/Service | ---------------------+ DAO | Unit Test ---------------------+ Utils | -------------------------------------------- Ant 的编译顺序是由下而上： 1. Utils 2. DAO 3. Manager/Service 4. 不编 Unit Test（记忆中，没有 CI 但会用 IDE 跑过全部测试） 这样做可以使相依关系被 Build Tool 硬性规定， 所以 DAO 能用 Utils 的类别，Utils 无法使用 DAO 的类别 Manager/Service 能使用 DAO, Utils 的类别， 同理，DAO Utils 无法使用 Manager/Service 的类别。 所以，程式码有没有放错 source folder 只要一 build 就会知道。 Unit Test 使用 JUnit 3.x + JMock/EasyMock + Spring 提供给 DAO 或 JDBC 相关的 TestCase Helper。 前端虽然使用 WebWork 但没有搭 FreeMarker， 是使用单纯的 JSP/JSTL/EL 与客制的 groovyTag， jQuery 忘了是几版的，总之 2009 年代的版本就是了。 开发的工作基本上就依 issue 的内容来走罗。大致各为： 1. 修 Business Logic 的 Bug 2. 实作新 feature 3. 修、调整 Web UI 刚进去时，被按排做 [1.] 比较多。因为内容比较单纯， 只需要先弄懂 manager/service 跟 dao 的范围就行了。 也能就近直接观看主要的逻辑是怎麽做出来的， 然後开始学习 debugger 怎麽使用。 是的，你没有看错，我连 debugger 要怎麽弄还不会， 但有着厚脸皮，跟看几次就懂的血轮眼（只是单纯熬夜看日剧有血丝吧！？） 会用 debugger 再来是设 breakpoint 的品味怎麽培养了， 基本上靠二分搜寻的策略，往中间夹挤出 bug 的发源地。 能正常地使用身为开发者都该会用的 debugger 後，就能顺利地解决 bug。 搞定後得将程式码 commit 至 svn 内， 并回 issue 内填上 svn:rxxxx 的版号。 同事有改 mantis 能直接 link 到 svn web 上去， 记得把 issue 由自己转给 reviewer 并标解决。 （然後，看看左邻右舍有没有要一起上 dev server 的，没有就自己先上去了） reviewer 看完并试过正确後，跟他想起一样， 或是跟 feature 动起来一样那就会被标为 close。 （close 後就能在下次 release 时上 product server） （关於 svn，每早架构师都会一般吃早餐， 一边 code review，如果有人写不好会被碎碎念攻击xd） 渐渐由解 Bug 熟悉部分的开发流程後， 与让同事了解目前的程度在哪後，就开机有机会接触 [2.] 的工作。 全新的 feature 可能会需要新的 Manager/Service， 或要开新的 db table 与对应的 DAO， 或是结合旧由的 Manager/Service 与 DAO 来做些什麽， 於是同事就教导我使用 appfuse 提供的 ant task 产生一组出新的 class， 会有一整套的 Manager/Service 到 DAO 还有页面， 得再手动把不需要的删除 :) 最初以开发 business logic 为主， 大致只会留下 Manager/Service 与 test case。 如果有新的资料要存那还要开 table 与建立 ORM 使用的 bean， 当然不是建完就没事了，还有 spring 与 xwork 的 xml 设定档要调整， 让它们认得新的 class 与 action。 全新的功能开发引发了另一件事，那时我使用的是 gigabyte 的白牌NB， 由於财力有限只插到 2GB RAM，用它来写写文件，开发小程式算够用， 只是使用它来开发 Java Web 很吃力。若是启动完整的 Web Application， 点过几个功能就会让 Eclipse 崩溃自杀了。 老板有问我需不需要贴我钱买新 NB 或是他出钱买新 NB， 我是比较习惯使用自己的电脑。於是就婉拒，等到领薪水再进行采购。 但中间的过渡期能要工作啊！ 由於启动 Web Application 测试过多的功能会让 IDE Crash， 要嘛就算选测试时不开 IDE，单纯开 Web Application。 不然就是不要测太多功能，或是将 Tomcat 换成比较不吃资源的 Jetty， 至少能运用到 debugger。 不管哪一种选择都是没效率的开发方式， 於是资深的架构师就帮我想了个方法！提早教我撰写 unit test， 大约经过几次的 pair programming 大致能掌握内容。 DAO 的测试就靠 Spring 的 Helper Class， Manager/Service 的测试就靠 mock library 做， 还有些有的没的小技巧，都是哪时学到的， 像是透过昵称类别覆写掉不是测试焦点的 method 这类的方法。 随着人员变动（startup 的成员变化是快了点），後来剩下我与创办人。 有一段时间我是一个人在工作的，就上面看的再加上 Web UI （虽然我对 UI 没 fu，但只要能做到跟 issue 里画的一样就行罗） 由於我是个蛮规律的人，除了没人可以聊天之外， （每天都能有解 issue 的进度^^） 就靠着刚开始进来的那些训练，支持着我後续的开发工作。 在「唯一的开发者」时期，是搬到万芳社区後的事了。 因为公司获得赞助 Dell Server 一台，於是得想办法在上面灌起系统 （我忘了是用 Debian 还是 Ubuntu Server） 得弄好 apache + mod_jk + tomcat， 然後得再接通 IP 分享器与另一台的 SQL Server 连线。 （忘了发生什麽事，总之，我有二台都重灌过，应该是为了换 Server） 後期比较累，主要是精神压力，因为除了写 code 还要当 server admin。 （然後，因为对 SQL Server 无知，transaction log 满了， 只好再想办法搞定） ＠工作环境：(不计标点符号100字+) 万芳社区很清悠，不过我常一个人在公司。 中午吃饭时会经过个小公园， 有时觉得自己像拉普达里的机器人，就只是这样的感觉而已。 ＠主管人好不好：(不计标点符号100字+) 大致上算不错噜。其实每个都算是主管 ^^ 这得回溯到我为什麽在这工作。进来前是想找份兼差多一份收入， 因为其他时间在替某教育训练基构写教材， 由於出社会前二年比较穷，想要试着让月收入达七万。 加上单纯写教材有点单调，虽然有钱赚但得写完过一阵子才能拿到钱， 於是再找个写 code 的工作，毕竟最终还是喜欢写 code 的。 於是在 CodeJob 版上看到有人在徵驻点，於是就带着履历去聊天了。 大致谈完知道，确定工作内容是写 Java，有 35K 的月薪。 只有客户需要时才需驻点支援，其他时间就再约讨论或是在家工作， 於是就接受了。 一段时间後，驻点的专案提早终止，那麽我就派入 PPolis 工作， 里面有驻点公司的老板、资深架构师、创办人与我。 对我来说，他们都是主管，分别有他们的身上获得许多不同的经验与技术。 当然，至今为止，我始终认为这段「基础建设」的过程， 对我後来的成长有着很大的影响。 身为开发者，受影响最深的当然是架构师了，这甚至影响了我的思考模式。 对菜鸟来说，看到 Bug 就是没想太多立马扑杀它，只要结果对就行了。 但他常自言自语地在位置上，把他自己的思考过程念出来， 我偶尔也不自觉地跟着他一起想同样的问题，渐渐地也习惯了相似的思考模式。 首先是「问题的定义」是什麽，为什麽这个现象被称为 Bug？ 这肯定得由功能的 feature 来看起，它不符合什麽条件， 而这条件在我们的设计中应当符合 那麽就是有些地方让这个条件产生了变化， 得找出导致改变的源头，也就是 root cause，而非眼前的现象。 另外，像是刚开始放手给我做时， 有个需求是要将 mail 寄送改成先放到 db， 以 db 为 queue 会有其他的程式稳定少量的发送。 我的工作就是修改原先寄送 mail 的 class，让它不要直接发出去， 而是将发出去的动作，写到 db 取代原先的发送。 於是我写了个全新的 MailSender class 与 DAO 来做这件事， 後来经过 review 实作上大致没有问题， 只是原先与旧 MailSender 相依的部分都被换成了新的实作。 二个版本的 MailSender 像在平行世界。 於是他用 Eclipse 的 refactoring 功能， 将原先的 MailSender 抽出抽象的父类别， 让 2 个 MailSender 都有共通的外显行为， 稍为调整只是单纯替换调 Spring 注册的 class 就行了， 相依这个 MailSender 的部分就不需要随着变动了， 因为其他部分就是认父类别而己。 （心理想，原来这就是多型啊！书上怎麽写都没感觉， 看人用一次就完全明白了） 这只是我「第一份写 code 的工作」， 但却误打误撞走进了可以无限提昇等级的落凤坡。 ＠相关连结：（选填） 由於服务已经不在，也没有营运的迹象， 只好由 Mr. 6 的 link 与 twitter 回味一下了 http://mr6.cc/?p=711 http://plurk.com/p/s6oiv ＠如果给一到五颗星，你给几颗？ (*****) 哥推的不是坑，是回忆。就当它是颗流星，一闪即逝呗（菸 (注：如果要批评请就事论事，请勿出现人身攻击。） --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.231.134.161 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1419871653.A.224.html ※ 编辑: qrtt1 (36.231.134.161), 12/30/2014 00:49:18 ※ 编辑: qrtt1 (36.231.134.161), 12/30/2014 08:31:19