2014 動向整理

從元旦開始，接觸到FP的觀念，然後就湧進了許多在OO( 我是用c# )沒涉獵過得觀念以及語言的元素，一時之間眼花撩亂。簡單的說，開發的素材變得更多樣了。有好處，不過對現在的我，帶來了一些困擾。

太多樣化的學習，會變得沒有著力點。可在編程的領域上，有許多的面向都是值得精進的，可時間與人力/資源是有限制，還是要做取捨。在這裡就按照自己的胃口來搭配吧。

語言的選擇， C# 與 Clojure。 C#是OO語言。 Clojure 是FP語言。
開發框架， MVC ,  ORM , 另外 AOP 與 SOA 僅在表面的認知階段 。

設計的部份(SD)，  Design Pattern 在進階的OO開發需求上，是不可或缺的。但在某個角度而言，是因為OO語言本身的限制，才造就了一些Pattern的發明，這個觀點是從FP語言上，FP語言對某些Pattern提供的用途，是直接榜定在該語言特性上的。
所以對DP的認識，除了利用DP進行工程師溝通設計的共通語言之外，其二是作為開發程式的策略工具，第三點，透過DP要實做的問題類型，用OO語言與FP語言來比較實做上的差異，進一步了解OO與FP所擅長的領域。

分析的部份(RA/SA)，為了達成某個目的，就會挖掘該目的要解決的問題，我們開始挖掘問題背後的構成元素，也許是需要更細分的小問題，也許是足夠讓SD進行實做的元素。這是分析角色的職責所在。
這個部份，需要從 IDDD , DDD 進行分析能力上的打底。然後配上 Poeaa 與 analysis Pattern 對分析這一層次所遇到的問題/樣式進行命名定位，減少重新發明樣式的狀況。
RA/SA 扮演了很重要的起頭角色，整個開發的生命週期，都是為了達成客戶的目標起頭的。若是A的時候，漏掉一兩個關鍵的議題，那之後要在修補設計上的結構，代價就很大了。



以上的部份，各種層次的技術與模型，都可以被視為工具，而工具是拿來達成某個目的的。
所以

先是有了 目標。
然後透過  DDD 進行 Domain Model 的分析 ，
        或許馬丁花在 Analysys Pattern 上分類出來的 pattern符合本次的目標
        也有些是符合 POEAA 裡面整理出來的 Pattern
整理完整個需求的 DDD後

開始進行實做上的開發，有些情境符合一兩個DP的情境，就套上合適的DP。
而在這一階段，也會針對問題選擇合適的框架來輔助開發。

一層一層的工具，都是為了完成目標而存在的。這麼多的技術，還是必須有一個目標，才會有價值。

所以這裡就跳出了一個不一樣的學習標的。 資料科學。

從資料中尋找分析有價值的目標。
例如從資料中挖掘出大部分人的不滿，或說沒被滿足的需求，那這就是一個潛在的市場。
又或者，利用大量資料，來建立決策的輔助工具。這是我覺得資料科學有價值的地方。