Archive for Engineering Management

文档那些事儿

还记得在2008年我做毕业设计的时候,自己心里有一个朦朦胧胧的概念,大概是说,要规范,制度上有标准,流程上有遵循。于是噼里啪啦整了软件工程十项文档,再加上一些辅助性文档就有了下面这个清单。我以为那样的全面会带来更好的评价,但是老师说,“太多了”,我很困惑,难道文档全面、综合,而且完备,这不好么?

文档那些事儿

在Amazon有一个大家都知道和反复自黑的事情。所有team都用wiki来记录和维护项目、产品有关

[......]阅读全文

分享到:

写给实习生的第一天

写给实习生的第一天

实习生(intern)和新员工有所区别。实习生仿佛一个长达12周(三个月)的面试,一起工作,一起解决问题。在最后有答辩和debrief meeting讨论结果。可能通过了,最后公司给offer;也可能没有通过。即便给了offer,还要面临双向选择,有可能实习生不理offer,继续求学或者去别的公司,当然也可能选择到别的团队。

我的习惯是,见面的第一天,这些内容是必须要交代清楚的:

1. 近视和远

[......]阅读全文

分享到:

研发团队的角色和构成

研发团队的角色和构成

以下都来自我的经历,带有主观评价,但是尽量保持平直的论述。

在我工作的第一家公司的时候,一个典型的研发团队是这样组成的。我的经验也只是到4年前,现在也许早就不一样了呢。

项目经理,这个角色是不断在换的。项目经理当然是只跟着项目走,这和团队经理(Team Leader)是不一样的。当然,Team Leader也往往在不同的项目里面兼任项目经理。基层的项目经理也可能会编码,但是不管参与不参与编码,工

[......]阅读全文

分享到:

扒一扒知乎上的帖子——“为什么有些大公司技术弱爆了?”

扒一扒知乎上的帖子——“为什么有些大公司技术弱爆了?”

知乎上看到一个热帖,我觉得很有意思,叫做“为什么有些大公司技术弱爆了?”。我刚看到标题的时候,先入为主和刻板偏见了一下,正如同第一个回答一样,我皱了皱眉头,产生了对题主的鄙视之情;但是很快,读完帖子以后,我却立场明确地站到题主一边了。正如同里面有位回答:

看题目以为是题主傻逼,看了正文发现真的是公司傻逼。

上面这种情况其实发生的概率挺低的,但是我觉得这回是真的发生了。

但是令我感到遗憾的是,

[......]阅读全文

分享到:

手滑的故事

手滑的故事

最近看到这篇文章《小伙伴们手滑集》,觉得感慨很多,强烈推荐大家阅读。比如这样的例子:

UPDATE没有WHERE条件

而我则经历过delete没有写where条件的惨剧,这个惨剧是某些case下面代码调用触发的,不是手动执行SQL发生的。

还有臭名昭著的,我没有经历过,但是我有不止一个同事干过这样的事情:

rm -rf

都只是手稍稍地温柔地“滑了一下”而已嘛……

这些事情我觉得一下子很亲

[......]阅读全文

分享到:

这样的傻事,其实并不遥远

最近有这样一条热门微博

这样的傻事,其实并不遥远

这样的故事真是精彩。最后一句“我想那是我此生唯一写垃圾代码的心安理得的一次机会了”,我明白至少作者还是有追求的。

任何KPI要合理都是无比困难的,这里的故事看起来有些极端,但就是一个简单地拿“代码量”数据统计来量化绩效指标的办法。这样的恶果公司最终会自己承担。

我曾经在这篇文章里面谈到过,统计指标是有价值的,但是如

[......]阅读全文

分享到:

进阶过程:程序员做项目的独立性

进阶过程:程序员做项目的独立性 第一阶段:编码机器

这是最低级的阶段,程序员拿到详细设计文档,上面连许多方法接口都定义好了。重构一些代码,写一些实现,调用一些既定的API,然后花许多时间在各种各样的场景测试上面。从做的工作上看,这都不能算程序员,最多,只是编码技巧卓越的码农而已。因为它几乎扼杀了一切创造力,但是这很常见,比如在一些对日外包公司,就是如此。

第二阶段:独立的实现者

程序员得到的只是粗略的设计文档,也许注明了外部接

[......]阅读全文

分享到:

几种华丽无比的开发方式

几种华丽无比的开发方式 不要被我的标题骗了。我可不是来宣扬什么模型驱动开发,或者什么测试驱动开发的,那些都弱爆了。今天我要说的,是几种看起来激动人心、华丽无比,但是可以让程序员们痛苦不堪的开发方式,特别适合那些热衷于折磨虐待程序员的项目经理和产品经理们。当然,掌握以后,偷偷用就好了,请不要来感谢我。

 

进度驱动开发(SDD,Schedule Driven Development)

这是在国内最为流行的开发方

[......]阅读全文

分享到:

《Rework》语句摘录

《Rework》语句摘录 《Rework》是让我有所感触的一本书,推荐阅读。作者是37signals的创立人Jason Fried和DHH(没错,此人正是RoR的作者)。37signals有两本书,除了这本,还有一本叫做《Getting Real》。

整本书都在做37signals价值观的宣扬,37signals是一家颇为特别的公司,小,但是非常酷,有一些想法令人叫绝。他们做的东西,用他们自己的话来说叫做“web-bas

[......]阅读全文

分享到:

对几个软件开发传统观点的质疑和反驳

对几个软件开发传统观点的质疑和反驳 下面这些观点都是程序员在教科书上、在编码规范里、在正统的软件工程流程里流传开来的,帮助了许多人在程序员启蒙期间养成了良好的习惯、原则。对许多人(包括曾经的我)来说,似乎是理所当然的。但是随着阅历的增长,视角在变化、看法也在变化,曾经的好恶现在都可能大翻身了。

为代码写足够的注释,让代码易于理解

“所有程序员都会写自己看得懂的代码,但只有优秀的程序员才写大家看得懂的代码。&rdqu

[......]阅读全文

分享到:

工作压力的问题

工作压力的问题程序员的工作是紧点好还是松点好?

对个人的影响

有人说紧点好,理由是可以从中学到东西,这是一种压力驱动式的学习方式;也有人说松点好,可以有大把的时间去闲逛、打酱油。前一种人至少是上进的、积极的,只是兴许是由于教育体制和软件大环境的原因,已经失去了许多主动性,非得要环境逼迫的压力下才能去学习、去分析和解决问题。

其实,大部分刚毕业的程序员都属于前一种,他们至少是努力着去提升自己,设法去写出好的

[......]阅读全文

分享到:

过度工程

过度工程 过度工程,最初我知道这个词是在Rod Johnson的《J2EE Development without EJB》,随着阅历地增长,渐渐发现书中熟悉的场景也在身边再现了。

 

敏捷、还有设计模式,给一个团队带来了什么?

我之所以把这两个词放在一起讲,是因为我要说一件显而易见的事情,可是这样一件事情很多人又不愿承认。

团队,是有风格个性的;团队,也是有能力强弱的。不管你承认不承认

[......]阅读全文

分享到:

那些牛叉无比的评审风格,你,属于哪一种?

那些牛叉无比的评审风格,你,属于哪一种?这篇文章里,我们可以见到许多有意思的编程风格,又没有精神为之一振的感觉,仿佛里面的例子就在自己身上,或者离自己很近。其实,对于文档、代码的评审,也是有诸多风格可言的,我这里列举一些有意思的典型:

 

一坨屎型评审

阅读文档、代码的时候,这些东西在自己眼里就是一坨屎:“我这么高智商的人都看不懂,明显是你有问题!”。

这样的人有一个他自己相当认可的世界观,凡是和这个世界观相冲突的无论对错

[......]阅读全文

分享到:

代码评审鲜为人知的好处

代码评审鲜为人知的好处 代码评审究竟有什么好处?

在前期发现问题,提高软件质量,降低软件成本。

事实上,代码评审的好处远不止这些。有些项目经理或者开发人员不愿意多提评审,Coding的过程包含的内容非常丰富,如果只把一个字符一个字符地敲代码叫做Coding,未免悲哀了一点。优秀的项目,编码阶段实际敲代码的时间不会很长;优秀的程序员,大部分时间都用来思考了。

 

我来说说代码评审其它鲜为人知的好处,兴许能改变某

[......]阅读全文

分享到:

Good Surroundings For Programmer

Good Surroundings For Programmer Programmers are those who work on creation, and they’re simple, hard-working and careless about dressing. They really need some special conditions to help to exhibit their creativity, since the very

[......]阅读全文

分享到:

我们的时间去了哪里?

我们的时间去了哪里? 做一个大型的WEB项目已有近两年,兄弟姐妹们总在忙忙碌碌中度过,看似很充实,可是当每个版本结束,我想我们又完成了一件大事,可是紧张的项目周期加上持续的加班,客户和一线还是对版本质量不满意。看到完成的作品时,我总有一种感觉:投入了相当大的人力,团队成员也兢兢业业,按说时间应该绰绰有余才对,可是实际上为什么我总觉得版本紧张,我们的时间怎么那么容易就被消耗掉了?

 

内耗之事

不可否认当一个

[......]阅读全文

分享到:

功能、模块质量和非功能性测试

功能、模块质量和非功能性测试 但凡面向终端用户的产品,产品做大了以后,几乎都要涉及到基线能力和定制能力的划分。任何一个优秀的产品,都要经历从相对无序到有序的逐步成熟的过程。产品的发展总是要经历不断的阵痛,可是时间长了,我还是总免不了思考:好吧,就算产品最初匆忙和艰辛的时期已经过去,就算现在基线能力的建设已经迈入正轨,可是为什么我们的直接客户,定制团队还是那么辛苦?

 

有多少功能是真正值得去完成、真正

[......]阅读全文

分享到:

Preview on Feedage: