他山之石,可以攻玉(一)

时间:2021-03-25 21:47:53

 

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

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

 

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

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

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

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

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

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

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

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

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