浅谈开发人员的管与理

极为赞同~

我也认为，关键就在于，检查代码的人，自身水平到位，也够认真负责，拎着搞1周2周，基本就合格了。

不过很多提出制度的公司没有这类专职人员搞这种事情。

因为走查代码要求人员水平高威信高，这类人员公司觉得做走查代码又比较浪费。

在公司七嘴八舌反而让自己想偏了，你的思路简单、清晰，实在佩服。

1.要有制度，制度要合理。
2.要有执行
3.考核即是约束也是激励
4.结合考核赏罚分明

目前最头疼的问题是考核。

恩，结合IDE等工具进行管理只是一个辅助手段，但是它还是有一定的价值的。不能盲目信赖工具，要先有合理并且已经实行的管理解决方案。
工具本身只是为了让管理更高效、但是不能代替人去做管理。

    赏罚看什么公司，我的看法是，一般情况下，奖赏易行，惩罚难做。比如做的特别好的员工，你给他物资或者精神上的奖赏，鼓舞作用还是有的。惩罚呢，如果实质性的惩罚，一次基本就能让该员工萌生走人的意思。如果是特别牛逼的企业，比如腾讯之类，该员工能力又一般，进入这种公司自己认知是烧高香的，那么还能让其认真点。否则一般情况，经济惩罚实际推行只会人心不稳。

   考核还是其次的，所谓上下都有对策，没有合适的制度，只有合适的执行者。

首先，从代码和开发规范的角度来考虑，你所在的公司，是否能给开发人员标示出需要走的“路”。就是说，公司的开发规范、流程、代码结构、风格是否是经过实践得出的、切合公司实际和开发人员实际水平的。如果是，那恭喜你，按这个标准执行吧，新员工中，有经验一般会很快上手；刚工作的，你给他点文档，再教一下，也能很快适应。代码检查工具、行政处罚只能是辅助手段，一般的代码检查工具只能做一些死的检查（我们公司的工具可以检查提交的代码是否按照统一的风格去格式化，但是对于业务逻辑处理的优劣、有没有更优的方法，它是无能为力的）；而行政处罚只能是下下策，在我们公司，如果这个人如果因为代码而被处罚，那他离辞职也不远了。
再来看看这个代码规范的标准：定高了，开发人员适应期长，项目风险大；定低了，不如没有，而且会误导一些新人。这个度需要项目经理或开发经理自己把握。
从我们的项目实际情况来看，我们的没有很先进、很牛、很多技巧的东西，甚至有很多的“反模式”在里面，但是要控制住开发方式，告诉一线的开发人员在碰到什么样的问题时你该怎么做，同时尽量为其提供需要的基础结构，使其专心于业务，而不是整体折腾在代码、规范的口水中。我们最后的结果是，在这样的场景下，开发人员在业务中的口水比代码中的口水多的多，而项目的风险和进度都能控制住，代码的质量在一个可以接受的范围内。
从项目的角度看，跳出开发人员、代码的管与理这样的圈子，给他一条合适的“路”让他走下去，合适的就是好的，多关注项目本身的业务，控制风险是主要的。

主要是代码规范
做对日外包 基本大家的代码差不多

如果你那思考和分析，最后的制度还是存在罚钱，那就是扯淡跟搞笑！

罚款是很极端的做法，一旦罚单开出，等于宣布，程序员a，你可以走了。
多开几张，老实干活的人也不想再这边干了，即使他可能还是受嘉奖的那位。

"代码走查"是怎么执行的，是人工的检查，还是有工具，设置好了规则直接自动完成检查，对于Java的开发人员来说有1、Eclipse 代码格式与规范2、Sonar 代码质量综合检查3、Checkstyle 代码自动检查4、PMD 代码自动检查等。至于功能上的检查估计用代码走查也看不出来，代码走查的目的是为了能够叫别的开发人员更好的理解自己写的代码，交接工作比较容易。

管是约束其行为。
而理则是提高工作效率，能留人才。

管：是制度、是条例、是游戏规则。
理：是谈心、交心、厚黑的施展、而管理者即在戏里也在戏外。

只管不理：虽能迅速见其效，效率增长缓慢，但最后留不住人才。
只理不管：平凡的岗位、和平的年代、缺少激情打工时代。只管不理虽能网住部分人心，但不能涉及所有，过度则有虚而不实。

只有管与理均衡施展：才能达到最佳效果。这里的奥秘只有个人用心观察，细心体会才能升华为宝贵经验，甚至是别人学不来的。 而并非简简单单分配均匀的时间去执行管和执行理。

因人不同，管与理也因人而异：比如李开复说的，谷歌的工程师只能理而不能管。那是因为有些人有“自知之明”知道自己要做什么，我付出多少我就该有多少回报少一分不少，换过来做得不好自己会内疚。对这部分人，行为自己能够约束，所以对其只施其理则有奇效。