重構-向範式前進 Refacttoring to Patterns(2)-創建Replace Constructors with Creation Methods

6. 創建（Creation）

   6.1 Replace Constructors with Creation Methods

      當有很多Constructors時,把它改成很多個createXXX()
      反正就是要把各個建構子換成Creation Method的樣式

      

         +.比建構式更能有效表達可獲得哪一種的實體物件

         +.突破建構式的限制,像是不能同時擁有兩個 引數個數和引數型別均相同的 建構式

         +.更容易找出未使用的創見瑪(creation code)

         -. Creation方式變得不標準,有些classes 使用new來instantiated ,有些使用Creation Method

         1.找出一個 為創建某種性質的實體而呼叫class的建構式(假設為Ctor1),對其Extract Method, 建立 public static函式

            此新函式為Creation Method,再實施Move Method將Creation Method移到內含建構式Ctor1的那個class

         2.找出Ctor1的所有呼叫者 將其改為呼叫Creation Method

         3.如果Ctor1呼叫了Ctor2 就讓Creation Method呼叫Ctor2 , 可透過Inline Method進行

         4.任何想轉換回Creation Method的建構式 重複步驟1~3

         5.如果這些class建構式沒有class之外的呼叫者,設為nonpublic

   

重構-向範式前進 Refacttoring to Patterns (1)

1. 為什麼寫這本書

    1.1 過度設計

    1.2 The Patterns Panacea

    1.3 Under-Engineering

    1.4 Test-Driven Development

    1.5 Refactoring Patterns

    1.6 Evolutionary Design

2. 重構（Refactoring）

    2.1 Human readable

    2.2 Small Steps

    2.3 Design Debt

    2.4 Evolving a New Architecture
3. 範式（Patterns）

    3.1 Up-Front Design
4. 程式碼壞味道（Code Smells）

    4.1 duplicated unclear complicated
5. 一份Refactorings to Patterns名錄

約耳趣談軟體 PART3 如果你是約耳：既定主題的隨機思考

CH29　Rick Chapman在尋找愚蠢 

            1.技術與商業
CH30　這個國家的狗做什麼工作？ 

            1.用自己的方法
CH31　小員工也能做大事

            1.從自己做起 
CH32　兩則故事 

            1.管理階層的重要性
CH33　大麥克對上原味主廚

            1.天才與標準流程方法論

            2.需要的是什麼 

            3.維持高標準 vs 快速擴展
CH34　沒有事情像表面看起來那麼簡單 

            1.先做設計在實作
CH35　為非我發明症辯護

            1.核心事業的功能 要自己做  
CH36　策略書之一： Ben and Jerry模式與Amazon模式 

            1.兩種模式都能成功 挑一種堅持下去 
CH37　策略書之二：雞生蛋蛋生雞問題 

            1.互利的策略
CH38　策略書之三：讓我換回去！ 

            1.消除進入障礙
CH39　策略書之四：腫脹軟體與80/20迷思 

            不適用軟體了
CH40　策略書之五：開放源碼的經濟學 

            雞生蛋 蛋生雞
CH41　墨菲定律發威的一週 
CH42　微軟如何輸掉API戰爭

約耳趣談軟體 PART2 程式人員管理

CH20　面試人員教戰守則 

            1.簡介

            2.最近專案的問題

               a.尋找熱情

               b.好的人選會仔細把事情由各個層面解釋清楚

               c.如果專案是由多個人負責  尋找能擔任領導者的腳色

            3.不可能的問題

            4.程式問題

            5.你滿意嗎

            6.你有什麼問題

CH21　激勵是有害的 

            1.為了報酬而工作的人 表現不如完全不期望報酬的人
CH22　不用測試人員的五大（錯誤）藉口 

            1.問題是懶惰的程式設計人員弄出來的

            2.軟體放在網路上 即使有問題也能馬上修好  因為分發容易  但會有壞印象

            3.客戶會替我測試軟體

            4.有資格可勝利的人都不想做測試人員

            5.我請不起測試人員
CH23　人的工作切換有害無益 
CH24　你絕對不應該做的事之一 

            1.把程式從頭寫過
CH25　揭露冰山的秘密 

            1.客戶不知道他們要什麼  別期望客戶知道他們要什麼

            2.外觀很重要  如果外觀好  很容易讓不懂程式的人 以為專案已經完成了  

               因此時程規劃時 若功能還沒好  外觀也先不要太完整
CH26　抽象滲漏法則 

            1.了解基礎
CH27　程式設計領域的帕麥爾斯頓勳爵 

            2.知道各個領域的差別 各有長處
CH28　測量

            1.評價標準很難,也會花去太多時間->激勵是有害的 

約耳趣談軟體 PART1 程式設計實務

最近開始捷運通勤上下班

每天等於多了大概一小時看書的時間

紀錄一下看過的書 及一些看完還記得的重點

CH01  選擇一種語言

CH02  回歸原點

                   1.了解程式底層原理

CH03  約耳測試-高品質程式碼的12個步驟 

1. 1. 1. 1. 你有使用原始碼控制系統嗎?
         2. 你能用一個步驟建出所有結果嗎?
         3. 你有沒有每天都重新編譯建立(daily builds)嗎?
         4. 你有沒有問題追蹤資料庫(bug database)?
         5. 你會先把問題都修好之後才寫新的程式嗎?
         6. 你有一份最新的時程表嗎?
         7. 你有規格嗎?
         8. 程式人員有沒有安靜的工作環境?
         9. 你有沒有用市面上最好的工具?
         10. 你有沒有測試人員?
         11. 有沒有在面試時要求面試對象寫程式?
         12. 有沒有做走廊使用性(hallway usability)測試?

CH04   每位開發人員至少且絕對要會的Unicode及字元集必備知識 

CH05　無痛的功能規格1：何必麻煩？ 

            1.有規格文件和沒有規格文件的差異

            2.寫程式前先寫規格
CH06　無痛的功能規格2：規格是什麼？ 

            1.一段聲明

            2.一位作者 

            3.情境

            4.非目標

            5.概要

            6.細節很重要

            7.未定義項目

            8.旁注:測試註解 行銷註解 技術註解 文件編寫註解

            9.規格必須是活的
CH07　無痛的功能規格3：但是…該怎麼做？

            1.誰寫規格

            2.產品經理: 別讓程式人員對產品經理報告 
CH08　無痛的功能規格4：提示 

            1.要有趣

            2.寫規格就像在寫用腦執行的程式

            3.寫得越簡單越好

            4.審閱多次 並重讀幾遍

            5.使用樣板是不好的
CH09　無痛的軟體時程 

            1.用excel

            2.簡單就好

            3.每個功能包含多項任務

            4.實際寫該程式的人 排自己的時程

            5.把任務分得很細

            6.紀錄最初和目前的估計

            7.每天更新耗時欄

            8.加上假日等項目

            9.除錯時間排入時程

           10.整合時間排入時程

           11.時程中加入緩衝時間

           12.絕不讓經理叫程式人員縮減時間

           13.時程就像積木
CH10　每日編譯是你的好朋友

             1.每日編譯確保程式能正常運作

CH11　絕不妥協的抓蟲行動 

             1.確定知道問題的狀況

             2.確定會得到經濟上的回饋

             3.找出那些問題值得修好
CH12　五個世界 

             1.知道各種不同的軟體開發方式

             2.並明白自己處於哪一種  適用於哪一種方式
CH13　紙上原型製作 

             1.用紙筆先畫出介面架構
CH14　別讓架構太空人嚇到你 

             1.重點是解決問題
CH15　邊開火邊移動 

             1.持續release 持續開發
CH16　工匠技藝 

             1.做到最好
CH17　電腦科學中三個錯誤的想法 

             1.不同文化 不同觀點

             2.沒有對錯 重點是了解這樣設計 是為了哪種需求
CH18　雙元文化主義 
CH19　由用戶端自動取得當機回報，一切全自動！

             1.識別重複的當機

             2.選擇分類

bash script runs manually , but fails on crontab

今天碰到一個問題是
寫的shell script 手動run的時候  是正常可以執行的

這個script 主要是呼叫mysql 執行一些資料庫的動作

查了一下發現是一些環境變數的問題
在crontab不認得一些變數--> path裡面所設定的mysql變數

因此先在環境下

下  echo $PATH   

可以知道PATH的變數設定

之後再script增加 

export PATH="上面得到的設定"

如此就可正常執行


參考
http://stackoverflow.com/questions/14612444/bash-script-runs-manually-but-fails-on-crontab

sql exist vs in

這邊比較一下sql exist 和in的差別


Select * from T1 where x in ( select y from T2 )

LIKE:

select *

from t1, ( select distinct y from t2 ) t2 >

where t1.x = t2.y;

如果使用EXISTS，如同上述的查詢結果
select * from t1 where exists ( select null from t2 where y = x ) 

LIKE: 

for x in ( select * from t1 ) 
loop 
if ( exists ( select null from t2 where y = x.x ) 
then 
OUTPUT THE RECORD 
end if 
end loop 


因此當子查詢比主查詢小的時候使用in  ,反之則使用exist
外大內小=IN，外小內大=EXISTS








參考了http://tw.knowledge.yahoo.com/question/question?qid=1306041509015