[size=medium]
读到优快云的一篇文章《[url=http://news.youkuaiyun.com/a/20111106/307026.html]优秀程序员的首要特性：判断力[/url]》，作者讲了一个故事来说明作为程序员判断力是如何重要。节省时间，我把故事贴出来：[/size]
[quote]关于Jack和Dianne的故事
Jack是一个摇滚巨星。Jack喜欢谈论世界上最酷会议中提到的最新发展趋势。他很重视在一个新项目中使用三种以上的新技术。当请他做一个基于互联网的控制后台，用于将烹饪方法与厨具进行匹配。他投入很大的精力开始做此事。最终该后台中用到了Google Protocol Buffers、node.js，具有可扩展性，却很难维护。
Dianne是一个优秀的程序员。最初Dianne是一个Unix 管理员，两年前才开始做Ruby开发。当被要求开发一个同样的系统时，她首先问了以下几个问题：
“预期会有多少厨具？”
“我们希望12个月内卖出500套厨具。”
“需要多长时间出一份报告？”
“大概一小时一次。”
“这网络的可靠性如何？”
“使用WiFi，它很稳定。”
Dianne使用MySQL数据库写了一个RESTful API结点。PostgreSQL可能更适合，但她只懂MySQL。
Dianne采用的这个解决方案可以扩展到1万个用户吗？不能，但这个系统并不需要这样做。Dianne的解决方案很简单、容易理解，具有更好的维护性。Dianne知道它并不是最简洁的解决方案，但她却知道任何更复杂的事都会超出她现在的能力。[/quote]
[size=medium]
看到这个故事时我的第一反应就是：神呐，让Jack用三年时间维护这个系统吧。
因为我之前遇到过像Jack这样的同事，碰到人就海吹新技术，且在产品线上的AS程序中频繁使用这些新技术。如果能保证质量也相当好，主要是不能，每次都是别人替他擦PG，久而久之，他就成了产品线上的“DEMO大师”。
大家以前都听过，产品的生命周期中，维护占着95%的时间，如果在2~3%的开发时间爽了，那么之后很容易陷入无穷无尽的苦难（和生小孩一个道理）。所以Dianne的优秀之处就在于：PostgreSQL可能更适合，但她只懂MySQL。她之前在MySQL上的经验和教训就能传承到新的项目中，对自己所用的技术自信且有能力保证产品质量。我觉着程序员对产品的可控在于：自己能力适当，对常用的基础产品可以掌控（DB，Cache，网络等逻辑架构熟悉，常见bug都能fix），对产品架构扩展有足够能力。不管是同事，客户还是领导都会信任这样的队友，我觉着这就是优秀。
其次，我很认同Dianne做事风格的一点就是，提前将产品的环境与容量搞清楚。就从我自己还有接触的同事来看，很少有人去管与产品容量规划有关的事，总觉着是Leader应该处理的范畴。如果产品的用户就是一百万，我们就做一百万的设计与规划，有适当余量是可以的，但不要考虑太多当用户是两百万时怎么办的问题。这个话题另说吧。
我这样说肯定有人质疑说，程序员应该是对技术敏感的，如果都用自己会的技术，对产品和个人发展不利。但程序员对新技术的敏感是与产品的稳妥性相冲突。程序员对技术的前瞻和创新首先应该是在自己的头脑里，不能抹杀这种热情。接着将自己的大胆想法做出原型与试验，证明它可以用在产品线上。在不断地仔细验证之后，才能将程序员的想法用在产品环境上。所以我的总结是：头脑跑在前面，试验新的技术，用最稳妥的技术。Jack使用新的技术没错，但不可控，如果出现问题的话，产品环境被拖累，自己也会很疲惫。
一己之见，诚请批评[/size]
读到优快云的一篇文章《[url=http://news.youkuaiyun.com/a/20111106/307026.html]优秀程序员的首要特性：判断力[/url]》，作者讲了一个故事来说明作为程序员判断力是如何重要。节省时间，我把故事贴出来：[/size]
[quote]关于Jack和Dianne的故事
Jack是一个摇滚巨星。Jack喜欢谈论世界上最酷会议中提到的最新发展趋势。他很重视在一个新项目中使用三种以上的新技术。当请他做一个基于互联网的控制后台，用于将烹饪方法与厨具进行匹配。他投入很大的精力开始做此事。最终该后台中用到了Google Protocol Buffers、node.js，具有可扩展性，却很难维护。
Dianne是一个优秀的程序员。最初Dianne是一个Unix 管理员，两年前才开始做Ruby开发。当被要求开发一个同样的系统时，她首先问了以下几个问题：
“预期会有多少厨具？”
“我们希望12个月内卖出500套厨具。”
“需要多长时间出一份报告？”
“大概一小时一次。”
“这网络的可靠性如何？”
“使用WiFi，它很稳定。”
Dianne使用MySQL数据库写了一个RESTful API结点。PostgreSQL可能更适合，但她只懂MySQL。
Dianne采用的这个解决方案可以扩展到1万个用户吗？不能，但这个系统并不需要这样做。Dianne的解决方案很简单、容易理解，具有更好的维护性。Dianne知道它并不是最简洁的解决方案，但她却知道任何更复杂的事都会超出她现在的能力。[/quote]
[size=medium]
看到这个故事时我的第一反应就是：神呐，让Jack用三年时间维护这个系统吧。
因为我之前遇到过像Jack这样的同事，碰到人就海吹新技术，且在产品线上的AS程序中频繁使用这些新技术。如果能保证质量也相当好，主要是不能，每次都是别人替他擦PG，久而久之，他就成了产品线上的“DEMO大师”。
大家以前都听过，产品的生命周期中，维护占着95%的时间，如果在2~3%的开发时间爽了，那么之后很容易陷入无穷无尽的苦难（和生小孩一个道理）。所以Dianne的优秀之处就在于：PostgreSQL可能更适合，但她只懂MySQL。她之前在MySQL上的经验和教训就能传承到新的项目中，对自己所用的技术自信且有能力保证产品质量。我觉着程序员对产品的可控在于：自己能力适当，对常用的基础产品可以掌控（DB，Cache，网络等逻辑架构熟悉，常见bug都能fix），对产品架构扩展有足够能力。不管是同事，客户还是领导都会信任这样的队友，我觉着这就是优秀。
其次，我很认同Dianne做事风格的一点就是，提前将产品的环境与容量搞清楚。就从我自己还有接触的同事来看，很少有人去管与产品容量规划有关的事，总觉着是Leader应该处理的范畴。如果产品的用户就是一百万，我们就做一百万的设计与规划，有适当余量是可以的，但不要考虑太多当用户是两百万时怎么办的问题。这个话题另说吧。
我这样说肯定有人质疑说，程序员应该是对技术敏感的，如果都用自己会的技术，对产品和个人发展不利。但程序员对新技术的敏感是与产品的稳妥性相冲突。程序员对技术的前瞻和创新首先应该是在自己的头脑里，不能抹杀这种热情。接着将自己的大胆想法做出原型与试验，证明它可以用在产品线上。在不断地仔细验证之后，才能将程序员的想法用在产品环境上。所以我的总结是：头脑跑在前面，试验新的技术，用最稳妥的技术。Jack使用新的技术没错，但不可控，如果出现问题的话，产品环境被拖累，自己也会很疲惫。
一己之见，诚请批评[/size]
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
