![[ 小黑宅 ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmj8WPlai5Sm3WwgojjMZ6gskRvSKGQJoJLSBz9-7VBEBuc_zkmYiGRwSMmvUr9UYsit7rvEXLajK7U4NoPeoLCwOc8UdlUzkj6wx-m19KR_TAoVPMaPk_bvUSQxyQ-HltWbOjm2gEbk5I/s1600-r/logo.png){kind=logo}
Android 6(API level 23) 之後，開發者會被要求者處理 APP 權限問題(針對 Run)，程式碼要撰寫相關邏輯：檢查有沒有權限、處理取得權限後的行為...等。官方範例碼大概就是畫面跳轉類似用 Listener Pattern 的方式來處理，另外還要處理當使用者選取"不要再跳出權限對話框"的特殊狀況。總覺得應該就是一個 yes 或 no 就該解決的事情，但每次寫出來都不一樣，各別提不同人寫出來的流程都是天差地遠了。
這次改用 RxPermissions 來重寫，RxPermissions 封裝邏輯後寫出來的程式碼順序很直覺：
0
則回應
0
則回應
這跟處理巨量資料的 apache spark 無關！
如果有時候只是要寫個沒幾個人用的 Restful API，或只是想要有個 HTTP 接口（透過 get/post）來呼叫我們寫好的 Java SE 程式，如果對架設 tomcat / Java EE Server 又不熟悉，那可以考慮用 Spark！
0
則回應
寫一下這一兩個月使用 Jenkins Server 的心得，我目前使用的狀況如下：
0
則回應
這本來算是我在前公司要弄的項目，種種原因下搞到最近我才敢講我有玩過一輪。實務部分，大概從 jenkins 建立到整合 git / svn ，成功 build 完一個 jar / android apk。理論的部分則是翻完了下面這本名字落落長的書（有機會在寫心得）。
本文記錄一下，我在 jenkins 建構完這兩個專案的想法。
Continuous Delivery中文版：利用自動化的建置、測試與部署完美創造出可信賴的軟體發佈
4
則回應
書中幾乎所有的程式碼都是以 Java 作為例子，所以寫 Java，C# 的人看起來會比較輕鬆。太深入的內容就不寫了，簡單寫幾句看完自己覺得的有印象的（寫程式可以先當作身體反應的準則），有興趣的還是買書去支持一下 Teddy 大大。
0
則回應
本文內容同步更新到我之前寫的 Android UI 屬性筆記(持續更新) 。
scaleType 屬性，決定了圖片如何在 ImageView 中被顯示，下方用兩張圖說明。為了避免圖片跟 ImageView 的顯示範圍搞不清楚，所以我程式碼將
所以下圖中的橘色也就是 ImageView 會塞滿整個手機顯示範圍。
觀察後的結論：
0
則回應
去年用Ruby寫的程式，主要是爬以下三個網頁：
你一定會問都有網頁查詢了，你還爬個屁阿！主要是他提供的資料都是以月份為最單位，若你要抓X年的資料你就要點12*X次，你若要抓Y檔股票，那你總共要點12*X*Y次，所以在父親大人的督促之下，就寫了這三隻爬蟲給他用，修改程式裡頭的時間範圍跟代號，就會去網頁爬一輪回來產生一隻CSV檔案（可用excel開啟）給使用者。
產生檔案範例可參考：
可執行且需要使用者重新編輯的檔案，根據網頁連結命名分別為：
需要重新編輯的程式碼大概都長得像這樣：
東西寫出來沒再用也是浪費，好一陣子沒用RUBY了，遇到問題請自己上網查或買書看，不要輸給我五十幾歲的老爸。
4
則回應
早上看到這篇Jekyll: A Ruby-Powered Static Site Generator，就順手安裝測試來玩，此為無聊筆記紀錄一下我有作過這些事。
是由Tom Preston-Werner(Github的編寫者？)所編寫的OpenSource。jekyll是一個很簡單使用的部落格文章內容生產器，傳入Textile、Markdown這類的Lightweight Markup Language，它便會根據你建立好的設定檔案（網頁的基本版型'、CSS…），最終產出一個架構完整的資料夾（內含html檔案、css檔案及其他會引用到的資料夾）。而我們最後所要做的只要把這個資料夾到網站主機上（例如：Apache）就可以了。
首先你要有安裝Ruby，接下來只是簡單把jekyll給gem回來即可。
參考：http://wiki.github.com/mojombo/jekyll/install
我沒有仔細看有無可以快速建立一個專案架構的script，所以我是參考原作者的jekyll專案，一個一個慢慢自己建立的，如下圖所示：
主要是用來設定jekyll啟動相關的參數。
參考：http://wiki.github.com/mojombo/jekyll/configuration
基本上裡頭要建立的是HTML檔案，主要用來架構Blog版面的骨架。
檔案最上面是YAML Front Matter用來設定變數，比如說我這邊就指定在這之前，必須先通過同是在_layouts資料夾下的default.html，藉此可以排除掉不斷DRY的html語法。
這也是我們放置文章的地方，檔名要符合”年-月-日-標題.副檔名”這樣的格式，檔案格式就是上面所提的Lightweight Mackup Language。這些檔案最後都會被轉成html。
根據設定（外貌）及_posts資料夾下的文字檔案（內容），最終產生的所有html檔案都會放在此處，這就是最後可以直接放在網站主機上的檔案結構。
首頁檔案。
參考：http://wiki.github.com/mojombo/jekyll/usage
把上述步驟完成，執行
jekyll –server
jekyll就會把產生_site資料夾，所有靜態的網頁檔案都放在其中，同時也可以在瀏覽器透過 http://localhost:4000 預覽網頁的效果。
就是把_site資料夾底下的所有檔案上傳到網頁主機上。
0
則回應
重構：狹義的解釋是重新整理已經寫好的程式碼。
重構：更廣義地解釋是不斷地整理正在寫的程式碼。
對於有重構思維的程序員來說，不論程式碼是否已經被完成，重構其實在編程過程中是不斷地在同步進行的。重構不在是笨重的黃金鎚！重構已經是一種內化行為！
三年前，剛考了一張號稱全民都有的SCJP，寫著自己都不知道有沒有OOP程式碼的菜鳥。還記得上班後第一次參加JAVA研討會，SDK的API都還不能算是熟捻的程度（現在也不熟XD），更何況大部分的議題都是不同應用領域的技術，兩天下來真的有萬念俱灰想死的念頭
（照片出處：http://www.flickr.com/photos/swanky-hsiao）
當時侯捷老師的議題是Design Pattern相關的主題，當時我還很開心想說中於是跟「寫程式概念」有相關的主題，此行終於能學到些可以用的技術。依稀記得走出會場我的臉是呆滯的，侯老師這堂課也是壓垮我編程信心的最後一根稻草。當時還不能夠體會編程之美的我，回到新竹的路上，腦裡都在想轉行的事情。從此到書店看到侯老師翻譯的書，眼光都不自主地飄開，跟勇九可以在地圖上選擇不遇敵一樣。
超愛看中文程式輸的我，寧願上網看英文的重構相關文章。一半的原因是當年揮之不去的心魔。另一半的原因也是我一直在等歐萊里，看它們會不會出一本無腦的深入淺出重構。三年過去了，沒盼到深入淺出重構的問世，也只好硬著頭皮買了這本重構聖經的中文版。
書花了一兩個星期就完食了，看完一整個是相見恨晚真的是恨自己怎麼硬撐那麼久才買。書裡頭得重點我就不花時間寫心得了（最近也沒時間寫），直接把值得推薦的原因寫上。
作者的文筆和翻譯品質都在水準之上。我最怕的程式書就是API的說明狂貼，要不然就是文筆不順，明明都是中文但整句看完卻完全看不懂作者想要表示什麼。
內容完全與編程技巧相關。沒有太多抽象空泛的長篇大論，每道手法的使用時機、詳細步驟和範例都一應俱全。
程式碼範例皆用JAVA與簡單的UML來說明。我不需要在花時間在思考語法轉換或語義的問題上。
文章編排簡潔，行距也夠寬，眼睛不會看到很吃力。
每個技巧是一個獨立章節，第一次看當觀念書看，整本看完以後，將來透過索引快速參照就變成一本實用的工具書。
自己的編程水準是找不太出這本書的缺點，唯一硬要挑毛病的話，大概是程式碼範例如果能使等寬字型會更好（果然水準不夠的人都是從外觀開始找問題XD）。
這本書最棒的地方在於，藉由範例讀者可以知道什麼樣的程式碼是糟糕的程式碼，而這原本可能是你需要犯上大量的錯誤代價才能學到的經驗。更棒的是，不僅教你釣魚連釣魚竿都幫你買好了，範例的後面就是解決問題的答案（XD）。
花上幾百元再加上認真讀個一兩個星期，而光譜的另一端是犯下已知錯誤不得不加班修改的爆肝生活，真的會想的研發都應該知道要選擇哪一種未來！
6
則回應
一直以來都是GoogleReader來分享文章，自從越來越多朋友玩噗浪之後，分享文章慢慢變成一種很DRY（Don’t Repeat Yourself）的事，在GoogleReader看到不錯的文章，一下忙著按下分享，一下忙著貼上噗浪，最後還要想看看是否要msn還是轉寄給家人。
不知道是不是有現成的軟體下，就直接開使用ruby開始寫工具了！不是我愛重造輪子，是我很慘每次學東就忘西，寫些程式好讓我喚回我對ruby的記憶。邊程相關應該沒啥人有興趣，我最直接寫在最後了。
PS: 此程式需要用到simple-rss和mechanize，使用者必須要gem回來。
關於噗浪這部份都是參考XDite大的Unofficial Plurk API in Ruby，最後發現自己用不到那麼多方法，所以只把有需要的部份加入到自己的程式碼中，順便從XDite的程式碼中得知mechanize這個跟網站互動的API。rss的部份因為GoogleReader輸出的是atom格式，所以沒有用內建的API改用simple-rss來讀取。
心得就是雙修的下場是兩邊技能都不太強，我英文跟日文的學習進度也有一樣的情況。然後不要玩太兇，要不然下場就跟我一樣（如下圖），暗！
8
則回應
續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第七章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
本章是本書的最後一章,我終於 K 完這本書了,雖然頁數不多,但看原文速度真的慢很多啊!
注重效率的團隊 將之前章節強調的觀念,以套用在團隊的立場在強調一次. 成員間要多交流,大家互相學習及成長,把好的開發流程或概念帶進團隊來,整個團隊不斷往前邁進,公司對外才會更有競爭力.
無所不在的自動化 告訴我們電腦是處理重覆性工作的專家,懶惰則是好的工程師需要具備的特性之一,利用工具或自己開發程式,把需要浪費時間的工作交給電腦處理,省下來的時間再去學新的東西.
無情的測試 強調測試並不是用完即丟,或是寫完就不用去修改它的. 測試程式應該是不斷被執行,並且會隨著程式碼演化的.
代碼文檔不分家. 註解是程式設計師最好的朋友,多花一點時間到離職都可以受用無窮,大腦就應該拿去裝一些需要思考運轉的東西,而不是用來挖掘當初為何自己要這樣寫的理由. 另外,每一份印出的文件都只是當時專案的快照,並不代表其永久有效,透過使用開放編輯的方式,讓文件跟程式碼同步演化,文件才有其存在的價值.
巨大的期望 需要與客戶持續互動,才能確保專案是朝著客戶想要的方向邁進. 回饋的頻率拉得越長,其修改所需的代價也會越高.
傲慢與偏見 - 很日劇式熱血的一小章. 反正就是要激發讀者身為職人的自尊,我以我的程式碼為榮,別人看到作者是我就知道這是品質保證. 因為自尊所以更認真保證品質,品質提高別人對自己的 Credit 變高,如此便是一個良性的循環.
2
則回應
續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第六章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
本章重點放在開始寫碼之前應該有的準備工作 - 收集需求,解決臭蟲,確認可行性,製訂規格 和 開發流程.
需求之坑 在於使用者很可能自己都不知道自己的需求為何的情況下,其實很多需求是在回饋的過程中,不斷地被挖掘出來的. 個人的經驗通常是,通過層層的關卡後,我做出來的東西,通常變的不會是終端使用者所想的功能,以至於後續會不斷上演砍掉重練的情況發生.
解決不可解的謎題 和之前提過的”靠巧合編碼”一樣,都是要求程式設計師要真正了解問題,把發生問題的原因解決,而不是掩飾表面或後續衍生的問題.
直到準備好 要求在寫碼之前要先規劃藍圖,房子不會邊蓋邊想要改幾層,但寫程式時常會被要求這要搞,但無腦之開寫的下場,辛運一點就是可運行但很難維護的程式碼,最衰的就是寫到一半才發現根本此路不通準備黑掉…
規範陷阱 相對於不規劃就編碼,它位於光譜的另外一端(凡事太過或是不及都不會是好事 XD),嚐試著一次完成所有的規格是件不可能的事,再加上客戶不斷增加或變化的需求,規格與實作往往會漸行漸遠. 做人腦筋不要太死板,規格也是一樣,且戰且走,邊做邊改,最後才不會拿到一本根本過時的兩千頁規格書.
圓圈與箭頭 要程式設計師對於各種開發方式採取開放的態度. 個人覺得這可以套用在各種地方,不排斥學習新知,好的學起來,不好的也了解壞在哪裡. 井底之蛙,以管窺天. 海納百川,有容乃大.
0
則回應
續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第五章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
本章主要強調的重點是 – 程式設計師是否真的了解自己在寫什麼. 而 程式黑手 與 程式設計師 的最大差別我想也在於此 - 是否有在用腦在寫程式碼,還是不管三七二十一拼出一個會動的東西而已.
靠巧合編碼 最好的解釋情境 – 修一個關於迴圈的 Bug ,只是不斷地去調整迴圈 index 的範圍,而不是找出錯誤的真正原因. 如果在寫程式時有這樣的心態,那你就是在靠巧合在編碼.
演算法的速度 使用 O() 表示法,在編碼(或 檢視程式碼片段)的過程中就能大概知道其效率,提早察覺效能上可能會遇到的瓶頸.
重構 鼓勵程式設計師週期性地檢視過去的程式碼,昨日的程式碼不見得符合現今的需要. 不斷地透過重構來整理程式碼,而不是在歪斜的骨架上搭建新的疊層屋.
易測試的代碼 在於寫程式之前就已經準備好測試的程式碼,如此所寫的程式碼不自覺就會以好測試為目標來下筆. 理想中,程式碼的大功能會被切分成小功能(這樣比較好分別測試). 另外,測試程式是重構最好的朋友,重構完是否搞砸了原有的功能? 問問測試程式是最快的方法.
邪惡的嚮導 也就是靠 IDE 工具生成出來的程式碼. 如同靠巧合編碼,是否真的了解程式碼,是 程式黑手 與 程式設計師 的最大的差異之處. 就算只是想當個程式黑手過日子,我相信多了解程式碼還是能節省許多解 Bug 的時間,好讓你回家看老婆抱小孩就是.
0
則回應
續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第四章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
本章強調彈性的好處,寫出鬆散低耦合的程式碼,在將來能用最少的修改以完成變動的需求(理想烏邦托是這樣).
解耦 就有點像 島耕作 在公司裡的作為 - 不結黨營私,越少的利害關係才能明哲保身. 其中的Demeter 法則,是在譔寫方法時很好用的一個開發心法.
Metaprogramming 又是更進一步將工作流程從程式碼中解耦出來,現在很多框架都也是用這種方式來做設定. 不過也代表除了程式碼之外,也得知道 要到哪? 做哪些設定? 設定的效果? ,以上是我在遇到設定時比較頭疼的問題(不過有好好看文件,這些應該都不是問題.).
時間耦合 是提醒在一開始就以將來會支援並行性的心態來撰寫程式,當加入行程的考量時,程式的設計不得不跳脫線性執行的思考,同時也比較模組化.
這不僅僅是 UI 主要是使用 訂閱/發佈 和 MVC 的概念,將 資料/商業邏輯 從 UI 中拔出來. 不過只有提到大觀念跟架構,實際寫法我建議還是要另外找書看,免得寫出一堆自稱是 MVC 的爛扣出來!
最後一章黑板,我只能說寫的很抽像,若是套用在開發流程上,我知道是要大家在同一個地方做溝通與設計的動作(ex: wiki),不過後面將黑板套用在程式設計時則完全是沒有提到如果實作,本人極度懷疑這段是請某個會劃大餅的 sales 寫的啊! XD
0
則回應
續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第三章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
本章終於開始進入寫程式的階段,利用語言或是外掛提供的功能,在進入程式實作之前建立一些規則/定義,讓潛在的問題提早在開發階段發生,而不是出包會黑掉的部署階段. 囧rz
按合約編程在實際開始編碼前,先規定好預期的 input 和 output ,我剛開始寫程式似乎都是用此想法開始,但後來我比較喜歡用測試先行的方式來寫碼.
死掉的程式就是死了! 換句話說有問題就讓程式早點死掉,忽略問題雖然可以讓程式繼續執行,但有很大的可能它已經是個活死人了(而已你也只會覺得它怪怪的),人死了才會讓程式設計師去正視問題!
斷言編程 不同於 合約編程,合約編程定出預期的事物,斷言編程用於檢查程式設計師(不要相信自己是本書的中心思想之一)認為不會發生的情況. 現實生活中,我還是習慣用 測試先行 來包含 合約編程 + 斷言編程 這兩種作法.
例外 是 Java 處理錯誤的方式,我只知道 1)不要亂隱藏例外,2)要寫有可讀性質的例外,3)將例外用於真正異常發生的時候,而不是當作 true/false 的昂貴代替寫法.
Java 有垃圾回收機制,所以資源部份我就不亂發表心得了! 以後我若改去寫 C 的工作,我相信我要重花一段時間好好學習這一塊. XD
0
則回應
續上一章 程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第二章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
本章開始介紹程式員應該設置好有效率的工作環境和工具. 建立專屬於自己的一套火藥庫,並不斷將這套環境更新及進化.
純本文的威力在於它沒有太多格式問題,人腦可理解也很容易寫程式去解析它. 雖然文字檔是人眼可讀的,但只要寫入的人無腦,還是能寫入一堆不可讀的資料,讓文字檔失去人腦可讀的特性.
Shell 這方面,只能說 GUI 讓更多人擁抱電腦,但在 Shell 才能讓電腦發揮它的長處 - 重覆性的耗時工作.
編輯器算是影響程序員產能的重要因素之一吧! 雖然我知道打開筆計本寫扣看起來很屌很大師,但我還是寧願打開我的 IDE ,背好熱鍵,讓 IDE 幫我產生樣版打出正確的名稱.
版本控制真的是好物,但不知為何總有人喜歡這邊留一份那邊留一份,然後再來人眼比對. 我想這這就是學校講授上和業界實務上的鴻溝之一吧學校沒教的事吧! XD
測試首先就是要冷靜,不要有先入為主的假設,遇到假設就要能證明它. 最後找出臭蟲的源頭並修正它,不要只做些表像的修補工作. 試問你家馬桶大便沖不下去, 1)你會每次大便完,把大便撈出來丟垃圾桶? 2)還是把馬桶修好?
文字處理算是程式員常常在接觸的東西,所以學好一個本文處理語言算是有益無害的東西. 有時只是臨時需要(用完可丟的)一個文字處理小程式,像 JAVA 的正規表達式的寫法就很難用,這時你若會寫 Ruby 就方便多了! 雖然我對於學新技術很排斥(我不愛追最新的東西,我覺得這東西追不完,這個十年你可以看到都是這些人在追,但下個十年可能就是完全沒看過新的一批人了. 至少我會想拿這些時間去學些可以永遠使用的技能. 但我還是很感謝勇於追新技術又肯分享的人.),但我不排斥能讓我早點下班的技術觀念. XD
透過程式碼生成器,可以將一些重覆的概念封裝在同一處,讓產生器根據此處來產生其它語言程式碼(讓它變成一個 Build 的步驟之一),變動只出現在一個地方,其它所需要的變動都讓生成器幫程式員做完了.
0
則回應
(圖片來自: http://www.dajiadiy.com/data/2007/0429/article_75.html)
對照上面的照片:
點點背是一個 極低調的讀字卡學習程式.
基本上 Delete jar 檔就可以了!
下載回來會是一個 jar 檔! 點兩下就可以執行!
第一步
若在你的系統托盤上看到點點背的圖示,代表已經成功啟動點點背. 在圖示上按右鍵,你可以看到點點背的相關功能.
開啟檔案
點點背只支援 CSV 格式的檔案. 可填入 檔案在電腦上的路徑 或是 檔案的網路連結.
- 關於 CSV 格式檔案可以參考下文 CSV檔案 這一章.
- 一開始大家應該沒有 CSV 檔案可匯入,可參考下文 分享 這一章,我有分享一個檔案可供大家測試.
低調學習
成功開啟後:
- 在圖示上點左鍵兩下,就會顯示目前卡片內容的對話框.
- 在圖示上點左鍵兩下,就會顯示下一張卡片內容的對話框.
- 在對話框上點擊,對話框就會消失.
簡單但說錯不負責地說明 CSV 格式:
更清楚的 CSV 格式可參考 http://zh.wikipedia.org/wiki/CSV (中文) 或 http://en.wikipedia.org/wiki/Comma-separated_values (英文) . 在了解 CSV 的格式之後,你可以使用 筆記本/Excel/Google Doc 產生你自己專屬的讀字卡內容.
歡迎大家留言分享自己在用的 CSV 檔案,舉手之勞這世界會更美好. 小弟自己先提供一個我在用的 CSV 檔案
日檢四級常用單字(共701個單字,直接把 Link 填入開啟 或 下載後在開啟 都可以.) - http://spreadsheets.google.com/pub?key=pYls0CH6DreZ4oin1thzWLg&output=csv
在此篇留言即可! Orz
謝謝這軟體的原創者 - 我同事 farfree ,我只是根據我的需求重新寫了一個我想要的版本. あぃがとう
0
則回應
續上一章程序員修煉之道 (The Pragmatic Programmer From Journeyman to Master) 第一章讀書心得.
此為讀後重點筆記,好書值得大家購買閱讀.
持續第一章,本章點出一些開發人員必要的心法,謹記在心可以避免很多低級錯誤!
重覆之罪這我幹醮很多次了! 不管再怎麼憤怒都不應該 CP 來 CP 去,好好靜下心來思考是否可重新利用(重構)可運行的程式碼,這才是王道. 另外減少重覆同時也是在縮小出包的範圍. XD
正交就是指每個元件的交集程度,交集越小也代表重覆的概念or責任越少. 但正交性這章看完,我不知道為什麼我總是會想到”上班好同事,下班不認識.”這句話. XD
可逆性白點就是話不要說太死,說太滿結果最後說錯可是很丟臉低. 寫扣前要好好想想是否未來此處有變動的機率,留點後路以後也不會太痛也可以少加一點班.
我個人開發還常用 Tracer Bullets 這個技巧,不浪費每一個我摸索所寫下的程式碼,我果然有客家人的血統.
相對於 Tracer Bullets ,我覺得寫程式用 Prototype 真的很腦殘,刻一個看起來正確卻無用的東西,真的是白癡!
領域語言我覺得跟第一章所說的溝通有關. 如何用對方了解的事物解釋對方所不了解的東西,就某方面來說,我覺得這是一個好 RD 跟 普通好 RD 的差別之一.
最後一章節就真的屌了! 估時程,坦白說,我真的覺得有些東西根本沒辦法估時程,有時候你很認真估了一個時程,到實際上也不一定照這個時程跑. 我覺得與其自己學好這些技巧,不如讓整個團隊也重視這個觀念來得有用!
0
則回應
此為讀後重點筆記,好書值得大家購買閱讀.
本章沒有太多技術性的東西,主要是導正程式設計師上一些心態.
貓吃掉了我的源碼是多麼愚蠢的理由,但有時我就是會說出這種不成理由的理由,面對問題不應該急著推卸責任,找出可行的解法才能體現個人價值所在.
專案中的無序狀態,根本就是在說我. 面對殘破不堪的程式碼,即使不能大破大立的砍掉重練,也應該築起防火牆,讓腐敗不影響後面新加入的程式碼.
石頭湯教我要做團隊中的摧化劑,大家一起學習才是最快的進步方式. 不知水溫的青蛙則是在警告我們要不時注意大環境潮流,更新自己的知識才能維持自己的價值.
寫出夠好的程式碼 然後 就夠了,前往下一個村莊吧.
建立自己的學習地圖,定期以及有效率地投資自己的知識. 我們是科技業,這不完全是一個寫越久就越有價值的達人系統行業.
最後,我們要學會如何好好表達自己的想法. 也許我是不喜歡跟人溝通才進入工程師這個職業,但事實上,除了跟電腦溝通(寫扣),我要跟主管溝通,我要跟客戶溝通. 沒錯! 很殘念的事實! 我們必須學會與別人溝通.
2
則回應
