作者gn01838335 (寂静的生存者)
看板Soft_Job
标题Re: [徵文] 软体工程师入门
时间Mon Apr 4 22:59:46 2016
※ 引述《csfgsj (真理不灭)》之铭言：
: 前文已经拉太长不好阅读，用回文的方式接续~~
: : → NodeWay: 知道一万种DP果然是大师 在下才疏学浅只数得出二十来种 04/04 1
4:
: : 推 RunRun5566: 我理解的Design Pattern大概只有十几种 04/04 1
5:
: : → Masakiad: DP并非用一种或数个架构要解决「所有」问题。DP是在特定 04/04 1
5:
: : → Masakiad: context（姑且称环境）下产生的force(姑且称问题），可 04/04 1
5:
: : → Masakiad: 以用同一种pattern去解决该force。但很多人忘记必须考虑 04/04 1
5:
: : → Masakiad: 该pattern产生相对应的force可能影响整体架构。但其实DP 04/04 1
5:
: : → Masakiad: 是有强调可能照成的相对force。另外pattern不指code或定 04/04 1
5:
: : → Masakiad: 型的class diagram，因为他意义上是指解决该force的一 04/04 1
5:
: : → Masakiad: 种固定手法，依我的能力这可能很难言语讲明白。但patter 04/04 1
5:
: : → Masakiad: n包含由原概念产生的变形也算。所以pattern一直很少。 04/04 1
5:
: 从以上的叙述，我想我大概明白你的意思，也同意你的看法
: 因为你说出了一个重点：
: 「pattern不指code或定型的class diagram」
: 这跟OOSA、OOSD的论点比起来，清爽多了
: (做蛋糕为何一定要用大便做原料)
: 对你的看法，我的认知，其实可以用更传统的词汇来描述它
: Force =：特定环境下的特定作业(管理)需求。
: Ex：开一家餐厅，要如何营运
: Pattern =：为满足这个需求，所采取的作业模式、系统模型等..
: Ex：餐厅的营运模式：客人进来，先看菜单、点餐、上菜、享用、结帐、离开
: 而同样的作业模式，可能在若干其他不同的地方
: 虽然环境需求不见得完全相同，却能似曾相似地被使用着
: Ex：K 房的营运模式：客人进来，大阅兵、点？、上？、享用、结帐、离开
: (跟餐厅的营运模式很像？)
: 因此类似这种，被很多不同地方同时套用的作业模式
: 就成了作业设计规画者的一个，经典的问题解决方案
: 一个参考范例，一个模式罐头
: 范例收集的越多，则能解决问题的办法就越多
: 如您所述，当你收集了20种以上不同的模式罐头
: 也就差不多能应付所有的管理作业问题了(大架构)
: 系统设计，也就只是在这些模式罐头间，选择合适的套用
: 大的系统，可能要同时套用许多不同的模式罐头
: 之间的交错又可能衍生出新的组合型模式罐头来
: 反过来看，要分析一个现成的系统 (系统分析)，也就是在观察
: 该系统用了哪些模式罐头参考例内的模式
: 当该系统所有模式都清点解析完了，还不用涉入code的实作细节
: 对该系统的了解，就已经差不多达到七八成了
: 以上就是该系统的领域知识，这些都与程序语言无关
: 对於脑袋里没有什麽模式罐头观念的人
: 去看一个大系统的Code，只能说「只在此山中，云深不知处」
: 迷路了不说，还很容易被大量的code淹死
: 研究作业模式，了解模型的哲学，才能应付这种问题
我是一位初窥大道的工程师 对於一些想法想和同辈交流
我认爲Design Pattern 写到後面都是在解耦 并抽换物件
这东西像太极拳，当你忘记那些框框架架
善用基础物件导向特性，当遇到事情复杂度和过份耦合上升
才要考虑是否要重复利用再考虑采注入或者抽象复写方法
并理解不该把过分变动放到父类别等一些简单设计原则
恶...说真的除非你对於系统的domain充分了解，
才能设计弹性和可扩充功能SOLID 不然都是边做边修
我看过太多硬要用模式而产生失败的例子
建议初学者应该要加强语言特性和工具掌握度，并有基本OO概念
掌握Trace Code技巧，大概就踏出第一步
最後更上层进步法
怎样板美容方法等等，转接头鸭子等等一些生活例子
接下来则是学习掌握本质和让程式说话的技巧
好的程式是不用太多注解就会自己表达
软体这条路真不管真理 歪理 只要能解决业务端问题
不会有人管你怎麽写 除了工程师维护时会骂脏话
End
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 39.13.10.94
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1459781988.A.5CB.html
1F：→ Lordaeron: 这只是对DP 不懂的人的说词,君不见本版动不动就DP一下04/04 23:05
2F：→ Lordaeron: 就知,只要有DP, 随便都有好程式.04/04 23:05
※ 编辑: gn01838335 (39.13.10.94), 04/04/2016 23:07:13
※ 编辑: gn01838335 (39.13.10.94), 04/04/2016 23:10:32
3F：→ robler: 程式是用写的 不是用讲的 太多讲的一嘴好程式的人了04/04 23:26
认同 但是要当管理职要会嘴程式 XD 我也初窥大道，重构很多程式有感而发
※ 编辑: gn01838335 (39.13.10.94), 04/04/2016 23:29:56
4F：推 tyc5116: "只要有DP,随便都有好程式",1F确定? 04/05 00:10
5F：推 Argos: 注解喔 我还是觉得一定要至少写上大纲... 就算名字取得再好 04/05 01:02
6F：→ Argos: 你永远也无法保证下一个看你程式的工程师英文程度如何...XD 04/05 01:03
7F：→ ripple0129: 楼上注解是用中文写？ 04/05 03:03
8F：→ ripple0129: 我个人对DP的见解是，当你觉得遇见相同模式的问题能 04/05 03:09
9F：→ ripple0129: 很快且自然的联想到解决方法，而不用在那边想半天该 04/05 03:09
10F：→ ripple0129: 用什麽方式去处理，这就是学习DP优点。别走火入魔的 04/05 03:09
11F：→ ripple0129: 话，多学习一定是有益无害的。 04/05 03:09
12F：→ csfgsj: 不要忘了，OO的框架，可都是一种硬框架，用起来问题一堆 04/05 07:29
13F：推 lovdkkkk: /*唯一支持注注解*/ XD 04/05 11:25
15F：→ Argos: 用中文写有什麽奇怪的？公司里没有外国工程师阿 04/05 19:56
16F：推 RunRun5566: 我觉得物件导向是很美妙的设计 04/06 09:07
17F：→ Masakiad: 美丽的东西总是充满陷阱 04/06 17:07