织网的老男孩 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]

织网的老男孩:

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