Simple

最近聽到這兩個詞的比較，套用在系統的效能分析上，是個不錯的解釋 不過我卻反而想到了在管理議題，曾經思考過的一個概念 頓時有種海闊天空的感覺，一掃最近的鬱悶 ------------------------------------------------------------------------------ 每個團隊，其實追求的並不是最大值(Maximization) 或者說，要是為了追求最大值，就會在不知不覺中，陷入前陣子那種鬱悶感中 團隊的資源、人力常常不是個人能決定的，而是由各種因素，組成了這個團隊 這就是「先天限制」，也就是 資源有限 的概念 那既然每個團隊的資源量都不同，大家都追求同一個最大值，合理嗎？ 這也是在管理的方面，一不注意就忽略的點 曾經在辦營隊的時候，有思考過一個問題 我們的團隊並不是個人能決定的，即便是有了分組，擅長的內容與擅長的程度也都不同 那今天如果身為一個領導者 要做的應該是「 引導一個80分的團隊，發揮出90分的成果 」，甚至是「 讓60分的團隊，產生80分的價值 」，這才是最佳化Optimization的概念 而不是不管任何先天限制，一味的追求那個最大值100分 在管理上，如果為了追求最大值，而忽略的資源限制，就會產生一個現象： 「領導者覺得成員為何不做到100分，開始責備成員；成員覺得為什麼已經做得比平常好了，還是得不到讚賞」 在這種互相不信任、對立的氛圍中，任何團隊都是會瓦解的 反倒應該是認清每個團隊的「現在最大值」，激勵所有成員去挑戰它，去協調、引導成員的合作，找出最佳的合作模式，一步一步地從65、70、80慢慢成長，即便最後成果不是100分，在整個合作過程中會達到多贏的局面 ──  所有成員都能在良好的團隊文化中，體會到成長的成就感 。 這時候的關鍵點是在領導者身上，如果沒有轉換成最佳化的概念，不論領導者個人有多厲害，都不能帶領出一個強悍的團隊；甚至可以說如果是個人能力太強，更容易加速團隊的瓦解。 我想，試著去引導團隊的風氣，才是較適合的做法

哎呀~今天要紀錄一下coding以外的東西了XD 實習的第一個階段已經完成了，接下來又是一個新的開始，先稍微整理一下收穫吧。 收穫其實很豐富，不過聽說三點 式 是最吸引人的，簡報通常大家也只記得三點。 那只好化繁為簡了~ --------------------------------------------------------------------------------------------------------- 1.實際接觸是最快速的學習方式 對我而言這三周新訓可以說學很多，接觸到一些沒寫過的語言、沒有深入思考過的OO概念... 不過更重要的是透過 印證學校所學的內容！ 舉例來說學校有教過Water-Fall開發方式，也說過這個方式缺點是文件多、時程長、反應慢等缺點。 然而在SA&D課程中，都只能憑空去「想像」，然後得到「嗯....真的」這樣的結論跟收穫。 當我真正去接觸一個軟體開發時，才能更深刻的體會到這個過程究竟有多漫長、這些缺點是否真的像之前學到的 書裡學的東西的確很寶貴，但對我這種不太愛記理論的人來說，直接去做去摔跤，留下來的疤痕我就會記得了！XD 這幾天呢，終於有點時間喘息，順便反省一下 回想一下SAD學過的開發方法：SDLC、Agile、Scrum 回想一下專題開發的兩三個月衝刺：跟現在Full-Time的工作方式有何不同 回想一下自己專題做過的需求分析、時程規劃：跟實務上的做法差在哪？(天壤之別阿QQ~之前做得差不多只是扮家家酒的等級) 回想一下自己負責coding的工作內容：跟現在coding的模式、要求是否相同 一個一個回想過，發現差在哪，那就是收穫了！ 現在回頭來看，雖然之前做的是扮家家酒等級，但曾經也是沒日沒夜的拚了才能有如此成果。 套一句 Scrum 的說法「雖然還是一直失敗，但每轉一圈，失敗就愈來愈少」 現在大概是我的第二輪吧，雖然一些workshop還是都滿失敗的，不過進步了一點點已經很開心了，哈哈。 接著就要進入第三輪了！ 又要失敗了 ----------------------------------------------------------------------------------------------------------...

實習以後時再遇到太多的"實務經驗"的洗禮了 以前繳作業大概就是能跑出結果，不要出大問題就ok 雖然也都教過一些原則跟"良好的程式"應該具備的東西，不會被釘的時候常常就....可以看就好啦~ 然而到了實習發現很多原則不遵守都不行，甚至要求的還比較嚴格 因為在專案變大已經不是自行玩玩的小程式了，人員、規格、嚴謹程度都大幅提升 也開始懂得「為什麼測試步驟常常被跳過」、「程式設計師跟需求端的溝通困難」之類的心情了XD 不過被釘了三個禮拜後，確實也學到滿多經驗跟擴展一些視野 今天記錄一下學到的一些命名原則 命名的要有意義： 最基本的要求，在境界上「讓大家不用看註解就能看懂」是最佳情況，因為註解可能寫的跟程式不同，但所有根本應該都還是程式。 盡量不要縮寫，把完整單字寫出，除非有特定領域大家都可接受的縮寫： 確保其他人一看就看得懂的意思 有「 Camel Case 」和「 Pascal Case 」兩種主要的命名方法 Camel Case：第一個字開頭小寫，後續單字開始大寫。如：firstName Pascal Case：第一個字開頭大寫，後續單字也都大寫。如：FirstName 避免使用符號、空白跟底線： 利用第3點的方式來命名 命名沒有絕對，可以參考團隊的開發手冊，整個團隊可以接受有共識即可。 另外不確定是OO都這樣還是只有Java(相較其他OO語言，只對Java比較熟悉一點...) 類別名稱常用名詞，以大寫開頭(Pascal Case)； class ImageSprite; 屬性名稱、參數名稱常用名詞，小寫開頭(Camel Case)； float myWidth; 方法名稱常用動詞開頭，小寫開頭(Camel Case)； runFast(); createTable(); 介面名稱常用形容詞，以大寫開頭(Pascal Case)。 interface Storing; 介面的命名通常會加上I：例如Customer類別要實作ICustomer介面 天吶~記不完，程式設計這種東西呢...最好的方法就是 多寫，養成習慣！！ 羨慕那些良好的Coding Style，可以寫出漂亮、乾淨的程式>< 菜鳥如我呢，也只能沒日沒夜的co...

今天又是一蹋糊塗的課程，大致整理一下把內容規程三塊吧 1. JSP、JavaBean和Servlet介紹 2. 系統開發分層概念 3. MVC模式 ----------------------------------------------------------------------------------------------------------- 1. JSP、JavaBean和Servlet介紹 JavaBean跟Servlet都是Java類別。 但Servlet是繼承自javax.servlet.HttpServlet，所以可以收Httprequest和送Httpresponse等網頁應用程式的基本功能。 而JavaBean就單純的是個Java類別，可以繼承自任何類別；其用途是介於JSP和Servlet之間當作傳遞的橋樑。似乎又可以分為兩種用途：工具或是單純的參數物件 相關參考連結： JSP、Servlet 與 JavaBean 的組合應用 ---------------------------------------------------------------------------------------------------------- 2. 系統開發分層概念 三層式架構：   這裡的 三層指的是Presentation Tier、Business Tier、Data Tier ！ 圖片來源：http://criticaltechnology.blogspot.tw/2011/09/mvc-in-three-tier-architecture.html 在古代的應用程式是只有兩層：前端的表現層跟後端的程式+資料庫。 但在現今的環境下，我們已經把程式跟資料庫分離，讓 資料維護 以及 程式維護 獨立。 因此現今的網頁應用程式就分成三層，讓各層的工作更加確切跟獨立。 而我一直把這三層式架構跟MVC模式喇在一起，傻傻分不清楚。 其實 兩者是不同的東西 ，三層式架構是軟體架構。 而MVC模式則是在程式設計上遵循的一個方式，也就是設計模式，讓程式設計師跟UI設計師可以更清楚的分工。 如果把兩者拉在一起看的話，M-V-C三者的集合大致...

今天又聽了一堆名詞....記都記不完，也聽不太懂XDD 只好花時間問Google做功課 進入正題，泛型簡單來說就是用來增加彈性，例如當我們 有同一個演算法，可是要處理的參數型別有很多種 ，就可以透過泛型來設計。 舉例來說List、ArrayList這些都有泛型的設計，所以我們在使用時可以進一步限制他們的型別。如List<String>、ArrayList<Customer>(Customer是自己設計的類別) 接著看泛型的使用，直接先看例子： class Node< T >{      private T  value;      T getValue(){           return value;      }      setValue( T value){            this.value = value;      } } 當我們在使用此Class時 Node< String > node = new Node< String >(); 就會做出下面這個Node class Node< String >{      private  String  value;       String  getValue(){           return value;      }      setValue( String  value){            this.value = value;      } } 那我們如果是其他的...

有鑑於Eclipse可能重灌或在其他設備上使用，把一些常用的設定筆記下來。 把提示的功能設為所有字母 工具列的Windows -> Preferences -> Java -> Editor -> Content Assist 1.勾選 "Enable auto-activation" 2.Auto activation delay 為提示出現的延遲時間，可以設為 0 3.Auto activation triggers for Java 為遇到何種字元會自動啟動提示，預設只有 dot，改為.abcdefghijklmnopqrstuvwxyz(, 移除一些不需要的套件 工具列的Help > About Eclipse 點選左下角 Installation Details。 點選要更新或移除的套件，下方會有 update 或 remove 可選擇。

這三者我一直搞不清楚，有時候API跟Method好像差不多，有時候覺得API概念不就跟Library一樣嗎？ 後來發現這三者差別，需要視它們是對於一個"應用程式"而言是在什麼位置。是應用程式本身，還是不相關的應用程式，還是想要與應用程式互動的外部應用程式。 先來個例子： 今天有一個甲應用程式提供了API ReturnNumber(int a) 而甲應用程式裡面的處理是 int ReturnNumber(int a){ return round(random(a)); }; 接著我們一一解釋它們各是甚麼。 round()、random()：是由內建library提供的兩個method ReturnNumber()：是一個自己寫的Method，但因為我們提供它給外部使用，所以也是個API。 假設乙應用程式用了ReturnNumber()這個API，則只能傳進一個參數a，實際上他不知道這個API裡面寫了什麼，只能透過甲提供的文件說明來知道用途。 這個例子可以看到三者的實例，接著再來進一步說明。 ----------------------------------------------------------------------------------------------- API、Method和Library的關係 【Library】 函式庫，指將一群已經寫好的Method(Function)包成一個Library，當我們import這個Library後就能使用其包含的Method。(此處只是個程式語言的稱法不同，Method指Java、Function指C) 【API( A pplication P rogramming I nterface)】 應用程式介面，指提供給 外部程式 存取或是已經寫好的功能，事實上可以把它當作一群Method的集合，外部程式只能用這些Method。 【Method】 在Java稱為Method，類似C的Function，但不完全相同，這又是另一段故事了。 (在物件導向中的Method是綁定Class，所以要用Method一定要先實體化一個Object。ex. student.gohom...