Yurii谈开发


因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少。很多候选人有多年的工作经验,常见的框架也玩得很溜。然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力。这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求。

软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论。正巧,最近我看完了新鲜出炉的《微服务设计》,所以大概可以谈谈自己的看法了。因为这类问题比较抽象,也没有统一答案,我努力尝试把思路整理清楚,把表达变得流畅。最终有没有讲清楚,说的对不对,欢迎大家给我留言。

(more…)

最近的面试中我发现一个很有意思的现象。问“还记得数据库范式吗?”,大多数工作了几年的开发人员都答不上来,但是其中大多数人会补充说“虽然我不记得范式了,但我可以保证自己设计的数据库肯定都是符合范式的”。

身为技术人员,大家都知道逻辑的重要性,那么逻辑的结论就是:范式这东西完全不重要,不记得了也不妨碍使用,而且不会出错。这种结论似乎有点不合逻辑,所以有必要专门谈谈范式。

(more…)

“全站HTTPs”俨然成了目前的热门话题,很多网站都在摩拳擦掌要实行全站HTTPs。凑巧,我们(沪江)也在推行这个计划。

一开始大家想得都很简单,把证书购买了、配好了,相应的路径改一改,就没有问题。事实也确实如此,单个独立站点的HTTPs改造是很容易的。一旦走向“全站”,才发现事情远远比想象的要复杂,全站意味着所有资源面对所有客户端,涉及的因素异常多,网络上又没有太多资料,只能自己摸索。下面我简单讲讲遇到的几个问题,提供一些经验给大家参考。

(more…)

按:本文的很多观点来自与七牛云存储首席架构师道哥(李道兵)的讨论,在这里对道哥表示感谢。

高校的计算机教育与时代脱节,这已经成为大家的共识。如果要问哪些课程脱节最严重,我的答案是“软件工程”。其他的课程虽然也有脱节,但多少有点用处:编程语言虽然不教怎么把程序写漂亮,至少教了语法;网络课程虽然没有形象直观的展示,毕竟通讯协议还在使用;数据库课程不讲数据库的安装和调优,关系代数理论仍然是不少问题的原型;数据结构与算法即便看起来与开发没有直接关联,有了概念总不会吃亏……

只有软件工程,是例外。顾名思义,“软件工程”讲的应当是把软件开发出来的学问。所以,它是名不副实的:如果你按照“软件工程”教的去做,多半开发不出来软件,至少开发不出好的软件。一方面大量毕业生不会写程序、写不出好程序,另一方面合格的“软件工程师”奇缺,对这种怪异的景象,名不副实的“软件工程”功不可没。

(more…)

技术领导要不要写代码?这是一个问题。

我刚工作的时候就听说,程序员(那时候还没有“码农”的说法)是吃青春饭的,到30岁就熬不了夜写不动代码了,所以要尽早转管理岗。相应的,如果你走上管理路线成了技术领导,自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多,技术能力增长很快,但总感觉有点别扭。那感觉就像,你能把车开得又快又熟练,最终只是为了能按时到达机场赶上飞机。然后,你就再也不用开车了。

不过无论如何,赶上飞机看来是更高级的选择,为了它,放弃苦心修炼的车技也可以接受罢。

但是等我真正走上管理岗位,才发现事实和我想的完全不一样。当时公司的业务增长飞快,支持业务的系统却是几年前“一锤子买卖”的外包项目,更要命的是技术团队的人员组成和工作习惯还处在作坊状态。从我的角度来看,四下里全是大坑,填坑的速度慢得让人着急,在此过程中还经常挖下新坑…… 在我的职业生涯中,我从没有在那么短的时间里写过那么多代码。几年后大家查提交排名,我的名字仍然第一。好在我的努力没有白费,系统终于没有垮掉,顺利回到正轨。

当时我身为技术领导,除去招人、定流程、做运维,还花了大量时间写代码,这样的做法是对的吗?如果是对的,后来我再没有写过那么多代码,好像也与“不称职的领导”无缘,甚至还被夸奖过“忍住放手让下属去做事,锻炼了组织”,这又是怎么回事呢?

(more…)

时常与一些同行朋友说起“软件难做”的话题,一方面软件确实挺难做,变数着实太多(推荐《梦断代码》),另一方面,让人理解软件难做,更是不容易的事情。如果说第一个问题靠苦练内功还能看到希望,第二个问题就近似无解而让人绝望了。下面两个场景,相信大家都不陌生:

头儿说:你们开发怎么这么慢?拿这么高的薪水,做事还这么慢?我急得不得了,只可惜我不懂开发。我如果懂,我去学校招50个码农,连续熬夜一两个礼拜,绝对可以做出我想要的系统。

头儿说:我真是对系统失望透顶了。想我以前刚创业的时候,七八个人,五六台电脑,什么事都是靠喊,那时候工作效率多高,人均产值多高?现在人才到几百个,就成了这个鬼样,说要上系统,上了系统有变好吗……

我有时候会想,这些说法在普通人看来似乎也没有错,但行业中人都知道错得厉害。那么,问题究竟出现在哪里呢?我想来想去,觉得原因大概在于,持这样说法的人往往只依靠来自生活经验的“逻辑”和“直觉”,还没有真正理解“软件”(或者说“系统”)到底是怎么一回事。

(more…)

上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”。

我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”

他说:“对,但我还是想知道,你为什么不把系统重做了呢?”

于是我问:“我离职之后,后来似乎多投了不少人重做系统?结果怎么样呢?”

他说:“结果,结果就是做业务要同时操作三四套系统……”

就我所见,把原有系统“推倒重来”的喜好不只程序员有,使用者更有。拿我几年前的那份工作来说,刚入职老大们就来跟我讨论系统重做的打算:需要多少人,多少钱,多长时间,能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛:速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头,来个干脆的彻底解决。

这种心情可以理解,但在我任内“重做系统”一直没有被提上日程,整个技术团队所做的都是“改良”的工作,内容就像我上面说的:系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握,而且在我看来,如果断然“推倒重来”,我未必能比继任者做得更好,甚至可能更糟糕,因为“推倒重来”绝不是那么简单的事情。

(more…)

在我上大学的时候,除去普通的英语课程,专业课程里还有一门《计算机英语》。当时大家的普遍认为,普通的“英语”是过四六级用的,《计算机英语》才是专业真正需要的。

等到工作了,我发现很多人都持这样的观点:程序员应该学好英语。这样才能方便地查找资料,迅速地学习最新的知识。换句话说,“学好英语”在很多人看来,就是是“学好专业英语”——这项要求已经很高了,我曾经在《程序员要怎样学英语》里提到,不但要能看懂文档,还要知道“黑屏”是blank screen,“死机”是system halt,否则查找就会很费力。

但是今天我想强调的是,对程序员来说,学好“英语”而不是“专业英语”是非常重要的。只学好专业英语,看得了技术文档,但那一大堆专业术语和概念可能会像陨石一样,没来由地坠落下来,只能生吞活剥地硬背。如果学好英语,你才会有融会贯通的感觉,知道那些术语和概念原来是从地里长出来的,底下连着根茎。

(more…)

在超市结帐的时候,收银员都会给我们打一张小票。有时候同样的商品我们会买两三件,打印在小票上面,有时候只有1行记录,数量是3(“听装百事可乐 x3”),但也有时候有3行记录,数量都是1(“听装百事可乐 x1” 重复3行)。这个现象很有意思,為什麼不统一呢?而且据我观察,后一种情况明显更多。分明是前一种做法更节省纸张,为什么更少采用呢?

我曾经设想,是因为收银的机器性能太差,内存很少,只能维护简单的数组结构,不能维护集合,也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现,这个说法站不住脚——现代的收银机性能足够很好了,甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢?就在我百思不得其解之际,一个偶然的机会解开了我的疑惑。

(more…)

很多初上管理岗位的人都听过这样一条教诲:“公开表扬,私下批评”。而且,很多有管理经验的人也是这么做的。理由很简单:公开表扬能给人鼓励,催人继续,私下批评给人留了面子,减少副作用。但是,它真的是一条应当时刻遵守的行为规则吗?

不妨看两个例子:某人表现不好,主管与他谈话之后有了一点改进的苗头,做事能“及格”了,看来应该鼓励,所以主管公开表扬,可是其它人明明做了更大贡献,却没有得到表扬;某人搞砸了工作,造成整个团队加班为他补救,然而主管只是私下批评,所以有人觉得不公平,这是主管在有意袒护。

很明显,这两个例子里的“公开表扬,私下批评”并不是合适的做法,反而造成了新的矛盾。那么,问题究竟出在哪里呢?表扬和批评,到底应该在什么情况下公开进行,什么情况下私下进行呢?

(more…)

Next Page »