团队里的两类程序员
程序员的分类 最近几年，我在多个不同类型的项目上，以不同的角色工作过：有时候会为项目前期做一些预研、然后为后续的交付估算工作量；有时候则在项目中期加入团队，做本职的交付工作（就是写业务代码）；而另外有些时候则会帮助客户的团队进行能力建设等等。 由于要在不同的场景和不同的上下文中频繁切换，我和很多不同水平、有着不同变成习惯和思维方式的程序员一起工作过。我觉得对于程序员这样一种角色，还可以再细化成两大类。虽然都是程序员，但是其职责，技能要求，甚至思维方式都可能有很大的不同。 这两大类程序员分别为： 原型类程序员（prototyper） 产品类程序员（engineer） 原型类程序员 如果通过敏捷的方式来运作一个项目，在项目开始的时候，开发往往需要客户/用户，BA（业务分析师）等角色一起协作。在有一个对需求的粗略梳理之后，通过技术手段快速实现应用程序的原型，用以快速验证业务场景。由于对需求的梳理是较为粗略的，其中有很多待验证的假设，如果按照传统的方式来运作，则会有很多不必要的浪费 设计师通过Photoshop作出页面 开发根据PS文件来开发 开发的同时，业务分析可能有了新的发现 设计师对Photoshop作出修改 开发根据新的PS来做修改 这种重量级的，瀑布方式的工作体验非常糟糕，不论是设计师，还是开发，总觉得很多事情都在变化，自己花费了很大力气做的像素级别的精准调整可能在第二天就要被推翻。不过现实世界就是这样：需求的变化是不可避免的，我们唯一能做的是积极拥抱变化，而不是在最开始就尝试设计、实现完美的效果。 与其在一开始就试图设计一个完美的、确定的系统，不如放弃幻想，每次只做简陋而可以示意的原型，然后不断去迭代，最后达到可用的系统。 比如，如果设计师完全不使用Photoshop，也不产出任何的PS文件，而是和开发坐在一起，开发一个简陋，但是易于修改（比如HTML+CSS）的页面，然后向业务分析师或者客户来确认，然后根据反馈来快速调整。在迭代过程中，每次确认之前，只做非常少量的工作，这样既可以避免返工，又可以让将来的调整更容易。 如果用这种方式来运作，我们队程序员的能力要求是这样的： 手速快（可以在很短时间内作出一个可以工作的原型） 技术广博（前后端） 可以与不同角色一起工作（最好是通过结对的方式） 比如通过python -m http.server 8080来运行一个Web服务器，而不是去考虑负载均衡或者HTTP缓存等，也无需考虑在为前端代码加入动态路由。 很有可能，一个在<head>里通过CDN引入外部依赖，然后将所有代码都写入main.js就可以让我们的想法变成触手可及的应用，在建立起快速反馈的机制之后，就可以和我们的BA，甚至客户一起来协作，并快速打磨原型，使之和客户的期望契合。 原型驱动 去年我参加了一个非常有意思的项目，在我加入的时候，客户只有一个非常粗糙的想法：在网络（不是计算机网络）中，如果某个实体被攻击了，那么对整个系统的影响是什么？比如某个变电站由于气温太高爆炸了（6·18西安变电站爆炸事故），那么哪些地铁站会受到影响？以及收到多大影响？又或者某个运营商的网络中断了，那么它对该城市的各大银行的转账业务有多大影响？ 客户希望有一个比较直观的方式来展现网络中的节点，以及当故障发生时会有什么样的影响。我们从原型开始，没有设计师的参加，也没有专门的业务分析师，一开始只有有一个简单的文档来描述，然后我根据文档画了一个草图： 和客户确认了，我用bootstrap+leaflet做了一个简单的页面： 客户表示大致是这么个意思。这时候我的代码是这样的： 一个HTML文件 从CDN来获取jQuery，bootstrap，leaflet inline的script中写了一点微小的代码 inline的css 确定了这就是客户想要的效果之后，我做了一些简单的调整： 将第三方依赖下载下来，放到本地的一个目录中 将inline的JavaScript和CSS抽取到文件 写了一个简单的shell script用来启停本地的HttpServer 几周之后，客户对右侧的两个panel有一些新的需求，要求有一棵树，可以点击，然后要做各种同步： 这时候，我的代码还是几个微小的jQuery写的文件，通过简单的事件机制来完成交互。很快，客户有了一个新的需求：中间区域的图中的非叶子节点要可点击，点击之后右侧的一个panel显示该节点下的所有叶子，同样，右侧panel中的节点也需要可点击。 也就是说，中间的树需要两个不同的视图，而背后的数据只有一份（这样点击时的展开和收起才会是同步的），这时候用事件机制就很难做到了，而且代码的复杂度直线上升，而且可维护性基本没有。 基本满足客户的需求之后，团队里加入了两位同事，这时候我做了一个比较大胆的决定，用vue.js将整个应用重写，将大部分功能都抽象为组件，方便以后的扩展。完成的时候，界面看起来是这样子的： 如果整理一下思路，原型类开发的流程是这样的： 用CDN+胶水代码迅速实现 及时与客户沟通，并根据反馈修改 在需求相对稳定，方向确定之后，再做实际的技术选型 重构 — 甚至重写（使用靠谱的技术站进行） 比如上面这个项目，如果现在让我再来做一次技术选型，我可能会这样选择： 前端框架：React + Redux + React-router 界面原型：AntDesign 地图：Leaflet 可视化：D3 产品类程序员 另一方面，当idea已经经过验证，我们需要通过严谨的工程实践将其产品化，那么对开发的要求却又有不同：...