他山之石，可以攻玉（一）

 

-------澄识-------------------

1、项目要当做产品做。要多想。产品是有延续性的。做项目时要考虑将来的延续，横向的通用性。并不是所有的业务系统都要一个模式，项目整个代码拷过来改改就行。把通用的东西抽出来，做成框架，有一定的规范限制，把具体的交给实现人去做。每个项目或日常都这样想想，都做一些重构，一年下来，也有不少收获。
2、业务部门做纯技术有困难，而且纯技术到最后，都是算法，没有很好的数学功底不行。如果想把某一门技术砖得很深，工作上需要有实践的机会，需要对该技术的很 多场景都了解，而业务部门通常只是用用，场景也只是一种。业务部门比较好的发展方向，是做系统设计，架构。结合自己的业务，找出最好的系统设计。在做系统 设计时，自然会想到业务。架构师发展到最后，不一定对某些技术了解的很深，更重要的是能够根据一个场景，给出好的解决方案，他甚至可能对JAVA并不熟， 但能给出好方案。
3、关于表达，需要知道对方想听什么。同一个问题，对100个人会有100种不同的答案。就是换位思考。有意思的是，当跟一个比自己层级高很多的人沟通时，因为很难知道对方真正想听什么，所以你跟他沟通会很难，他跟你沟通不难。

 

-------冯春培-------------------

昨天做了一整天的评委，原来以为6点半结束，却不知觉的搞到了10点。其间反复跟每个人都谈过我看的 标准 问题。
理想的P7：
1：把控 技术细节（不要只以解决问题为目标，而要深究原因）
2：专业和技术方向上能独当一面，你的主管把你往那一放，就能放心！
3：能跨 团队协调，能整合技术方案，解决棘手的事情
理想的P8：
1：把控技术细节
2：能有较强的整合跨部门技术和资源整合能力，从问题和价值出发，比较完善的有体系的思考和解决问题，思考问题能覆盖更广的维度（包括技术、团队、公司、 客户）
3：技术方案能考虑到到2--3年的延续性，年初能讲清楚年底自己到底要干成哪些具体可衡量的事情，以及这些事情带来的价值

-------岑文初-------------------

对于业务性需求变更，思维方式应当按如下顺序进行：

第一，是否已经有类似功能，需要做些改进就可以满足需求；

第二，没有类似功能，是否可以抽取部分已有功能，再做部分封装即可实现；

第三，完全没有可以复用的内容，考虑一下后续可能的业务需求。

也许上面的内容比较虚，但业务一定是根据场景来做出实际判断，而这三点其实就是一个理念——不断优化业务代码，复用的思考会促进不断地合理化结构（因为大部分情况下，复用性越小的代码其结构本身存在耦合性过强的问题）。

非业务性需求变更主要是指由于系统自身应用场景发生变化（包括处理的数据量、业务规则复杂度等），而使得需要对现有系统做结构性调整。