如何在公司里舒服的活着

人活着，有时候挺累的。最近在公司遇到了一些问题，引起了我的反思。我该操那份心吗？

说一下现在的情况。最近在一家互联网公司做系统架构师，上级是部门经理。新启动了一个产品线，有专门的产品经理，主要做需求.我和部门经理属于研发部，和产品部是两个不同的部门,分工还是很明确的。

按说我的工作主要是架构设计，主要是各种技术的调研，和系统需求的抽象功能化，以及各种技术规范的制定，还有技术框架的决定，以及核心功能的研发。但是我进这家公司时，已经启动刚进入开发。前期做得并不是特别好，比如各种技术规范不够统一，下面的开发人员风格各一，测试也不规范。基本上每个人的代码都是天马行空。

好吧，我进来了，可能由于以前做team leader的原因，我看着这种情况就不大舒服，想改进。想统一大家的开发风格以及开发的规范，细点说就是各种命名，各层的调用统一等。现在还有着比如spring里应该用xml配置文件还是全注解0配置的争议。还有vo是否应该用等等。当然这些每个人都有自已的道理，各种方式我在以前的项目中都有使用过，当然我也有自已的偏向性。

现在主要让我烦心的是，我把问题提出来了。ok,部门经理说，你来负责把这些问题处理一下吧。好吧，我的工作量来了。本来我就有任务在身，如核心功能开发、WebIM及搜索引擎的研发。恩，我加加班就挺过来了，没什么。但是关于上面这些一规定后，下面N多人的代码要修改，要统一，要花不少工作量，大家肯定会有怨言。有时真的是费力不讨好呀。

大家说我是轻轻松松的，什么都不管，大家爱干嘛爱干嘛，我每天完成我的工作，按时上下班就完事呢。还是发扬主人公精神，管管这闲事？

最新进展：公司内部有一次大的变动，问题也得到了CTO的重视，一些东西也慢慢建立起来。我的工作重心也由原来的一些复杂业务开发，转为专注系统级别的技术研发，如静态化、缓存、搜索引擎、异步消息服务、文件服务管理、redis、负载性能等。在人员配备及在时间压力上，还是很紧。大家只能大干一场才行了。整个团队的氛围现在还算可以，希望一切能够顺顺利利。其实很多事情还是得上面推动才行。
更新进展：公司原来技术副总监离职了，也就是我的直接上级，山雨欲来风满楼呀。下周有新的人空降过来。哥的希望在哪里？

评论

42 楼 peterwei 2011-04-23  

zym_nanako 写道

peterwei 写道

lookdd1 写道

嫩们搞个网站也整上spring啊。。也整上PO啊。。也整上分N多层啊。。。。

为什么整网站不能用spring？至于po(do)本来就是必备品呀。网站大了之后，我认为更要分层清晰。如web层和app层分开部署，通过一些如rmi,hessian之类的协议访问，还需要vo(dto)之类的。

请问楼主，网站大了web和app为啥要分开，有啥好处

这里不讨论详细技术细节。看了我写的这篇blog,也许你就明白了。
VO(DTO)模式在分层架构设计中是否需要的扯淡http://www.iteye.com/topic/1013803

41 楼 peterwei 2011-04-23  

引用

项目中， 我让他们用mantisbt 用记录bug ，保证质量。  一开始抱怨是英文的。
我说英文很简单， 只需要填写几个地方就OK了，甚至手把手教了，会用了。
没用多久，抱怨 图文不能像word 一样排版 ，又换成了word文档记录bug 。。

我说 写代码实现功能之前 ，先把界面设计出来，把用户交互操作考虑清楚，然后再编码 。
结果只有口头上的交流 之后，开始写代码了。 结果 需要交互一改再改。

产品出来差不多，邀请朋友内测 ，发现很多玩不懂 ，不知道 要干嘛。 通过讲解之后，才了解网站是干嘛的。
衷心希望 早点搞定完成 。。。

是神马导致 产品做了半年多 ！

相对来说，你们是悲剧的。我们有专门的产品部，有好些个人在整理需求和界面交互这块的东西。我们的开发人员用不着管这些美工和用户交互的东西。

40 楼 zym_nanako 2011-04-23  

peterwei 写道

lookdd1 写道

嫩们搞个网站也整上spring啊。。也整上PO啊。。也整上分N多层啊。。。。

为什么整网站不能用spring？至于po(do)本来就是必备品呀。网站大了之后，我认为更要分层清晰。如web层和app层分开部署，通过一些如rmi,hessian之类的协议访问，还需要vo(dto)之类的。

请问楼主，网站大了web和app为啥要分开，有啥好处

39 楼 Anddy 2011-04-23  

peterwei 写道

java菜菜鸟 写道

gigix 写道

peterwei 写道

gigix 写道

发扬主人公精神，并且按时上下班。
一方面要积极进取，另一方面凡事不可期必。

另外有个小问题。我现在一个人试了下TDD方式。但经过我一小段时间的实践,发现效果是有一些，但花的工作量是我以前开发的1.5倍。这个真不是夸张。我以前开发很快的，但试了下TDD,发现时间花得更多了。唯一给我的真实感受就是：代码更稳定、更放心也更接近需求了。但时间是摆在那的，所以我都不敢向团队提出来，一方面是公司上级有时间压力，二方面让大家搞TDD，我估计被骂死，主要是本来开发就累了，整完规范，又整TDD，谁都受不了。下面的人都是工作二年左右的工程师，我认为根本不可行。
用一句话概括就是：快感是有，但也累！

这个不是你的问题。是你老板的问题。
你老板对“把事情做好”没有commitment，所以你多做多累多挨骂。
他也不一定真是舍不得，可能只是没有意识到：天下没有免费的午餐，有一分投入才有一分回报。你应该首先解决的是这个问题。
如果你老板不想投入，那你就让他明白，事情不可能自己就变好。
如果他确实想弄好，就要他做出commitment。

这句话说得很好，做得再好，如果领导不知道，也就=0。

对于一些不搞技术的领导，你能说得通吗？他们可能根本就不理解这些技术上的概念。头脑里也许只有时间，时间，进度进度，成本成本。

必须 +1 。。。

==========================

项目中， 我让他们用mantisbt 用记录bug ，保证质量。  一开始抱怨是英文的。
我说英文很简单， 只需要填写几个地方就OK了，甚至手把手教了，会用了。
没用多久，抱怨 图文不能像word 一样排版 ，又换成了word文档记录bug 。。

我说 写代码实现功能之前 ，先把界面设计出来，把用户交互操作考虑清楚，然后再编码 。
结果只有口头上的交流 之后，开始写代码了。 结果 需要交互一改再改。

产品出来差不多，邀请朋友内测 ，发现很多玩不懂 ，不知道 要干嘛。 通过讲解之后，才了解网站是干嘛的。
衷心希望 早点搞定完成 。。。

是神马导致 产品做了半年多 ！

38 楼 Anddy 2011-04-23  

不懂技术的 ，只关心时间 。

让不懂技术的关系下质量，是多么难的事情啊 。

一心想把产品 尽早做出来，然后推出去 。

结果 天天关心 时间 。

先写代码，再改需求 ，再写代码 ，再搞 用户体验 。最后N个月没个成品出来 。。。

软件过程 的顺序 完全乱了 。

37 楼 peterwei 2011-04-23  

qianhd 写道

peterwei 写道

Eric.D.Chen 写道

这跟老板没关系，你是个典型的技术男，为了技术而技术。你不是要知道怎么舒服的活着么，那你就得知道你BOSS的想法，而不是什么都想改变，老板关心项目能不能上线，能不能来钱，你架构再好再规范对老板来说没啥意义。所以你要改变的是你的想法，这事没谁对错。楼上的程序员们基本都想用自己的小想法去要求老板，这不可能。而且你们说的什么第一步该怎么怎么，然后和谁沟通怎么怎么的，都是空话，你真正需要做的是，可观的评价自己，做你自己职责内的和你能力范围内的，其他的不是你操心的你去管，结果只有一个，就是你现在的处境！

这其实是个选择性问题。从急功近利的角度来说，老板都是想越快挣钱越好的。但是没有一定的保障的话，以后推倒重来的可能性也很大。从长远的发展来说，我觉得还是要有个良好的规范和计划,至少太乱肯定不行。说句自私的话，当以后二期，三期的时候，当你以后疲于奔命的时候怎么办？当庞大之后，改一个地方，都会影响其它地方的时候怎么办？那时候老板指着你的鼻子骂，怎么搞的，系统搞得那么烂，改改改！！！但是那时关联性又太多，然后无休无止的加班。如果说是个项目，我搞完，拍拍屁股走人，烂摊子交给别人，这是可行的。但现在的情况是，以后还可能是我们这帮人弄这个系统，所以我想把它做好。就这样，好吧，我承认我算半个技术男。

我会向上面反映这种情况，如果boss充许以后推倒重来，并愿意承担以后可能的加人加钱的风险，那么先什么都不管了，把系统全部实现了再说。

烂摊子真的很难维护

举个例子
比如List.isEmpty() 这empty本来就是一个逻辑值 只需要根据size判断就行
但是如果硬加一个isEmpty的boolean属性, 然后再每一个影响size的地方去更新isEmpty的值,这就tmd脑残了
当然我说的只是项目中的烂代码,并不是List中真的有isEmpty的这个属性.
这种垃圾的代码咋维护.简直想死的心都有了.

出来混，总是要还的。很多人搞的项目，一般都是搞好，自已奔赴下个项目，然后由像你这样的人来维护。这就是现实。

36 楼 qianhd 2011-04-23  

peterwei 写道

Eric.D.Chen 写道

这跟老板没关系，你是个典型的技术男，为了技术而技术。你不是要知道怎么舒服的活着么，那你就得知道你BOSS的想法，而不是什么都想改变，老板关心项目能不能上线，能不能来钱，你架构再好再规范对老板来说没啥意义。所以你要改变的是你的想法，这事没谁对错。楼上的程序员们基本都想用自己的小想法去要求老板，这不可能。而且你们说的什么第一步该怎么怎么，然后和谁沟通怎么怎么的，都是空话，你真正需要做的是，可观的评价自己，做你自己职责内的和你能力范围内的，其他的不是你操心的你去管，结果只有一个，就是你现在的处境！

这其实是个选择性问题。从急功近利的角度来说，老板都是想越快挣钱越好的。但是没有一定的保障的话，以后推倒重来的可能性也很大。从长远的发展来说，我觉得还是要有个良好的规范和计划,至少太乱肯定不行。说句自私的话，当以后二期，三期的时候，当你以后疲于奔命的时候怎么办？当庞大之后，改一个地方，都会影响其它地方的时候怎么办？那时候老板指着你的鼻子骂，怎么搞的，系统搞得那么烂，改改改！！！但是那时关联性又太多，然后无休无止的加班。如果说是个项目，我搞完，拍拍屁股走人，烂摊子交给别人，这是可行的。但现在的情况是，以后还可能是我们这帮人弄这个系统，所以我想把它做好。就这样，好吧，我承认我算半个技术男。

我会向上面反映这种情况，如果boss充许以后推倒重来，并愿意承担以后可能的加人加钱的风险，那么先什么都不管了，把系统全部实现了再说。

烂摊子真的很难维护

举个例子
比如List.isEmpty() 这empty本来就是一个逻辑值 只需要根据size判断就行
但是如果硬加一个isEmpty的boolean属性, 然后再每一个影响size的地方去更新isEmpty的值,这就tmd脑残了
当然我说的只是项目中的烂代码,并不是List中真的有isEmpty的这个属性.
这种垃圾的代码咋维护.简直想死的心都有了.

35 楼 peterwei 2011-04-23  

Eric.D.Chen 写道

这跟老板没关系，你是个典型的技术男，为了技术而技术。你不是要知道怎么舒服的活着么，那你就得知道你BOSS的想法，而不是什么都想改变，老板关心项目能不能上线，能不能来钱，你架构再好再规范对老板来说没啥意义。所以你要改变的是你的想法，这事没谁对错。楼上的程序员们基本都想用自己的小想法去要求老板，这不可能。而且你们说的什么第一步该怎么怎么，然后和谁沟通怎么怎么的，都是空话，你真正需要做的是，可观的评价自己，做你自己职责内的和你能力范围内的，其他的不是你操心的你去管，结果只有一个，就是你现在的处境！

这其实是个选择性问题。从急功近利的角度来说，老板都是想越快挣钱越好的。但是没有一定的保障的话，以后推倒重来的可能性也很大。从长远的发展来说，我觉得还是要有个良好的规范和计划,至少太乱肯定不行。说句自私的话，当以后二期，三期的时候，当你以后疲于奔命的时候怎么办？当庞大之后，改一个地方，都会影响其它地方的时候怎么办？那时候老板指着你的鼻子骂，怎么搞的，系统搞得那么烂，改改改！！！但是那时关联性又太多，然后无休无止的加班。如果说是个项目，我搞完，拍拍屁股走人，烂摊子交给别人，这是可行的。但现在的情况是，以后还可能是我们这帮人弄这个系统，所以我想把它做好。就这样，好吧，我承认我算半个技术男。

我会向上面反映这种情况，如果boss充许以后推倒重来，并愿意承担以后可能的加人加钱的风险，那么先什么都不管了，把系统全部实现了再说。

34 楼 peterwei 2011-04-23  

jamesji 写道

首先，你说的这些是架构师工作范围以内的事情，是必须要做的。
但是，怎么做，是需要技巧的。
通常来说，相对于现行的技术体系，超过15%的变化，被团队否决的可螚性是很大的。

我的建议，
1. 将现有程序模块化，采用 maven 进行统一管理。模块分两大类，功能性的和技术性的。功能性的是说有用户界面的或者需要根据客户需求进行调整的。技术性的是没有界面的，比如安全校验。每一个模块都要有一个统一的对外的接口。这个过程中，尽可能的只是 refactoring, 保证程序可靠运行是唯一标准。模块越多越小越好。
2. 建立 core team。选择技术好的核心工程师加入，每周开一个会沟通。三到五人为佳。也看具体项目和团队大小。
3. 建立你说的标准，做好详细的文档和例子。也可以你开个头，让一个核心团队中的一个 senior 去做。然后，在核心团队中先征求大家的建议。这样，加上细化的那个 senior， 应该容易通过。
4. 将标准加到 TWIKI 上，这样确保每个人都可以看到。
5. 在团队全体会议上宣布并讲解。要用鼓励性的话讲，比如，“我们已经干出来一个好的产品(good)，但是我们要把这个项目成为一个最好的产品(great)。”等等。讲解的时候，一定要有例子。一定要说明，这个规定只对新的模块有要求，这样大家的心里容易接受。
6. 通过后，找人一个一个模块的改。因为接口的存在，影响应该是可控的。
7. 如果是 java 项目，可以用 check style 在 Eclipse 或者 build 阶段帮助程序员follow 你定的标准。

关于 TDD， 技术性模块一定要加 TDD。功能性的看项目进度。

My 2 cents.

很好的主意。

33 楼 jamesji 2011-04-23  

首先，你说的这些是架构师工作范围以内的事情，是必须要做的。
但是，怎么做，是需要技巧的。
通常来说，相对于现行的技术体系，超过15%的变化，被团队否决的可螚性是很大的。

我的建议，
1. 将现有程序模块化，采用 maven 进行统一管理。模块分两大类，功能性的和技术性的。功能性的是说有用户界面的或者需要根据客户需求进行调整的。技术性的是没有界面的，比如安全校验。每一个模块都要有一个统一的对外的接口。这个过程中，尽可能的只是 refactoring, 保证程序可靠运行是唯一标准。模块越多越小越好。
2. 建立 core team。选择技术好的核心工程师加入，每周开一个会沟通。三到五人为佳。也看具体项目和团队大小。
3. 建立你说的标准，做好详细的文档和例子。也可以你开个头，让一个核心团队中的一个 senior 去做。然后，在核心团队中先征求大家的建议。这样，加上细化的那个 senior， 应该容易通过。
4. 将标准加到 TWIKI 上，这样确保每个人都可以看到。
5. 在团队全体会议上宣布并讲解。要用鼓励性的话讲，比如，“我们已经干出来一个好的产品(good)，但是我们要把这个项目成为一个最好的产品(great)。”等等。讲解的时候，一定要有例子。一定要说明，这个规定只对新的模块有要求，这样大家的心里容易接受。
6. 通过后，找人一个一个模块的改。因为接口的存在，影响应该是可控的。
7. 如果是 java 项目，可以用 check style 在 Eclipse 或者 build 阶段帮助程序员follow 你定的标准。

关于 TDD， 技术性模块一定要加 TDD。功能性的看项目进度。

My 2 cents.

32 楼 Eric.D.Chen 2011-04-23  

这跟老板没关系，你是个典型的技术男，为了技术而技术。你不是要知道怎么舒服的活着么，那你就得知道你BOSS的想法，而不是什么都想改变，老板关心项目能不能上线，能不能来钱，你架构再好再规范对老板来说没啥意义。所以你要改变的是你的想法，这事没谁对错。楼上的程序员们基本都想用自己的小想法去要求老板，这不可能。而且你们说的什么第一步该怎么怎么，然后和谁沟通怎么怎么的，都是空话，你真正需要做的是，可观的评价自己，做你自己职责内的和你能力范围内的，其他的不是你操心的你去管，结果只有一个，就是你现在的处境！

31 楼 peterwei 2011-04-22  

lookdd1 写道

嫩们搞个网站也整上spring啊。。也整上PO啊。。也整上分N多层啊。。。。

为什么整网站不能用spring？至于po(do)本来就是必备品呀。网站大了之后，我认为更要分层清晰。如web层和app层分开部署，通过一些如rmi,hessian之类的协议访问，还需要vo(dto)之类的。

30 楼 lookdd1 2011-04-22  

嫩们搞个网站也整上spring啊。。也整上PO啊。。也整上分N多层啊。。。。

29 楼 peterwei 2011-04-22  

hardPass 写道

不在点子上，不在其位，不谋其事（还是不谋其政？）

如果非要说不关我的事，严格从职责上来说，却也算是我的份内事。毕竟是架构师，所以也算是在其位的，技术规范也算是工作的一部分。如果说从一开始我就参与进来的话，当然是顺理成章的。其实主要的问题是应该不应该在开发过程中不断的重构代码和设计。改吧，让底下开发的人累一些；不改呢，大家就轻松些，但是会带来其它的一些如可维护性，健壮性的问题。

28 楼 hardPass 2011-04-22  

不在点子上，不在其位，不谋其事（还是不谋其政？）

27 楼 peterwei 2011-04-22  

qianhd 写道

peterwei 写道

qianhd 写道

gigix 写道

发扬主人公精神，并且按时上下班。
一方面要积极进取，另一方面凡事不可期必。

维护的代码太烂咋办?  维护的很累
小步的重构?

如果是在运行中，并不赞成去重构。和我们开发阶段不一样。

那咋办 随它烂?

小步的重构是可行的。但如果是运行良好的，不出错的，你还是不要动的好。出了错，你就over了。改了这个地方，引出新的毛病，这种事情是经常发生的。

26 楼 qianhd 2011-04-22  

peterwei 写道

qianhd 写道

gigix 写道

发扬主人公精神，并且按时上下班。
一方面要积极进取，另一方面凡事不可期必。

维护的代码太烂咋办?  维护的很累
小步的重构?

如果是在运行中，并不赞成去重构。和我们开发阶段不一样。

那咋办 随它烂?

25 楼 peterwei 2011-04-22  

qianhd 写道

gigix 写道

发扬主人公精神，并且按时上下班。
一方面要积极进取，另一方面凡事不可期必。

维护的代码太烂咋办?  维护的很累
小步的重构?

如果是在运行中，并不赞成去重构。和我们开发阶段不一样。

24 楼 peterwei 2011-04-22  

java菜菜鸟 写道

gigix 写道

peterwei 写道

gigix 写道

发扬主人公精神，并且按时上下班。
一方面要积极进取，另一方面凡事不可期必。

另外有个小问题。我现在一个人试了下TDD方式。但经过我一小段时间的实践,发现效果是有一些，但花的工作量是我以前开发的1.5倍。这个真不是夸张。我以前开发很快的，但试了下TDD,发现时间花得更多了。唯一给我的真实感受就是：代码更稳定、更放心也更接近需求了。但时间是摆在那的，所以我都不敢向团队提出来，一方面是公司上级有时间压力，二方面让大家搞TDD，我估计被骂死，主要是本来开发就累了，整完规范，又整TDD，谁都受不了。下面的人都是工作二年左右的工程师，我认为根本不可行。
用一句话概括就是：快感是有，但也累！

这个不是你的问题。是你老板的问题。
你老板对“把事情做好”没有commitment，所以你多做多累多挨骂。
他也不一定真是舍不得，可能只是没有意识到：天下没有免费的午餐，有一分投入才有一分回报。你应该首先解决的是这个问题。
如果你老板不想投入，那你就让他明白，事情不可能自己就变好。
如果他确实想弄好，就要他做出commitment。

这句话说得很好，做得再好，如果领导不知道，也就=0。

对于一些不搞技术的领导，你能说得通吗？他们可能根本就不理解这些技术上的概念。头脑里也许只有时间，时间，进度进度，成本成本。

23 楼 peterwei 2011-04-22  

阳光晒晒 写道

做孽还是不做孽

这是个问题

这话说的。