[心得]從小就該學寫程式？

晚安，2016年又過了一周，今天是1月9號，

有時真的會感嘆時光的飛逝。

越來越多人投入軟體工程領域，

這實在是一件好事，同時也代表著軟體產業確實有著這樣的需求，

轉職成軟體工程師前你該考慮的三件事 ，提出了一些反思，

恰巧讓我有些共鳴，其實我認為未來二十年軟體領域將會進入一個黃金期

以一個年紀30歲的青年來說，這二十年將會是他人生的精華所在。

也就是說如果你現在處在軟體相關產業的人，

真的是恭逢其時，至少二十年內，你不會缺少機會與舞台，

再來若你不在軟體產業，準備好迎接衝擊吧，

是挑戰也是機會，電子商務、智慧/自動車、智慧宅、綠能、…

這股浪潮將會像是工業革命般改變全世界、全部的產業。

不要覺得不干自已的事，改變已經開始了。

這二十年的到來，的確讓人振奮的想要跳起來，

但是我看到很多的人提出的觀點，保持著懷疑的態度，

就是「讓孩子從小當工程師」

我完全贊成小孩需要學點程式，因為這有助於邏輯思考，

但重點在邏輯思考，而不在程式啊!

但重點在邏輯思考，而不在程式啊!

但重點在邏輯思考，而不在程式啊!

這是柯P在台大演講，裡面對邏輯思維的養成，

相當值得一看(建議用1.5倍速)，

另外，我認為未來二十年後奇點將至，

軟體或許將會變得M型化，

簡易的需求將會有更快速的工具去滿足，

Blog、購物網站、App或是遊戲，

都能用套裝的工具去達成，而且可以有高度客制化的能力，

自我搭建、研發的成本將高於服務，一般的公司多會使用PaaS、SaaS的服務，

M型的一端，將會是以一檔百的工程師，而且業界將會求才若渴，

M型的另一端，則是只會應用其服務的工程師，

當其應用越變越簡單跨過了工程師的門檻時，

工程師就與User沒有兩樣了。

當然這沒有不好，這可以讓一般User更專注在自已想實踐的部份上，

而且還有自我還有高度客制化的能力，

這是進行式，當然要完全取代工程人員，

短期內不太可能會發生，

努力讓自已走向M型的另一端，不要停留在安逸的地方，

學無止盡，一起加油吧。

二十年說長不長，說短不短，我們等著看。

本周其它文章推薦

• 12-Factor 方法論

• 做開源軟件項目會用到的服務簡介

• R.I.P IE 

• 一個好的界面設計應該注意的75 個原則

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]

[轉貼]程式人產能之謎

原文

本文開始:

留意正負產能差異原因，而不是指標結果，例如不適任者的虛耗與難以專注工作的環境

在程式人的產能差異上，你可能聽過不少的傳說，像是「程式人間有5:1或10:1產能差距並不是種曲解」、「90%程式碼是由10%程式人撰寫」、「優秀軟體開發者價值遠勝平庸開發者10,000倍」等，產能差異在哪？單純關注個別程式人的正向產能，是對的嗎？

產能評量的迷思
Joel Spolsky、Robert C. Martin、Bill Gates分別對產能差異提出了以上的想法，Steve McConnell在〈10x Software Development〉中亦提到「許多研究發現，產能與品質在個體甚至團隊間會有10:1的差異」，總之，任何10次方的產能差距你可能都有聽過，作為管理者，大多會關心如何評量開發者產能，期待促進專案整體的生產力。

只是要量測程式人的產能相當困難，程式設計是個知識工作，先不論其本身有許多難以量化元素，如果為了評量開發者產能，訂出了許多量化指標，就會出現許多收集點數的荒謬行為。那麼，這些10次方產能差距的結論到底從何而來？Joel Spolsky是研究學生用相同技術做相同作業花費的時間，以及取得的作業分數，Steve McConnell研究中談到的是創建、除錯一個程式需要的時間，以及程式的大小、速度、找到的錯誤等。

從收集而來的資料看來，產能差距似乎指向時間與品質，因而有人試圖從中建立指標，期待於每年、每季甚至每月，提前並切割地評量程式人的產能表現，然而實務上不會讓兩個開發者做相同的任務，Tom Cargill也說過：「前90%程式碼耗掉了90%開發時間，剩下的10%需要另外90%的開發時間」，這說明了提前與切割地進行產能評量也是個問題。

從管理角度來看，不可否認地需要某些指標來評量開發者好壞，其實當我們覺得某開發者極具生產力時，實際上，心中確實為他建立了一些指標，也許是類似功能另一開發者花了一整月開發而他只花一星期，某問題另一開發者花了一星期無法除錯，而他接手僅花一天就順心解決……那麼，原因呢？與其就結果來論斷他是否有生產力，不如進一步探究為何他擁有這樣的生產力。

程式人的三種美德
在《Programming Perl》中，Larry Wall鼓勵程式人應培養三種美德：「懶惰（Laziness）、沒耐性（Impatience）與驕傲（Hubris）」。懶惰就會讓程式人努力減少整體工作量，寫一些能節省人力的程式，並寫下這個程式的文件，免得要親自回答許多問題；沒耐性的程式人無法忍受電腦怠惰，寫的程式就會儘可能讓它閒不下來，而不是停下來等待你的需求，驕傲的程式人會寫下旁人無可挑剔，而本身極度自豪的程式。

這三種美德看來就對應了先前談到程式人產能差距指向的時間與品質，探討程式人生產力祕訣的《The Productive Programmer》書籍前言中，也談到即使沒有直接提到這三個名詞，然而這三種美德將會在該書中擴展開來。

程式人的三種美德可以拆開來看，也可以合併來看。想要減少整體工作量有個簡單方式，就是不做重複的工作，電腦絕對比你擅長重複工作，只要告訴它怎麼做，如果發現常常用滑鼠在電腦上重複地走來走去，那就想辦法用工具或寫程式把這個過程「錄」下來，如果發現經常要輸入相同的指令，那就想辦法用工具或寫程式讓這個過程自動化，如果發現類似專案間有些個別差異而增加了溝通麻煩，那就讓它們標準化，實際上會發現，不少現成工具就是這麼創造出來的，是否能瞭解、善用甚至創造出這類工具，就決定了優秀與平庸程式人間的產能差距。

重複的程式碼也是一種重複的工作，無論形成重複的原因是否來自程式碼的剪貼，重複會造成程式碼後續維護時整體工作量的增加，將明顯或三次以上的程式碼重複加以適當重構，透過適當設計讓程式有彈性，就構成了程式人第三種美德。實際上，許多文件、書籍在教導或傳承的就是這三種美德，作為一個進取的程式人，多半會關心如何彌補自身與優秀開發者的這段差距，以提升自我程度為自豪。

程式人的三種罪行

「90%程式碼是由10%程式人撰寫」是Bob大叔在〈One per Pixel〉文章中談到的，文中後續還講了「其他90%的人寫了剩下10%程式（而10%的那些人還得修正這些程式）」，他提到優秀的程式人其實不多，只有10%或許太誇張，也許是20%，也許是30%。實際上在職場生態中確實如此，程式設計對許多人來說，只是份工作，追求優秀與產能這種事，大多數人並不關心。

懶惰、沒耐性與驕傲是程式人的三種美德，這是幽默地從正面意義去看待這三個負面詞語，如果用負面方向來解釋這三個詞語，就是不少從事程式設計工作者的三種罪行。

就懶惰這方面來說，大多數從事程式設計工作的人，就真的只是懶，他們懶得去熟練語言與工具、懶得去探究問題發生的原因，也沒耐性去學習新的東西、沒耐性寫下文件，對於程式本身不會有責任感，程式能動就好，不會去管程式碼的重複、不在意程式的溝通性，甚至隱藏程式碼中的錯誤，隨意地在不同元件中自私地進行各式程式碼侵入，他們建立自己的舒適區，如果你基於改善程式品質的立場去冒犯了他們，他們還會有各式傲慢的回應。

無論是文件或書籍總愛討論如何提升程式人產能，實際上優秀的程式人會自動追求這類自我提升，在關注產能之時，也許不該去評量這類程式人的產能，指標對這類程式人經常是種傷害；真正該注意的是，如何評量出「負產能」，負產能程式工作者建立出來的程式，後續還得耗費優秀程式人來修正，一正一負之下雙方產能抵消歸零也就算了，優秀程式人如果因此心生委屈而離開了，負產能與優秀程式人間的差距，就不是10,000倍可以比擬了。

David Parnas在有次訪談中被問到「軟體工程中最常被忽略的風險是什麼？」他的回答是「不適任的程式工作者（Incompetent programmer）」，並談到「差勁的程式工作者，一年可以輕易創造兩個新工作」，這跟Bob大叔說的類似，因為還得有人來為不適任程式工作者寫的程式進行善後，技術債（Technical debt）這名詞似乎很適合拿來形容這類情況，只不過欠下技術債的是不適任程式工作者，卻得由優秀程式人來償還。

給程式人專注的環境
產能這方面有個人因素，實際上也有環境因素，在關注個別程式人產能之時，別忽略了給予程式人可以專注的環境。

在《Peopleware: Productive Projects and Teams》一書中，就指出：「管理者的工作並不是叫人去工作，而是創造讓人想去工作的情境」。許多公司都會有類似的情況……規範員工每日的產能指標，然後實際上每天不斷地把員工從工作情境中拉離（電話、郵件、開會……），最後在每月、每季或每年考核時，再來指責程式人為何產能如此之差，打擾者也許不只是管理者，不適任程式工作者也經常會做這種事。

關注正向產能當然是好事，只不過程式設計這領域，沒有真正適用的評量，任何基於自我想像的指標傷害性就更大了，不適任程式工作者為了符合指標，也總是能「下有對策」；與其關注程式人的產能，不如關注優秀程式人用了哪些方法提高產能，讓他們能發揮，並且留意不適任程式工作者的行為。

更重要的是得留意，產能差異的謎團也許不只是來自程式人，也有可能是環境或本身，想想看，算過自己打電話打擾其他開發者的次數嗎？這類的指標，也許是從沒有被考量進去的！

作者簡介

林信良

因在網路上經營「良葛格學習筆記」（openhome.cc）而聞名，曾任昇陽教育訓練中心技術顧問、甲骨文教育訓練中心授權講師，目前為自由工作者，專長為技術寫作、翻譯與教育訓練。喜好研究程式語言、框架、社群，從中學習設計、典範及文化。閒暇之餘記錄所學，技術文件涵蓋C/C++、Java、Ruby/Rails、Python、JavaScript、Haskell等多個領域。 

心得小結:
美德與惡德只是一線之隔，保持謙遜的態度。別讓美德成為惡德。
專注真的好嗎？ The Clean Coder 作者 Bob大叔說過「不要進入flow zone」，
原因是進入這個狀況，或許會有極大的產出，但是不容易顧及全面，依本文所說反而容易產生負產能，「挖一個坑來補一個坑」是很容易發生的。如何建立一個良好的工作環境，不讓單一工程師進入流態，而是讓整個團隊專注於一項功能/產品 進行開發，我想這是專案管理上的重要課題。

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]

[轉貼]常用 Git 命令清單

原文

作者:阮一峰
--

我每天使用Git ，但是很多命令記不住。

一般來說，日常使用只要記住下圖6個命令，就可以了。但是熟練使用，恐怕要記住60～100個命令。

下面是我整理的常用 Git 命令清單。幾個專用名詞的譯名如下。

• Workspace：工作區
• Index / Stage：暫存區
• Repository：倉庫區（或本地倉庫）
• Remote：遠端倉庫

一、新建代碼庫

# 在當前目錄新建一個Git代碼庫
$ git init

# 新建一個目錄，將其初始化為Git代碼庫
$ git init [project-name]

# 下載一個項目和它的整個代碼歷史
$ git clone [url]

二、配置

Git的設置文件為.gitconfig，它可以在用戶主目錄下（全局配置），也可以在項目目錄下（項目配置）。

# 顯示當前的Git配置
$ git config --list

# 編輯Git配置文件
$ git config -e [--global]

# 設置提交代碼時的用户信息
$ git config [--global] user.name "[name]"
$ git config [--global] user.email "[email address]"

三、增加/删除文件

# 添加指定文件到暫存區
$ git add [file1] [file2] ...

# 添加指定目錄到暫存區，包括子目錄

$ git add [dir]

# 添加當前目錄的所有文件到暫存區
$ git add .

# 删除工作區文件，並且將這次删除放入暫存區
$ git rm [file1] [file2] ...

# 停止追踪指定文件，但該文件會保留在工作區
$ git rm --cached [file]

# 重新命名文件，並且將這個命名放入暫存區$ git mv [file-original] [file-renamed]

四、代碼提交

# 提交暫存區到倉庫區
$ git commit -m [message]

# 提交暫存區的指定文件到倉庫區
$ git commit [file1] [file2] ... -m [message]

# 提交工作區自上次commit之後的變化，直接到倉庫區
$ git commit -a

# 提交時顯示所有diff信息
$ git commit -v

# 使用一次新的commit，替代上一次提交
# 如果代碼没有任何新變化，則用來改寫上一次commit的提交信息
$ git commit --amend -m [message]

# 重做上一次commit，並包括指定文件的新變化
$ git commit --amend [file1] [file2] ...

五、分支

# 列出所有本地分支
$ git branch

# 列出所有遠端分支
$ git branch -r

# 列出所有本地分支和遠端分支$ git branch -a

# 新建一個分支，但依然停留在目前分支
$ git branch [branch-name]

# 新建一個分支，並切換到該分支$ git checkout -b [branch]

# 新建一個分支，指向指定commit$ git branch [branch] [commit]

# 新建一個分支，與指定的遠端分支建立追踪關係$ git branch --track [branch] [remote-branch]

# 切換到指定分支，並更新工作區
$ git checkout [branch-name]

# 建立追踪關係，在現有分支與指定的遠端分支之間
$ git branch --set-upstream [branch] [remote-branch]

# 合併指定分支到當前分支
$ git merge [branch]

# 選擇一個commit，合併進當前分支
$ git cherry-pick [commit]

# 删除分支
$ git branch -d [branch-name]

# 删除遠端分支
$ git push origin --delete [branch-name]
$ git branch -dr [remote/branch]

六、標籤

# 列出所有tag
$ git tag

# 新建一個tag在當前commit
$ git tag [tag]

# 新建一個tag在指定commit
$ git tag [tag] [commit]

# 查看tag信息
$ git show [tag]

# 提交指定tag
$ git push [remote] [tag]

# 提交所有tag
$ git push [remote] --tags

# 新建一個分支，指向某個tag
$ git checkout -b [branch] [tag]

七、查看信息

# 顯示有變更的文件$ git status

# 顯示當前分支的版本歷史
$ git log

# 顯示commit歷史，以及每次commit發生變更的文件$ git log --stat

# 顯示某個文件的版本歷史，包括文件改名
$ git log --follow [file]
$ git whatchanged [file]

# 顯示指定文件相關的每一次diff
$ git log -p [file]

# 顯示指定文件是什麼人在什麼時間修改過
$ git blame [file]

# 顯示暫存區和工作區的差異
$ git diff

# 顯示暫存區和上一個commit的差異
$ git diff --cached [file]

# 顯示工作區與當前分支最新commit之間的差異
$ git diff HEAD

# 顯示兩次提交之間的差異
$ git diff [first-branch]...[second-branch]

# 顯示某次提交的元數據和内容變化
$ git show [commit]

# 顯示某次提交發生變化的文件
$ git show --name-only [commit]

# 顯示某次提交时，某個文件的内容
$ git show [commit]:[filename]

# 顯示當前分支的最近幾次提交
$ git reflog

八、遠端同步

# 下載遠端倉庫的所有變動
$ git fetch [remote]

# 顯示所有遠端倉庫
$ git remote -v

# 顯示某個遠端倉庫的信息
$ git remote show [remote]

# 增加一個新的遠端倉庫，並命名
$ git remote add [shortname] [url]

# 取回遠端倉庫的變化，並與本地分支合併
$ git pull [remote] [branch]

# 上傳本地指定分支到遠端倉庫
$ git push [remote] [branch]

# 强行推送當前分支到遠端倉庫，即使有衝突$ git push [remote] --force

# 推送所有分支到遠端倉庫
$ git push [remote] --all

九、撤銷

# 恢復暫存區的指定文件到工作區
$ git checkout [file]

# 恢復某個commit的指定文件到工作區$ git checkout [commit] [file]

# 恢復上一個commit的所有文件到工作區$ git checkout .

# 重置暫存區的指定文件，與上一次commit保持一致，但工作區不變
$ git reset [file]

# 重置暫存區和工作區，與上一次commit保持一致$ git reset --hard

# 重置當前分支的指針為指定commit，同時重置暫存區，但工作區不變
$ git reset [commit]

# 重置當前分支的HEAD為指定commit，同時重置暫存區和工作區，與指定commit一致$ git reset --hard [commit]

# 重置當前HEAD为指定commit，但保持暫存區和工作區不變
$ git reset --keep [commit]

# 新建一個commit，用來撤銷指定commit
# 後者的所有變化都將被前者抵消，並且應用到當前分支
$ git revert [commit]

十、其他

# 生成一個可供發佈的壓縮包
$ git archive

[[[本誌僅為個人分享與記錄，不保証內容永久正確性，如有謬誤、疏漏或侵權還請留言告知]]]