[推坑] 波麗斯科技 PPolis

看板Soft_Job作者qrtt1 (有些事，有時候。。。)時間9年前 (2014/12/30 00:47)推噓7(7推 0噓 1→)

留言8則, 8人參與討論串1/1

＠公司名稱：（請盡量寫正確的全名）波麗斯科技 (應該已經不在囉，只是寫寫菜鳥時的回憶) ＠工作地點：（約略就好～）最初在師大附近，後來搬到萬芳社區，輾轉又移過地方，現在只在我的回憶裡。＠工時狀況：(不計標點符號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://www.ptt.cc/bbs/Soft_Job/M.1419871653.A.224.html ※ 編輯: qrtt1 (36.231.134.161), 12/30/2014 00:49:18

推

Expsun

12/30 06:28, , 1^F

12/30 06:28, 1^F

※ 編輯: qrtt1 (36.231.134.161), 12/30/2014 08:31:19

推

ntddt

12/30 08:30, , 2^F

12/30 08:30, 2^F

推

userid

12/30 13:37, , 3^F