[答疑]为什么面试的时候不考核心域的知识

织网的老男孩 2019-1-24 16:35:

潘老师的《软件方法》强调主攻自己的核心域知识，而较为忽视非核心域知识—计算机基础等，工作中确实用不到，但是现在工作面试中就喜欢关注这些平时用不到的非核心域，每逢面试，很多都需要临时抱佛脚准备这些，用不上的东西又容易忘，各位怎么看，怎么应对的

。。。。:

我觉得潘老师的战略是对的，核心域的知识是核心竞争力，必须重视，但是也不是说非核心域的基础就不管了，非核心域的多体现在设计阶段，是这个阶段里面能力的体现

织网的老男孩:

明明是搞java业务开发的，大家现在都揪着jvm的种种不放，对工作基本无益。 现在市面招聘感觉有点像高考选拔，考察的知识不一定有用，但是你要会，考察范围基本默认圈定了。:

现在的说法不是"招聘造航母，入职拧螺丝"吗？~~

大多都是这样的。比如阿里。

现在业界java面试，jvm，各种锁问题，是一大重头戏，应用开发基本是用不到的，这些基本都是中间件解决了的。于是乎，大家都苦哈哈的研究jvm, 各种锁。而甚至忽略了基本工作技能的修炼、提高。

深切感受到人力学习资源的浪费或者说个人时间的浪费，都在做无用功。和高考应试很有点像了，面试结束找到工作了，突击的知识点，长久不用，又容易生疏了。再要面试，再撸一遍，即使平时不断学，用不上的东西，也比较难深入

UMLChina潘加宇:

@织网的老男孩 因为面试者本身就没有掌握业务建模、需求、分析的技能，所以只好考一些自己懂的技能。如果我是面试者就不一样了嘛，一道一道题都有讲究。

织网的老男孩:

是的，我也这样认为的，很多互联网公司软件开发这块是没有章法的。 但是，又得面对这种不学不行的局面。所谓的知识焦虑。

UMLChina潘加宇:

书里也有讲

很多能够带来利润的系统，它的核心域却没有那么多人去研究。很少有类似这样的书，把一家电厂的流程，各种概念之间的关系，用某种方式（UML的类图、序列图、活动图，以前的数据流图、E/R图）表达得清清楚楚。

在这方面，不少媒体有误导。媒体会访问某些"知名程序员"对建模的看法，得到的回答可能是"对我来说不重要"。这里面的原因是：基础设施领域的程序员更容易得到媒体青睐成为"知名程序员"， "芯片"、"操作系统"、"编译器"等词汇上的光环更容易撩拨媒体从业人员的兴奋点。

开发团队A研发出了Aware，获得市场的认可，开发团队B利用Aware研发出Bware，也同样获得市场的认可。根据我们上面所说的，研发Aware和Bware各有各的复杂度。但是需要批评一种现象——开发团队B里的某个开发人员在使用Aware的过程中产生了错觉，以为研发Aware才是"技术"，把大量的精力用来思考Aware的核心域知识，却对Bware的核心域知识不屑一顾。不客气地说，媒体热爱的一些"知名程序员"就是以上描述的实例。一边拿着公司的薪水，却不好好思考如何吃透公司的核心域做好公司的项目，把大量精力投入到自己的小爱好上，在网络上博得名声。

某开发人员喜欢钻研"底层"。明明本职工作是编写一段计费的C#代码，他偏偏要花时间深入研究到编译器、操作系统甚至硬件，而且确实也搞清楚了一些门道。虽然工作是耽搁了，但该开发人员却获得了"勤奋好钻研"的名声。其实还有另一个更值得钻研的"底层"：怎样才能使这段代码更容易维护和扩展？这段代码达到的功能和性能对涉众意味着什么？……

过分热衷于钻研"底层"，这样的行为更像是偷懒而不是勤奋，毕竟比起离开电脑去搞清楚质管部和生产部之间有什么利益上的冲突，研究MSIL的语法要容易得多，愉快得多。

所谓"底层"也只是另一个领域的知识，那个领域自有另外的人去研究。玩票式的钻研，在真正专注研究这个领域的研究者看来，实在是不值一提。但是人性的弱点如此，正如钱钟书所说："蝙蝠碰见鸟就充作鸟，碰见兽就充作兽。人比蝙蝠就聪明多了。他会把蝙蝠的方法反过来施用：在鸟类里偏要充兽，表示脚踏实地；在兽类里偏要充鸟，表示高超出世。向武人卖弄风雅，向文人装作英雄；"[钱 1982]

织网的老男孩:

是的，就是看到书里面相关内容了。

===广告分隔线===

主题:	软件需求设计UML全程实例剖析
开课时间:	2019年3月9-10日(周六、周日)（9:00-12:00，13:30-17:30）
上课地点:	广州
费用：	每人2400元，含午餐。交通、住宿费请自理。可以开增值税专用发票和增值税普通发票。
微信报名：	18758097122
QQ报名：	1493943028
Email报名：	[e-mail]
咨询电话：	18758097122
报名交费：	步骤一、报名 教室座位有限，需要先报名。请通过以上任何联系方式告知我们您的姓名和单位，以便我们预留座位。 步骤二、交费 按以下方法办理交费，将交费凭证（截屏或照片）、发票单位名称（如果要开）通过以上任何方式告知我们。我们收到费用后会给您发听课证，听课证是一个pdf文件，上有详细听课地点和您的座位号。听课证上有详细地址和座位细节。 不方便现场交费，因为需按交费顺序安排座位，而且现场只有老师，无人收款。 如果您交费后因故未能参加，您的名额和上课时间将会一直保留。 交费方法： （1）支付宝支付到[e-mail]，手机扫描二维码或PC上点击付款图标即可付款 （2）微信支付到18758097122 （3）如果是公司财务汇，可以汇到负责UMLChina商务事宜的以下公司账号: 户名：杭州先思软件技术有限公司 帐号：3310 6594 0018 0100 29896 开户行：交通银行杭州滨江支行
课前准备：	请下载以下资料： （1）最新版本的本次课程训练幻灯 http://www.umlchina.com/training/slide.htm （2）建模软件EA30天试用版 http://www.sparxsystems.com/products/ea/trial/request.html （3）UMLChina模型模板 http://www.umlchina.com/training/myproject.rar （4）《软件方法（上）》第2版，自行到书店购买，勘误：http://www.umlchina.com/book/errata2ed.htm （5）《软件方法（下）》目前公开内容，请在http://www.umlchina.com/book/softmeth0809.pdf下载 （6）课上可以专门以学员的项目作为主要讨论项目。如果您希望在课上讨论您的项目，麻烦下载http://www.umlchina.com/training/project.doc 填好后发给我们，以便老师针对您的项目相关领域事先做准备。

[训练介绍]

软件开发中，需求是解决“产品怎样好卖”的问题，设计是解决“降低生产成本”的问题。二者相辅相成，缺一不可。而且，不能相互取代。要迈向“低成本制造好卖的产品”的境界，并非喊喊口号就能达到，需要静下心来，学习和实践各种技能。

在这个强调“做减法”的时代，建模是正确帮助您“做减法”的绝佳工具。

本训练就是教授如何使用UML2.5相关的需求和设计技能来全程实例剖析一个系统的过程。

本训练对每个开发工作流，结合讲解、做练习巩固、应用到实际项目三种方式，展示使用UML2.5相关技能开发软件系统的全过程，解答实际应用中的疑难细节问题。

[学员要求]

有一年以上项目经验的需求或设计（编码）人员。不需要您有“UML基础”，只需要您有项目经验。欢迎学员携带自己的项目来听课，由专家在现场进行剖析。

[专家]

UMLChina首席专家 潘加宇。在1999年还是一名程序员时，利用业余时间创建了UMLChina，潜心研究软件需求和设计技能。2002年开始对外提供UML需求和设计的技术指导和训练服务，到现在为止，已经上门为超过280家的软件组织提供服务，覆盖了国内各个领域的领袖企业，包括通信、企业管理、电子商务、房地产、网络游戏、地理信息、物流、数码设备、医疗设备、工业控制.....等领域。

[课程大纲]

1. 概论
--需求和设计的关键区别
--核心工作流
--UML的统一
--使用UML开发过程、工具、资料介绍
2. 愿景
--愿景的要点
--如何揣摩愿景
--项目实作：愿景 
3. 业务建模
--组织的外观和内观
--选取合适的建模业务单元
--业务执行者和业务用例
--业务序列图
--改进业务序列图
--项目实作：绘制业务用例图、业务序列图 
4. 需求
--系统执行者要点剖析
--系统用例要点剖析
--从业务序列图映射到系统用例图
--项目实作：绘制系统用例图 
--书写用例规约
--项目实作：书写用例规约 
--通过关系整理用例
--需求启发技术
5. 结构分析之类图
--抽象和封装
--识别类及其属性
--识别类之间的泛化
--识别类之间的关联
--项目实作：绘制类图 
--彩色建模技术
--典型分析模式
6. 行为分析之序列图
--序列图精要
--用例、类图、序列图的互动
--专家原则和单一责任原则
--老板原则和聚合根
--可视原则
--项目实作：绘制序列图 
7. 行为分析之状态图
--状态图、类图、序列图的映射
--状态
--事件、动作和转换
--层次状态、历史状态
--转换执行序列
--分层和细化
--状态图和代码的映射
--项目实作：绘制状态机图 
8. 架构和设计
--存储层的映射
--数据源层的映射
--业务层的映射
--界面层的映射
--领域驱动设计
9. 改进指南
--根据团队情况改进
--小步前进
--正确的改进心态

以上时间分配会根据项目特点和训练进程调整。