看板 Soft_Job 關於我們 聯絡資訊
比較詳細地再說一回我的情況, 先說最後結果 我最後看到的成果是, 我離開前四週, 開始看到 SD 的螢幕畫面上在看我的教學, 以及相關的 references, (主要是良葛格和官方文件), 我離開前兩週的一次會議, SA 開始願意以 物件 的角度做思考, 不再只是永遠的 模組...模組... 這很難說是有或沒有成功, 或者有沒有打動人, 只是我看到的一些改變而已, 接著說一些可能有助益的...credit? 我將查詢時間減少為原本的 1/3, 將記憶體的消耗減少為原本的 1/8, 解了一個 memory leak, 一個循環狀態造成的系統掛點, 不過最主要的是, 我讓他們看到, 以我的方法做事, 我總是能以他們認為的時程 一半以下 的時間完成工作, 打個比方, 某次開會講某個功能的對話: ========================== SA: 這個一天可以嗎? SD: 唉呀他超快啦, 應該兩個小時就夠了 me: 大概...一二十分鐘吧 SA: 怎麼可能, 要改這改那...不可能啦 (笑 ========================== 這是發生在我重構得差不多時的事, 現成的幾個物件串一串, 開完會後半小時, 我 commit 了程式並寄出了測試報告 ( 聽說我半年新做的部份, 相當於他們過去所有東西的份量 ) 也以一些實際例子, 讓他們看到我所用的一些技術或工具, 能如何實際地為自己省工省時 ( 只是很簡單的 Ant, JAXB, JSTL 而已 ) 再說過程 其實一開始身為新人, 我並沒有什麼想法, 是照舊程式學著寫的, 大概長這樣 ModelAndView(req, res){ 從 req 拿參數 撈DB 處理邏輯 回傳頁面及資料物件 } 一個方法打死 頁面則是 <% 拿物件 繼續跑邏輯 %> ...做一些輸出... <% 再跑邏輯 %> ...又做一些輸出... 沒錯, 後端的邏輯其實只跑不到半套, 前面繼續跑 我沒有任何疑議地這樣寫了兩個月, 雖然我也知道有分層, 更清楚的做法, (用過 JSF, Struts + JSTL/EL) 但當時我只當作, 是用的工具不一樣, (Spring MVC) 這種架構下應該就是要這麼做 漸漸地開發重心轉到了我的身上, 我被 assign 了所有的新功能, 同時要解舊有的 bugs, 慢慢的我摸熟了當時的框架, 上網看了許多資料, 主要幾個是 猴子靈藥, 克明的鮮思維, 良葛格的 JSP JSTL 設計模式, Spring 我開始發現根本不是工具的因素, 而是真的很多東西實際上在亂做, 發現過去可能沒有人把記憶體資訊拿來看過, 或者明明用 MySQL, hibernate設定檔的 dialect 卻掛 MSSQL, ( X, 難怪有些指令會出錯, 又找不到原因 ) 再加上我上頭 PM 請其他兩位前輩做的 SA, SD, 幾乎生不出什麼東西, 例如使用者登入, - 要檢查權限 - 加上防 bot 驗證碼 這是一個功能, 經過上面的 SA SD 之後送到我手上的東西, 我看不出那和 user 直接開的需求有什麼不同, 甚至 user 開的搞不好會更詳細 於是很自然地, 整個專案掌握在我手上, 即使我不這麼希望, 我希望 SA 能想好流程, 我希望 SD 能訂好架構, 我還希望我寫完 SA 可以測測, 給一些 feed back, 但是實際上, 我得自己想好流程, 有必要的話得畫流程圖向 SA 講解, 給他開會時說, 然後自己訂好架構, 有必要的話得向 SD 做說明, 讓他能做簡報, 再自己做完測試, 寫一份測試報告上呈, 裡面有測資, 操作過程的截圖與說明, 到這裡約過了三個半月, 在這個過程中, 終於我將整個專案摸清楚了, 為了往後開發及解 bug, 我決定重構, 說是重構, 其實也沒做什麼了不起的設計, 只是很基本的分門別類, 整理一番而已, 打個比方來說就是, 原本是一塊四處佈滿垃圾的大空地, 將垃圾做好分類, 打包堆在固定地方, 然後棋盤式地畫一些區隔出來, 只是比原本以 純C 寫 JAVA 的方式好多了 頁面也全部重寫, 採用 JSTL/EL, 並補強後端程式, 落實 MVC 一邊做新東西, 一邊重構, 到終於分出層, 改寫完所有程式及頁面, 約過了五個月, 然後我丟了辭呈, 預告時間為一個半月, 其實依規定我只要十天前提出即可, 但是...就佛心病發 然後我開始將我所知道的一切文件化, 有哪些技術, 有什麼資源, 能怎麼用, 做一些簡單的實際範例, 然後 publish, 這事一直做到我離職當天, 寫完最後幾篇文章, ( 其實是用年假寫的, 離職當天貼上團隊文件區 ) 下午跑完流程閃人 以上個人經驗, 僅供參考, 實際上該如何做, 能如何做, 請斟酌您公司的制度, 前輩們的為人, 自己的時間與精力, 對整個專案可能的影響等等因素, 好好慎重考慮思量 ※ 引述《pokerhand (pokerhand)》之銘言: : 雖然我原先問的怎麼導入OO觀念的部份, 不知道怎麼後面變成在講 refactor去了... : 不過這些文章也很精彩 : 也有得到幾種解法 : "掌權後規範" : "成為team裡的神, 喊水就會結凍" : 其實這樣比較合理 : 不過我仍然想聽聽看有沒有怎麼打動"人"的case可以分享 : ps. 這個主題其實跟技術沒什麼關 純粹是人的問題 : ※ 引述《TonyQ (沉默是金。)》之銘言: : (恕珊) : : 2.有些東西看起來像是 cp ,但實際上不是 cp : : 比方說 for loop 都長很像,但是每個 for loop 巧妙各有不同, : : 有些 code 要看仔細,有些不同的小變數或什麼, : : 能拆成參數的盡量拆,但是也是會有碰到看起來很像, : : 重構拆成共同的方法一換之後發現不會動的事情發生, : : 因為他們就是不一樣... : 另外問一下, 像這種流程看起來很像的東西, 通常是用template : 但是有時候就是會發生這種很小規模的兩個 condition或是 loop 只差一點點 : 有什麼好方法可以解決嗎? -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.224.45.10
pokerhand:推詳細, 很有參考價值 & 看到"user搞不好還比較詳細" 04/17 23:22
pokerhand:我忍不住笑了...苦笑...因為我們SA也是這個樣.. 04/17 23:22
amouse:看完我還蠻想要那些文件的...xd 04/17 23:24
kyoin:很好奇你們的SA&SD如果像你說的這麼... 為什麼他們還可以安 04/17 23:36
kyoin:然的任職?就文章內容說起來,感覺你有一定的實力了阿 怎麼不 04/17 23:38
kyoin:直接找點有規模的公司 起碼也比較不會遇到像現在的情況 04/17 23:38
kyoin:純粹好奇這兩個問題!! 沒有任何冒犯之意 04/17 23:39
lovdkkkk:@amouse 文件就不太方便哩 太多該單位資訊 04/17 23:39
lovdkkkk:@kyoin 那是一個進去後就非常 非常不容易被砍頭的地方 04/17 23:40
lovdkkkk:其實挺大 挺安穩 也光鮮亮麗的 04/17 23:42
lovdkkkk:反而離開後 我選擇找小得多 但也精實多了的公司 04/17 23:43
※ 編輯: lovdkkkk 來自: 61.224.45.10 (04/18 00:12)
lovdkkkk:@pokerhand 我個人覺得 hibernate 掛錯 dialect 比較扯 04/18 00:44
lovdkkkk:不過也是個 讓我有動力爬過所有設定檔跟官方文件的契機 04/18 00:45
pokerhand:不太容易被砍大概是不願精實的主因吧 04/18 01:25
pokerhand:我是抱著幾年後跳槽的心態在做事的,可能這一點就不同了 04/18 01:25