推荐大家看一下这篇文章，原文和译文链接在下面。

文中关于米国程序员的薪资提到了一般的$65/h和建议给顶级程序员的$200/h，我搜索了一下米国薪资的相关信息：07年的成年男子年薪大致是5万左右，软件工程师8万；而11年的手机软件开发工程师比较高的能拿到11.5万。 每小时65块的转成年薪是：65X21天X8小时/天X12月/年=13.1万/年，在美国工程师群体中已经是很高的工资了。 说明原文作者所在的公司相当给力，那个200每小时的大致是65的三倍，应该是40万左右，是医生收入的2倍，一个这样的程序员在米国应该也是稀缺动物。 由此我们可以知道，用三倍平均工资招人一定会带来巨大的好处，作者分析的很在理，反正我是相信了。

如果你在招聘程序员，你应该给他们200美元/小时。这样一来，很多其它任何方法都无法解决的难题都变的很容易。比如解决你的人才招募问题，保证你只有在真正需要的时候才去招募程序员。

用时薪200雇佣程序员的好处

能获得高效且积极的程序员

这样的程序员一定会迫切的解决出现的问题和满足客户的需求。不会用自己学习的时间让客户埋单，也不会因为修复因为自己疏忽造成的bug向客户收费。 我要说一句，如果让我用三倍的平均薪资招募这样的程序员，那公司真的是赚到了。

能获得非常忠诚的程序员

你永远不会再担心程序员会离你而去。如果你有大量的工作交付给他，他会接受，会把大量的剩余精力投入到工作中。如果你每周只有少量的工作交给他 ...

Continue reading

Code Review的目的和内容

检查设计是否合理

Code Review需要承担一部分“结对设计”和“设计把关”的职责 内容包括：

1. 设计是否合理：如实现方法，数据结构，设计模式，扩展性考虑等
2. 否存在大量重复代码和其他组件是否有重复的代码
3. 结构设计是否合理

互为Backup

Code Review 中，Review 的开发人员了解代码的设计和实现，传递了技术，开发人员互为Backup，方便后期的维护，也减少了项目风险。

分享知识、设计、技术

Code Review是一个学习和享受的过程，一个开发人员的能力有限，而Code Review正是这样的一种机制，让好的知识、设计在团队中分享，实现整体团队的成长和整体的效益最大化。

提高代码可读性

代码的要求不止是能运行功能正确的代码，而是有了更高的要求，即Code for maintenance。 可维护的代码，需要清晰，可读性强，这里可读性代码检查不是指代码格式（代码格式可以通过工具检查出），而是指代码语义 ...

Continue reading

Code Review的好处

1. 代码风格可控，代码质量有一定提升；
2. 新员工入职后能够得到更多人的指导，成长非常快；
3. 小 bug 频出的情况比之前的项目少了至少一个数量级。

Code Review的流程

1. 使用 reviewboard 作为工具，通过 SVN hooks 强制每一次签入都是经过 review 的；
2. 至少要有 2 个团队成员 ship it，才能够签入；
3. ship it 的成员中，至少有一个是资深的团队成员。

Code Review的详细步骤

1. 团队成员在提交代码之前，需要先使用 post-review 工具在 reviewboard 上创建一个 review request。一个配置良好的 reviewboard 能够自动发送邮件给所有成员；
2. 收到邮件通知后大家抽空去 review 代码，而 review 结果也会通过邮件知会给大家，所以发起 ...

Continue reading

来源： 腾讯教育论坛

摘要:

笔者和中国，美国，印度和日本四国程序员有比较深入的合作过。通过分析他们的共性和差异，希望能够部分解答程序员应该具备何种能力的问题。

日本程序员

- 优点 非常仔细。原因是日本公司的需求非常细致。细致到在网页上，连一个像素都不能偏差的地步； 执行力非常强，对老板的承诺比命还重要 很敬业，善于做领导想做的事 - 缺点 高执行力背后的代价是低创造力； 英语被翻译成片假名，发音古怪。和日本人用英语沟通很困难

印度程序员

• 优点 流程做得好，文档写得好 善于说领导想听的话
• 缺点 代码水平一般，在算法，数据机构等基本功方面的水平明显低于中国程序员

  美国程序员

• 优点 喜欢技术，甚至崇尚技术； 才艺能力都不错； 文档写得好，因为不是为了老板，而是为了自己，为了分享。因此他们的文档往往读起来很有趣，很实用；
• 缺点 个性强； 不是为了完成老板的想法，而是为了实现自己的想法，有时候想法多了点；

中国程序员

• 优点 ...

Continue reading

上午三场内容和感受如下

Eric Evans - 《领域驱动设计：解决复杂问题的高效模式》

评价：5星 这个听得很有感觉。举了三个例子：集装箱运输、世界地图和盲人摸象。都很精妙。

• 什么是模型？ model is useful only because it's made for a particular purpose。
• 两个经常出现的错误如何避免？
• 模型要够用就好，不必十分精确，满足需求的模型就是好模型；
• 在信息不全和需求不同时，不要坚持只有一个模型。

这个ppt得好好学习。

Gavin King -《Ceylon项目——下一代Java语言？》

评价：3星 Speaker也是个年轻的牛人。Ceylon是一种由java演化而来，特意为结构化数据而设计的语言。也是跑在JVM上头的。 去年听讲Groovy还有点儿小激动，这次听这个一点儿感觉都没有。感觉语法有些乱！

Evan Weaver-《Twitter中的性能优化原则》

评价：2星 ...

Continue reading

王晨贴出了google公布的编码规范，然后也在身体力行的在公司推广编码规范，做得很好。 用怎样使用编码规范搜了一下，竟然没有中文内容，那我就劳动一下，推荐一篇tiobe上的文章并简单翻译一点内容吧，希望能够对大家在推进编码规范的工作中有点儿帮助。 先上一张图：

Step #1: Adopt/Define Coding Standards

选择或定义编码标准

Step #2: Select Code Checking Tool(s)

选择检查工具

Step #3: Customize Code Checking Tool(s)

定制检查工具

Step #4: Integration in Software Environment

集成到开发环境中

Step #5: Set up Quality Database

建立质量数据库

Step ...

Continue reading

以开发组为单位，就工作目标完成情况、工作中遇到的问题和收获、个人工作情况分别进行总结。 copy了老汉大量的经典问题，整个模板分成以下四个部分：

一、工作计划执行情况

• 做了哪些工作？
• 哪些工作是按照计划做的，哪些工作是突发的，后者的比重占多少，是否严重影响到你的计划了？

渠道的工作总结很好，可以作为模板

• 任务号： 名称和负责人
• 所属项目： 商务平台
• 实现功能： BOSS 平台注册的月结算渠
• 是否完成： 是
• 未完成原因： 无
• 运行情况： 出现过1次问题：
• 需求方反馈：
• 计划任务开销
• 实际任务开销

二、工作中的问题和收获

• 哪些工作效果很好，哪些效果差，或者是做了无用功甚至带来了副作用？
• 学到了什么新的知识，还存在哪些不足？
• 有哪些经验可以在将来重复使用，又有哪些教训是今后可以作为前车之鉴的？

三、组长个人工作总结

• 团队中谁影响你最大，为什么？
• 如何可以使自己所在的团队更和谐、效率更高？
• 我为团队建设做了些什么，还能做些什么？
• 有哪些事情是你想做而没有做成的，为什么 ...

Continue reading

最近观察了一下部门内的几个团队，王晨的团队成员士气最好；之前也向他的团队成员和外部合作方了解过他们项目的开发过程，发现他有一个特点，相比其他Team Leader，王晨更沉得下心，能从功能实现角度把控项目。

昨天中午一块儿吃饭，聊得很痛快，关于怎么提高团队士气，王晨也给出他自己的经验： 每个程序员或多或少都有对技术的向往，让他们在工作中，确实能学到新的技术，这样他们就会有干劲儿了。能够摸到程序员的确定需求且给与满足，嗯，挺受启发的。

再从部门管理角度想想，公司希望每个员工的目标都能和公司发展目标一致，要做到这点，最重要的其实不是给每个人定目标，而是先要摸清每个人到底想从工作中得到什么，呵呵，只有这样，才好考虑怎样使目标一致。想当然的给人一些东西，不如真的知道他想要什么，再给与有针对性的帮助，这样才能做到双赢。

Continue reading

盖洛普Q12的学习笔记

起因

公司人力搞了一下Q12调查，并把大家交到一起做了一个培训。 觉得这个调查方法针对性挺强的，能让管理者有针对性的对工作进行改进。 今天又拿到我们部门自己的数据，就一边分析一边学习了。

关于盖洛普和Q12调查

盖洛普是美国数学家，抽样调查方法的创始人，后来创建了一家咨询公司，也叫盖洛普。 盖洛普通过对12个不同行业、24家公司的2500多个经营部门进行了数据收集，然后对它们的 105,000名不同公司和文化的员工态度的分析，发现了12个关键问题最能反映员工的保留、利润、效率和顾客满意度这四个硬指标。这就是著名的Gallup Q12。

12个问题

Q1：我知道公司对我的工作要求 Q2：我有做好我的工作所需要的材料与设备 Q3：在工作中，我每天都有机会做我最擅长做的事 Q4：在过去的7天里，我因工作出色而受到表扬 Q5：我觉得我的主管或同事关心我的个人情况 Q6：工作单位有人鼓励我的发展 Q7：在工作中，我觉得我的意见受到重视 Q8：公司的使命/目标是我觉得我的工作很重要 Q9：我的同事们致力于高质量的工作 Q10：我在工作单位有一个最好的朋友 Q11：在过去的6个月内 ...

Continue reading

周五上午的大会议室被人循环订上了，我们的头脑风暴就改到周四上午了，提前一天开，感觉准备起来有点儿赶。其实之前的积累还是挺丰富的，内容来自《关于职场规划》、《程序员职场生涯n次转型》、《职业生涯规划的九个立足点》。

因为是回家才开始准备的，对内容的组织，apple给了很多的意见，主要吸取的是增加了Why和Goal，说明一下做职业规划对大家的好处和本次交流的目的； 在现场怎么和大家互动也花了一些心思，准备了三个统计调查和大家互动； 在早上上班路上还在想，如何让大家对职业规划有感性认识？竟然让我想到拿旅游计划来类比，呵呵，现在想想依然有点儿得意，不过这应该也得益于apple最近正在准备的十一旅游。

把思维导图拿出来和大家分享：

Continue reading

最近计费组人员变动较大，所以我对计费服务关注比较多。在实际开发中，除了因为新人业务不熟造成的调试效率不高外，系统本身也存在一些需要改进的地方。

1. 被动调用和主动发起最好分离

被动式调用：大多数计费功能都是被动式的，接收合作方或我们自己的服务器发送的请求并进行规定的回应； 主动发起： 但也有一些周期订购逻辑，需要计费服务器主动发起一些请求。按照业务要求，主动发起只能由一个实例发起。

目前每个部署实例中，都包含主动和被动功能。现在依靠在部署环境中添加特定环境变量的约定来限制主动发起功能。是一个容易出问题的点。还不如把主动与被动分开的好。

2. 服务部署复杂度高，不同环境下的部署配置不统一

今天加班和这个配置不统一有关。出了一个特别奇怪的现象：两个环境下的代码和类库都一样，但在Release下计费服务一切正常，而Verify下计费服务无法加载正确的广播消息公共模块。 尝试在Release下模拟Verify的问题，但配置高度不一致，无法做；打算用正式环境的代码覆盖Verify，但这个操作只能摆脱系统部的人做（开发的没有这两个环境的权限），又怕引起多个主动发起，也作罢了。

3. 功能的模拟测试和自动化测试还需要加强

上周加了两天的班调一个计费应用，其实在这个应用中计费就提供了一个特别简单的接口，复杂性都在另外一个team。我们提供了一个模拟测试，让那个team的开发和测试人员都清楚的看到我们的接口是好用的。我们就不用跟着他们耗着了。 昨天和群峰、苑琪确认了，现在在Release和Verify都可以做模拟测试了。这个好习惯需要保持下去。

Continue reading

如何做好知识分享

讨论原则

1. 总是想一下自己或自己的团队能做些什么
2. 心里阳光一点儿，多从积极方面考虑问题，不说负面内容

主持人发言

1. 形成知识分享的氛围
   1. 公司将积累的知识视为公司财富，肯定其重要性
   2. 本着拿来主义精神，对于不适合的知识分享，先肯定其工作态度再引导其正确的进行知识分享，不打消积极性，另外，可以开辟多个共享主题，明确主题内容
   3. 对乐于知识分享的人给予充分的肯定和鼓励
   4. 强调自觉的重要性，但是最好有一定的利益激励：如kpi加分项或者定期的组内表扬
   5. Open的态度：所有人都应该open，不断的完善，乐于接受意见及建议
2. 知识分享平台：Wiki
   1. 有明确的知识分类及索引，可以方便快速准确的查找问题
   2. 有确定的存储空间保存共享信息，防止愿意共享而无处共享的情况
3. 鼓励进行知识分享：KPI
4. 组长带头，在组员不愿意或者不清楚如何进行知识分享时，组长要充分起到示范作用
   1. DB组的wiki，组长先写好，整理好，然后发给大家，让大家看到知识分享的好处
   2. 组长要定期对共享资料进行整理，避免繁杂无序，无人愿意看
5. 不定期的面对面交流（面对面）
   1. 要充分鼓励培训和经验交流，花时间整理资料，会占用部分私人时间，建议组长带头做起 ...

Continue reading

主持人发言

讨论原则

1. 总是想一下自己或自己的团队能做 些什么
2. 心里阳光一点儿，多从积极方面考虑问题， 不说负面内容

抛砖引玉

结合工作，说说自己的看 法：

1. 换位思考，你觉得上级会关心什么？
   1. 工作是否主动
   2. 对工作是否思考怎样干的更好
   3. 是否坚持
2. 哪些工作可以提升我们的业绩？
   1. 体现主动性的工作
   2. 展 示自己的工作思路、总结
   3. 做好季度计划和总结
3. 公司目前的价值评估标准
   1. 贡献度： 收入、用户、影响力；
   2. 相 应速度、满意度；
   3. 投入产出比；
   4. 统一标准是绩效

换位思考，如果你是BOSS，你会关心什么？

1. 【监控系统、报表系统】上级关 心的是系统的准确性和可用性。【郝庆治】
2. 冲刺 项目：关注的是进度；维护项目：关注的是稳定性【王征】
3. 这 个问题很复杂，不同角色关注点不同【王晨 ...

Continue reading

结合工作，说说自己的看法：

1. 换位思考，你觉得上级会关心什么？
2. 哪些工作可以提升我们的业绩？

- 换位思考，如果你是BOSS，你会关心什么？

1. 工作是否主动
2. 对工作是否思考怎样干的更好
3. 是否坚持

- 哪些工作可以提升我们的业绩？

1. 体现主动性的工作
2. 展示自己的工作思路、总结
3. 做好季度计划和总结

- 公司目前的价值评估标准

1. 贡献度： 收入、用户、影响力；
2. 相应速度、满意度；
3. 投入产出比；
4. 统一标准是绩效

Continue reading

主持人发言

结合工作，从一下三个方面挑 选一、二发言：

1. 目的： 监控应该提供怎样的功能
2. 内容： 哪些地方需要监控
3. 怎样做：结合工作谈谈怎样监 控系统设计、开发的思路

监控提供的功能

1. 确认故障点：目前计费报警不是 特别方便定位【葛旭】
2. 评估服务情况： 给出财务损失报告【李焱】
3. 服务能力预警： 分析历史数据，根据趋势为服务能力告警【李焱】

内容

1. 在数据库层面，对统计查询的监 控力度还不够；监控系统的可用性也需要监控【苑琦】
2. 系 统角度： 网络和硬件的有效性；服务请求总量；服务请求相应时间分布【李焱】
3. 业 务角度： 计费成功情况、用户成果推送情况【李焱】
4. 用 户行为角度： 用户行为分析【李焱】

怎样做

1. 监控报警不够准确，需要加强； 监控系统的可用性需要有保障 ...

Continue reading