码代码只占程序员工作的 10%……

当一位作者说出下面这些文字的时候，我瞬间对他写的书很好奇：
如果你认为程序员的工作就是写代码，那就大错特错了！事实上，编程只占程序设计工作的 10%，而且是相对简单的工作......
所以，我特别好奇的是：程序员们，那 90% 的时间你们究竟在干什么呢？憋什么大招？今天这篇会解开我的好奇心，顺便，估计会戳中大部分程序员的痛点。
这本书的作者是布朗大叔（Gregory T. Brow），Prawn PDF 作者（之前还蛮受欢迎的，GitHub上有3567颗星星），Practicing Ruby 出版人。一位具有丰富经验的 IT 咨询师——通常，能做好咨询师的，眼睛都比较毒辣，毕竟都是诊断问题的老司机。特别提一下，本书的译者是一位生于 95 年的妹子，目前在西安交通大学人工智能与机器人研究所从事计算机视觉相关研究，同时在西安交通大学软件学院攻读软件工程硕士学位。她同时具备英语语言文学功底和计算机专业知识......其实，我是想告诉你，这本书写得好，翻译得也好，至于，妹子有没有男朋友，这种问题我当然是——很了解，但是不想告诉你了！

这本书在亚马逊网站是全五星好评。“干货十足，轻松易读”之类的就不说了，下面这条评论中提到的问题大概很多小伙伴会感同身受。
太多软件开发书就像早间烹饪秀，大厨出场，秀一堆处理好的料理，扔到锅里，出来的就是美味可口的食物。然而，轮到你上场的时候，依然困惑和不知所措。这本书非常不同，采用对话式情景代入法，在具体问题场景中分析问题并逐步得出解决方案。作者想确保本书的读者作为解决问题的主角，能够始终参与其中，最终，不管是作者作为高手的直觉还是经验，都能更好地传授给读者。

好了，我们就来看看这本书讲些什么吧，来看看作者都设定了哪些场景，会解决什么问题，这些问题是否也是咱们每个程序员都可能遇到的；具体的解决过程咱们就省略几万字了......

[h1]善用设计原型，探索项目创意[/h1]
假设你在一家代理机构工作，负责指导客户做早期产品设计和项目规划。
不论做什么产品或项目，首要任务都是尽快发掘和实现客户头脑中的需求。在项目刚刚起步时，对话和绘制线框图是很有用的方法；但紧接着就应该进入探索式编程阶段，因为仅凭对话或画图能带给你的启发非常有限。
尽早生成可工作的软件，可以令产品设计变成交互式协作过程。高效的反馈环有利于快速识别潜在的不良设计，并对此提出解决方案，以免日后在更关键的阶段浪费大量时间和精力。
再简单的软件系统也是由很多活动的组件构成的，所以在设计的早期阶段就让它运转起来，看看组件之间的相互作用，是很有好处的。虽然所做的项目千差万别，但在这一层面上，所有项目都是相通的。
这一周，你将会和你的同伴 Samara 一起给一个音乐视频推荐系统开发功能原型。最初的特性集不需要打磨得多么完美，只要能实现基本功能，并从对产品感兴趣的人那里收集反馈即可。

　主要内容
你将学到如何运用探索式编程技术，在开发过程开始后的几小时之内为产品创意构思出有意义的概念验证方案。

[h1]观察增量变更，发掘隐藏依赖[/h1]
假设你所在的公司以其基于高质量文档的大型知识库而闻名。
你所在的公司非常幸运地拥有忠诚的客户。其中有很多客户会撰写博客和文章来分享自己的想法，为充分利用公司的产品献言献策。
为了鼓励这种基于社区分享学习资料的发展模式，你需要搭建一个公开的维基系统，使它与官方知识库网站协同运行。
你更希望将这个功能作为独立的项目来实现，但出于某些无法完全解释清楚的“战略原因”，产品经理希望你把这个新维基系统的特性整合到现有的知识库中。这个维基系统会有自己的“地盘”，但需要和主站共享代码库和基础设施。
该项目的难点在于，如何让维基系统上线，但不对现有的网站产生任何不良影响。表面上看，这很容易，因为加入新特性并不需要改变原有的代码。但实际上该项目暗流涌动，很多深层次的问题有待挖掘。

　主要内容
你将了解到，在逐步扩展代码库的过程中，哪些出乎意料的问题会从天而降。

[h1]准确识别痛点，高效集成服务[/h1]
假设你管理着一份面向程序员的教育型刊物。该刊物拥有少量的付费读者，其收入不足以支持你雇用全职员工。
你和你的朋友 Huan 一起维护着一个定制的 Web 应用，为刊物及其订阅者提供支持。因为预算不多，所以该项目主要由一些靠普通开源工具拼凑起来的代码和几个集成的 Web 服务组合而成。
这几年里，你开始意识到，使用自己控制不了的代码其实成本很高，也有很大风险。由于在设计软件时欠考虑，你已经吃了好几次苦头。这让你在进行外部服务集成时变得更加谨慎。
作为年终总结的一部分，你和 Huan 今天要见一面，回顾一下你们在第三方软件集成方面遇到过的几大痛点。
你们俩互相保证，绝对不能把这次讨论变成“该怪谁”的相互埋怨，因为这样做只会引起争斗，不会带来什么启发。相反，你们会重点讨论如何在未来的工作中解决类似的问题，如果可能，最好是完全避免此类问题。

　主要内容
你将了解到由第三方系统引发的几类故障，同时认识到，如果不将服务集成考虑清楚，会对决策产生不良影响。

[h1]设计严密方案，逐步解决问题[/h1]
假设在最近几个月里，你正在指导一位刚刚进入软件开发行业的朋友。
你的朋友 Emma 大概一年前找到了她的第一份软件开发工作。在那之前，她对软件开发的了解主要靠自学。为了能够尽快获得经验，Emma 在偶尔遇到困难时，会向你寻求帮助。
在过去的几周中，Emma 注意到自己好像在遇到定义明确的任务时做得不错，而在遇到包含很多细节、需要自己一一理清再解决的问题时，就有点不知所措了。
发现这一绊脚石后，Emma 问你是否需要做些编程题来训练这方面的能力。
你认真思考了一下这个想法。编程题一般画蛇添足地将实现细节复杂化，故意把数据表示得很麻烦，而且在完全理清其规则之前，是很难解出来的。这就意味着，靠做题很难训练编程实战能力，但编程题很适合用于探索通用的问题解决技巧。
于是，你找了一道 Emma 可能会喜欢的题。她随即开始解题，你则在她身边待命，帮助她解决在解题过程中遇到的问题。

　主要内容
你将学到几个非常简单直接的策略，帮助你有条不紊地逐步分解并解决难题。

[h1]谨记自底向上，优化软件设计[/h1]
假设你是一门软件设计课程的客座讲师，并且你希望缩小理论与实践的差距。
这门课程是你的朋友 Nasir 开设的，但是他目前的教学效果不太理想。于是，他请你来帮忙。
在进行案例分析的时候，Nasir 的学生很容易就能抓住要点，并能提出富有创意的问题，从而引出精彩的讨论。但是一旦涉及在自己的项目中运用设计概念，大部分学生都很难把理论和实践联系起来。
目前的问题是，大部分学生并没有构建软件系统的实战经验。这使得学生把软件设计看成是抽象的练习，而不是具象且必要的技能。
课本上的例子强化了自顶向下的软件设计方式，其中的设计理念出现得很突兀。真正的设计不同于此，但是学生经常照葫芦画瓢，进而产生气馁情绪。
为了揭示设计决策的来龙去脉，你将搭建一个小型的实时项目，并在此过程中与学生进行讨论。通过这样的形式，学生将有机会参与迭代设计过程，发挥主动性，一砖一瓦地完成系统的构建。

　主要内容
你将逐步学会自底向上的软件设计方法，并权衡利弊。

　
[h1]认清现实瑕疵，改善数据建模[/h1]
假设你在一家小公司工作。该公司刚着手对用了 10 年的考勤管理应用进行替换。
你的同事 Mateo 是原应用的主要开发人员。该应用在 10 年前替换了繁琐得惹人厌的纸质流程。多年来，该软件一直“任劳任怨”地工作着，但 10 年的连续使用使它暴露出一些弱点。其核心数据模型有一些粗糙之处，尤其不应该延续到新系统里。
由于你并没有参与原应用的开发，因此 Mateo 希望你能够从一个全新的角度思考替换方案。最近几天，你一直在研究原应用的代码库，并试验新想法。今天，你要向大家介绍构建更优系统的计划。
该项目最大的挑战是要解决理想情况下的技术实现与公司的工作风格和需求之间的矛盾。数据建模和工作流设计密不可分，只有把它们放在一起考虑，才能达到最好的效果。
Mateo 会帮助你了解该项目的历史。你们俩需要合作设计出一个能长期使用的新应用。

　主要内容
你将学到，只要对数据模型的基础结构做很小的改动，就能从根本上改善用户与系统的交互方式。

[h1]逐渐改善流程，合理安排时间[/h1]假设你是咨询师，专门帮助处于产品开发初期阶段的公司克服困难。
你最新的客户在几个月前刚从 Web 开发转型做产品开发。其核心关注点是一款叫作 TagSail 的产品。这是一个非常适合于移动端用户的 Web 应用，专门帮助用户了解附近的二手物品出售活动。
TagSail 的商业模式很简单：它免费向买家提供服务，但向在其平台上发布销售信息的卖家收费。它还为付费用户提供了一些额外的功能。但和很多不成熟的产品一样，TagSail 所提供的功能有点老套。
几个月以来，该产品表现平平。但就在最近几周，它开始获得关注。这给公司的技术设备和人员都带来了压力。团队现在蓄势待发，力求不被市场淘汰。
你的任务是帮助 TagSail 团队“精兵简政”，同时仍能为用户提供稳定的服务。为了实现这一目标，你将运用精益方法改善流程，但会做一些调整，以满足客户的实际需求。

　主要内容
你将了解到使软件项目管理陷入困境的一些反面模式，并学到如何通过逐渐改善各个层级的流程脱离困境。

[h1]认清行业未来，再议软件开发[/h1]
和在前几章中一样，你在最后也会读到一个小故事。但由于想把本章作为后记，因此我想暂停自己的旁白身份，转而说一些重要的事。
我之所以撰写本书，是因为我相信程序员不只是编程专家，转型在所难免。如果这个观点正确，那么整个行业都应做好准备，因为在不久的将来，“程序员是用技术解决人类社会常见问题的人”这一观点可能成为行业标准。
我已经写了几十年代码，感觉这个想法有些激进，但也令我如释重负。对于我来说，程序设计中最有趣的一直是解决问题、沟通等“以人为本”的方面；代码只是我能找到的解决问题最有力的工具而已。
本书中的故事不包含示例代码，但它们的目标很明确：帮助你我关注软件开发中很多有趣的、更高层级的挑战。但在每个故事的背后，都有大量的代码编写工作，只不过我们的关注点不在代码上而已。
现在让我们更进一步，想象在未来世界中，机器会完成大部分代码编写工作。我承诺在故事结束时，一定会回到现实中，但我们不妨在大幕落下之前找些乐趣。

　主要内容
你将会初步了解，当把精力完全放在解决问题和沟通上，而不管代码怎么写时，程序设计会变成什么样。

场景引入完毕......感兴趣的同学可以去购买继续阅读。希望这本虽薄但给力的书真正可以帮我们建立一种程序人生的大局观，更从容地面对自己的编程生涯。
点击文末阅读原文
或点击进入下方小程序即可购买~
[url=][/url]
备注：购买后需要查询订单是否发货请在微信小程序里搜索“码书商城”，然后点击“我的”即可查询哦