@bk201 说起这个，老总前段时间还找过我，商量说把现在的主管转成架构师（现在的主管技术实力很强），然后我转主管，负责主要的管理，我犹豫了一下午，还是拒绝了，因为总觉得自己还是更偏向技术方面的发展。老板最终也同意了

到现在我也不知道这样的决定是不是正确

@airqj sorry啦，短期不考虑魔都以外的地区～感谢你的看重

@JamesRuan 说起这个真是...心塞...尽管每次给同事培训我自己确实感到获益匪浅，但是...从单元测试到Git的基本理念与用法，从编码风格的重要性到Resharper实战范例...将近两年时间里我多多少少也召集过5，6次培训...结论是，大部分人，根本不关心

“我费这劲干毛啊到底？！”，每次结束后我的想法

难懂个屁啦，我一行oc都没写过，也觉得第二种方式是100%自然又易维护的写法，楼主别怂，掏出代码大全跟他刚正面

@pimin https://www.visualstudio.com/products/compare-visual-studio-2015-products-vs

看起来并不是全功能啊？Codelens都没有

@matthewgao
摘抄自原文：“你也许会想，这种曳光代码的概念就是原型制作...他们有区别：使用原型...其间的区别很重要，足以让我们再重复一次，原型制作生成用过就扔的代码，曳光弹代码虽然简约，但却是完整的，并且构成了最终系统的骨架的一部分，你可以把原型制作视为在第一发曳光弹发射前进行的侦查和情报搜集工作”

我想你的困惑主要来源与对“原型”的理解和作者所表达的“真正的原型制作”不同。

作者表达的“真正的原型”是什么呢？是最基本的线框图，PPT，仅有有限交互能力的动态页面，等等。譬如Axure制作的“网页”，譬如最近流行的用纸笔作画，用iphone照相然后就可以给相片添加交互功能的那个App（叫啥我给忘记了）。这些“原型”都是仅仅借用UI表达基本业务逻辑，你无法在后续的工作中再次利用它们。

许你在日常工作中已经下意识的采用了曳光弹方法只是不自知罢了，你制作原型，展示给客户，调整方向，继续完善，这就是曳光弹。

本来这本书里所讲授的都是像这样“显而易见的”方法，可能有大量实践你都已经不知不觉的做过了，但未能将其内化，未能将其当做开发的本能，其书的价值就在于把这些方法整理了出来，提供给你一个可以随时查阅的列表。就像《重构》，就像《设计模式》。

一点浅见~见笑了

根据书中给出的例子，我对“曳光弹”的理解是MVP，最小可用产品。甚至是比MVP更简单，进一步最小化的，一段核心算法，一个可操作的简单界面...等等。避免从复杂繁重的文档和大而全的设计开始，直击要害（或者说是你认为的“要害”），实现一个可供操作和评估的东西，观察用户的反应。一旦命中，再对其进行修缮和完备，反复在系统的各个部分实施这样的动作，形成最终的产品。

这不正是现实中“曳光弹”的作用么

是你求助的事情怎么看都像是鸡鸣狗盗之流，不是大家乐意帮忙的事情