BingerSoft

兴趣方向:1)大数据/数据分析; 2)信息安全/网络安全; 3)人工智能; 4) 云计算/微服务; 5) C/C++/Java/Python/Go.     
C/C++群:26678700     
交流QQ: 704839634,申请时请说明来自C++博客网友
合作: 1) 可全职远程办公开发; 2) 有一套Go+C+Python开发的行业短信云平台可出售。

局限思考

        我们长久以来被灌输固守本职的观念,这种观念如此强烈,以致将自身跟工作混淆。
    一个员工进一家公司,常常被分配到一个领域里,而且按开发语言划分居多:c++组,java组;前台,后台。
       大部分人,进入一个组,就把自己职责固定在这个组内。一个c++组的开发人员,一般人不会去主动去做点java开发,特别是中大型公司,人员充足,主管不会去分配一个组的人去做另一个组的工作。
       但是,常常有一种现象:你发现一小部分人,常常不甘寂寞,工作职责是C++开发,他也对java或c#学习兴趣浓厚,还常常找机会说服主管或同事让他试一试,时间一长就真有这个机会,最后你发现,这类人自学能力强、适应能力强,常常有更好的上升空间。
       而那些大部分人,固守本职,随着时间推移,最后连本职工作也没有兴趣了,工作谈何绩效,晋升谈何机会。
       当一般人被问起如何维生时,大多数人都是叙述他们天天在做的工作,而不会扩大范围去说明他们企业的目标是什么。多数人认为自己对于整体只有很小或毫无影响能力。他们在自己的工作岗位上埋首苦干,结果把自己的责任局限于职务范围之内。
       当组织中的人只专注于自身职务上,他们便不会对所有职务互动所产生的结果有责任感。就算对结果失望,可能也察觉不出何以如此。大家只会认为一定有人搞砸了。
       现代组织功能导向的设计,将组织依功能切割分工,更加深了这种学习智障。 
       看看我们java开发模式,分层开发、分功能开发,复杂问题分解没错,但企业常常用原代码管理(cvs\svn)系统权限来故意让底层开发人员只能获取部分信息,并且没有注意到让团队成员尽量了解整个系统架构的重要性。即便是注重接口设计,但最后组装成系统整体时,显示出来的问题不小。

  

posted on 2011-03-15 23:39 BingerSoft 阅读(1575) 评论(4)  编辑 收藏 引用 所属分类: 其它

评论

# re: 局限思考 2011-03-16 01:23 aaa

感觉你说的太绝对,或许你的出发点是好的,但这个问题比较复杂,不是你说的这个简单,我举几个例子,
1,一般核心的代码,公司是不会轻易全部给出
2,如果一个项目比较大,如果每个人都去了解设计,需求,那猴年马月才能完成
3,如果让所有的人都可以随便动别人的代码,万一哪个改了,谁知道会有什么问题,出了问题谁负责,桌子负责啊
4,。。。。
5,。。。
  回复  更多评论   

# re: 局限思考 2011-03-16 08:45 万连文

不要轻易的对大是大非发表个人见解,尤其是制度体制方面的,这样往往会暴露自己狭窄的思考。  回复  更多评论   

# re: 局限思考[未登录] 2011-03-16 12:00 vincent

按接口分配,最后组装,这就是标准的手术刀式的项目风格吧
这种项目风格,本就应该每人只专注于自己的模块,因为接口已经确定,如果你还要去关注别的模块,那只说明接口之间存在耦合,那就是设计问题。而且,这个时候你去关注过多的模块,就会导致在设计时有过多的顾虑,顾虑多了问题自然也会多起来。
而且这种风格应该有一个经验丰富的主治医生来划分模块和设定接口,他是来掌控全局的,没有这样一个人,出问题的风险自然很大。
不过虽然如此,我也觉得的确不应该对于代码做出一些权限设置。
我虽经也经历过代码的权限的问题,但那大多是出于对代码的保护,而且代码大多是与设计模块无关的底层基础代码。像博主所说的,对一些贯穿整体框架的代码做出权限设置我还至今未结果。

ps.我也是一个喜欢先了解全局,再去深入细节的人


  回复  更多评论   

# re: 局限思考 2011-03-16 13:38 天堂的隔壁

根据自己不多的观察,如果不进行限制,特别是写权限的限制,结果会更糟。
大量程序员根本没有关于模块界限的概念,模块间胡乱调用。
如果想进行一些优化,得到的响应往往是“你的修改破坏了编译”  回复  更多评论   


只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理