※ 引述《superpai (超級白)》之銘言：
: ※ 引述《Luos (Soul)》之銘言：
: 我只想問改用 Git 的風險在哪裏...
: Git又沒有很難也不用錢也不會幫你code加入bug
: 也不是最新的科技，也沒聽過不穩
前文恕刪,看了這一連串回文,分享一下心得好了,大家當作聽聽故事(有點長)
然後再藉這個標題問些問題,聽聽大家的意見XD
想當初研所畢業做的東西,因為以學生時代來說
我覺得我寫的東西算是有一定規模的程式了,寫到最後覺得架構變很臭
所以在畢業,退伍,進社會後,因為新人一開始有蜜月期
就趁著快退伍及蜜月期這時候看了UML,Design Pattern,敏捷開發等書
然後在一開始進公司時,前輩拿了一些資料給我,其中一些內容是寫公司的架構
"為了便於新人學習,所以程式@#$%^&*()",簡單說就是引用工研院的程式架構MSD
MSD意思就是把程式分成Model,Status,Design,將程式分為數個次模組
每個模組有各自的狀態切換,然後將其轉換為程式,細節就不說了
重點來囉~~~~
看完說明,再看程式,心裡馬上就開罵了,這三小???寫那麼爛
一開始不知道是MSD是由工研院傳下來的,還以為是PLC部門的前輩那邊導入的
(我在設備製造商工作),想說這架構可能比較適合PLC吧
日後聽到PLC的前輩也在嫌這架構,理由是,沒把圖畫出來根本不知道程式在寫什麼
很多同事還是先寫完程式再補圖,就更看不懂了
然後畢竟自己是新人,所以默默的開始自己思考架構的改良(蜜月期的人是滿閒的)
也沒跟其它人說,一方面自己是新人,一方面導入的前輩還在,亂講話是會得罪人的
(重點!!新人還是安靜的好),最後沒有用出來,畢竟沒有經過什麼磨練
等第一次的case分到我身上,上戰場後,恩~~~程式修改的效率真的有改進空間
有了第一次實戰經驗,對於公司程式的架構,看法稍微不一樣了
"架構不好,但是並非沒有可取之處,雖然還是有很多問題,大體來說,還是要改"
再經過數次case的磨練,對於Design Pattern,Refactor等等的概念也有更進一步的體會
以及公司的心靈陶冶(???)看法又變了
"改架構再怎麼說對公司都是風險,所以不會亂動,
但如果針對目前的架構作一點小小的改良,讓其它人可以接受這小小的改變
以後再一點一點的來改良,對效率有幫助,遇到的風險也較小"
這時大概工作一年半了,也比較有經驗了,便針對目前公司的架構作了一點小小的改良
弄成Sample,寄給主管,也許考慮的不是很周全,但至少比起剛出社會,我拿的出一些東西了
恩~~不過沒被接受,沒被接受我是可以理解的,
主管有主管的考量,而且提出來的東西不見得禁得起考驗
爾後因為部門組織的變動,和主管中間插了一層(以下稱小主管)
大小主管都算是好主管,但是我覺得小主管的眼界不夠寬,而且不太勇於嘗試新事物的感覺
爾後提的一些建議一律的答案便是
"我們的程式架構雖然有很多改進的空間,但是堪用"
甚至於我要一個實驗用機台(還說日後可以拿來教導新人)作一些測試,也沒成功
牽涉到錢的東西,不被接受我也認了
後來,我接觸到了版本控制Git這個東西,覺得很不錯,我甚至想不到有任何風險
因為公司到現在程式的管理都是,今天開一個20140519的資料夾,
明天再開一個20140520的資料夾,導入Git總沒問題了吧?還是免費的東西耶!!
不但免費,現在也發展的很穩定了(應該是吧....XD)
mail給小主管,cc給主管,小主管的回應是"有機會分享給其它同仁"
此後便沒了下文
現在,我已經默默的打開104.......哈
心得:
1.新人還是安靜點,說太多沒人會理你
2.自己有好東西自己留著,如果人家主動想要學再教別人
3.如果教別人要花很多時間,人家還不見得聽的懂,那就直接跟他說"我不會"
(分享一下我老師說過的話XD)
另外,想問問各位前輩,對於上面說到MSD架構有什麼看法(如果有接觸過的話)?
謝謝