軟體開發這件事
本來是打算寫一下物件導向，寫著寫著就覺得應該先寫一下軟體開發，可是我又不是理論派，所以只好分享一下自己的經驗了。
底下所有內容皆屬於個人看法，如果有錯誤，請砲小力一點~謝謝
物件導向這一件事情
物件導向是一種抽象性的概念，將真實世界的需求，轉變成一個一個的物件，而這些物件又有自己的屬性及方法。透過這樣的方式彼此互動，達到模擬真實世界的需求。
當然這樣的模擬不可能會是無窮無盡的，不然你程式就寫不完了。所以我們在透過程式語言都是為了要解決某一個問題，要達成這個目標所使用的工具、方法。比如，要讓客戶的產品能夠直接在網路上賣出去，因此替客戶架設一個電子商務網站就是一個達成目標的方式之一。
客戶是為了要讓它們的產品能夠透過網路觸及到更多潛在的消費者，網站是一個解決方案；但這個目標不會只有一個解決方案，在本文僅以網站作為範例說明。
而這個電子商務網站並不一定只能用特定的技術來實作，可以用 php、asp.net、node.js 當然也包括了很久、很久、很久以前的技術：asp。
一般來說，在傳統的方式及學校裡面學到的知識，都會提到一個專有名詞：瀑布開發模式，記得是在學校的專案管理這門課裡面學到的。大致上的意思我們也不是專攻理論派的，就直接口語化的解釋一下：在軟體開發的過程當中會有許多腳色，分別處理不同的事情，其中最重要的是【確認客戶需求】，這件事情，我們交給一個叫做 PM 的人去負責
PM 可以是專案經理 ( Project Manager )，或是產品經理 ( Product Manager )，依據開發團隊的性質來決定，例如這一家公司是專門接案子進來做，我會認為他的這個腳色是專案經理；如果是自己公司有自身產品，那麼我會認為應該是產品經理。這兩者做的事情有很多都一樣，但是卻又有很多不同。學問很大，細節很多，我們就略過不表
而當需求已經被確定了，那麼就會交由系統分析師 ( System Analysis )，將需求分析出來，這個腳色我覺得最重要的事情是：確認什麼事情要做；而那些東西又是不用去做的。最終產出一份規格書，爾後，所有程式開發的部分都將以這份規格書當作依據。
好吧，上面那一段是理論上的，實務上我從來沒有看過能夠跟規格書對的上的程式碼，所以你們也就參考就好。
而在這個環節，還有一個部分叫做系統設計 ( System Design )，因為 SA 的部分做的事情是比較抽象一點的，而落在實務設計上，會經由 SD 這個腳色，將理論與實務合而為一，從而開出一份真正能夠實作出來的文件，在這個階段， SD 主要的工作項目就會是比較偏程式語言出身的人能看懂的東西，也就是建構出一個又一個的類別，寫一下這個類別有甚麼屬性阿、方法阿，之類的。請原諒我這一段沒有辦法給出太多經驗，因為在我的職涯中，沒看過 SD 這號人物。
這也是很多小公司的通病， SD 這個職務常常是不存在的
直接是由 SA 開規格給程式設計師，所以常常很多 SD 的工作，都落在了所謂資深程式設計師身上；或者是由 SA 順便做掉了這一部份的工作；或者是在認知不足的情況下；這部分工作就直接被忽略掉了。
甚麼？你說不可能忽略？怎麼不可能。你以為動輒數千行的 Legacy Code 一開始是怎麼來的呢？把一份規格書交給一個新人 PG 就出來了。在沒有資深工程師的帶領之下，新手 PG 一個人開副本打怪的結果就是只會用最原始的方式，一刀一槍的打拼，你說他不認真嗎？不一定。但是那份程式碼可能會有許多維護上的困難，而這些，是開發團隊成員的其他腳色感受不到、也不會理解的。出錢的那一位也不一定會理解，老闆都是看結果的，程式能不能跑？能跑。程式對不對？是對的。那就行了。誰還管 SD 這件事情？
這邊定義的新手PG屬於程式設計新人，沒有物件導向概念及程式開發背景
好吧，終於輪到 Programmer 了，說到這個腳色需要會的東西真的很多，但是，都不會好像也沒有關係，因為老闆不會知道。只有技術人懂技術人啊。
所以老板不會清楚軟體開發流程中，一個資深的程式設計師能夠起到的作用，絕大多數都是在看不見的地方。一樣是接收到規格書，資淺的程式設計師當然就是按照規格書一步一腳印的實作出來。而資深的程式設計師，還會考量很多事情，我們講最簡單的：以後好不好維護就是一個例子。
PG 其實就是將需求，用程式碼一行一行的處理掉，如果是不懂物件導向概念的人，很有可能會寫出難以維護的程式碼，而有概念的人，會將這些完成需求的程式碼，思考如何抽象出來共用。以後再添加新需求，或者是需求異動的時候，維護成本就看的出來了。
我就曾經看過好幾個例子，一樣是加一個需求，某位程式設計師的手法是複製貼上，然後前面加個判斷，原程式從三千行直接翻倍成長變成六千行。而另外一個的手法是先重構，然後抽象出來，接著才去改程式碼。前者工時花費一小時，眾人好評不斷；後者工時花費一天，承受抨擊無數。
去除掉政治因素的考量，我們純粹以程式設計師的角度來看這一件事情。你願意日常維護哪一份程式碼呢？
在這邊還是要呼籲一下，拜託不要別人的孩子死不完，你搞的不是公司，是接手你工作的其他同事。這個世界很小，遇得到的。
在軟體功能開發完成之後，通常會有人來複測這份程式碼功能對不對，這個腳色通常我會用 QC ( Quality Control ) 來稱呼。在其他公司可能會有其他的稱呼，對於這一點我有看到一篇文章寫得還蠻不錯的，提供給各位參考一下：QA、QC、傻傻分不清楚。
測試如果通過了，通常會交由另外一個腳色開始做產品發布的動作。這一段因為我涉獵不多就略過了。但是軟體從無到有，大概就是經過了這樣的流程來開發、產生出來的。
以上說得通通是屬於古早年代的作法。
以上說得通通是屬於古早年代的作法。
以上說得通通是屬於古早年代的作法。
是的。很悲哀的是，軟體產業在今天，還是有許多公司、企業，仍然奉行這一套軟體開發模式。在變動較少的產業、需求中，如果還在使用瀑布開發模式，那沒有問題。
但是在資訊變遷非常快速的現代社會中，這一套軟體開發方式無疑是被擊中了弱點。因為這一套走下來，往往耗時費工，當你發現了一個能夠賺錢的商業模式希望要趕快上線的時候，卻發現打完這一套組合拳，人家葉師傅已經打十個了。
怎麼那麼帥 怎麼那麼屌 怎麼那麼有腦袋
怎麼那麼罩 這麼多的才華 這麼少時間 怎麼做的到 - 熊仔 【凶宅】
我不禁想到背景音樂的這首歌，對阿，這麼少的時間，別的競爭對手怎麼做的到？？
其實就是另外一套模式：敏捷軟體開發
敏捷開發打破了先前瀑布模式的許多觀念，核心就是一個快速反應、持續交付的概念。而要達到這個目標，從骨子裡都與傳統的瀑布開發有著本質上的不同。
最淺顯易見的就是常常聽到的，敏捷樂於擁抱變化；而傳統的規格書你動他一個需求試試看，跟你說啦，會議就開不完了。
要Run敏捷也有很多限制，最大的一個限制當然就是老闆要支持。而 PG 成員可能自己本身的底子也要夠，因為要做到持續交付，單元測試是少不了的，這裡頭太多學問，等以後我有了解再分享給各位。