※ 引述《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架构有什么看法(如果有接触过的话)?
谢谢