假如我是一行代码

   <p>一直以来很想写这样的一篇文章，奈何对这个论题的理解一直停滞不前，理解的也不够透彻。今天偶然的一个想法，综合自己的工作经历和项目经验，突然找到了灵感，现在，为大家带来这篇文章。</p>    <h2>绪论</h2>    <p>故 事应该从麦肯锡公司的金字塔原则谈起，我们都知道，麦肯锡公司的金字塔原则教给我们的是重点突出、逻辑清晰、主次分明的逻辑思路，也就是告诉我们一种从金 字塔塔尖逐渐向下推演的过程，至于，金字塔原理的详细内容，在此就不做赘述了。其实大家可以发现，金字塔原理是很符合我们的思维习惯的，这里面又涉及到一 种重要的思维方式，那就是推演。而大部分人的这项能力其实和一般人别无二致。但是，反向的思维，比如说归纳又有多少人能够熟练掌握呢？大多数人程序设计， 往往从架构基本概念入手，不断向下挖掘，不断的推演，当然有时候会辅以头脑风暴，效果更佳。但我们今天，就从一行小小的代码谈起，刷新一下我们的认知！</p>    <h2>假如我是一行代码</h2>    <p>为何这样想？</p>    <p>我 们不止一次在生活中听到”假如我怎样怎样，我会怎样怎样“的句式，而这样的句式说出来的一般意义无非就是让我们站在另一个角度去思考问题，比如说曾经一个 物理学家假设自己是一个电子，他借着这样的假设进入了另外一个神奇的天地，那是一片从来没有人到达的乐土，那是一个就算两个电子相撞、抑或相互泯灭都显得 举足轻重的一个世界，在那里，电子是主宰，而不再是人类。电子遵循着生存的法则，相安无事。而我们，今天的主题，将带着大家以一种全新的思维去看待程序设 计，假如我是一行代码！</p>    <p>站在一个软件工程师的角度，我们往往觉得一行代码对于我们的影响是微乎其微的，可以忽略不记，而今天，当我们假想自 己是一个代码块的时候，我们可能会发现另一个世界。但是有人提出质疑了，那你为何不假想自己是一个关键字，是一个字母，是一个字节或者一个比特位呢，莫 急，且听我慢慢道来，我们今天讨论的程序设计，我认为实用的有讨论意义的单位最小就是一行代码了，再小的话，将失去我们讨论的价值所在。当然，换个角度来 讲，如果你想探究cpu内部的加、减、乘、除的机理，你选一行代码作为参考自然是不够的，那个时候，字节等量级的参考才是我们真正所需。</p>    <p>那么，让我们开始思考，假如我们是一行代码，我们会怎么思考呢？文字有时候还是显得太枯燥了，我们来张脑图天马行空一下。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/6e743659567e61de7a746ee235058ec8.jpg"></p>    <p>可以清楚的看到，作为一行代码真的还是不错的，有这麽多的事情可以干，哈哈。当然，我着重标出来的1和2大家一看都知道这两个老梗，不懂的自行谷歌之。</p>    <p>当然了，我们并介意那些天马行空的想法，但是在想这些事之前还是先把我们最主要的事情先做好吧，那当然就是我们的程序设计啦！现在，我们就确立一下我这行代码现在想的问题，那就是如何写出一段好的程序，下面的话，让我们进入今天的主题，主题，主题。</p>    <p>我要怎么做？</p>    <p>上 面我们已经谈到了我们为何要这样去思考问题，我们争取站在一行代码的角度去理解软件设计这门艺术，那么，作为一行代码的我们，现在已经确立了这样的一个宏 伟的目标。我们现在站在这样一个难题面前，想着如何去攻克它，证明我们自己的实力，似乎现在已经到了一种剑拔弩张的状态，空气里到处都充斥着火药的味道。</p>    <p>但 是作为一行聪明的代码，我不能蛮干啊，我一定得先在心里有一个想法，然后去扩充它，由于我所处的层次是比较低的，我只能就一点点的思考了，大家可不要笑话 我这行代码啦！思考的结果我该以什么样的形式呈现给大家呢？苦思冥想之下突然发现作为一行优秀的代码，todoList一定是要有的，于是就有了我下面的 思考。于是就有了下面的列表：</p>    <ol>     <li>首先当然是拉拢几大程序设计结构，if-while-for他们了，这样一来，我军士气大涨。</li>    </ol>    <p>2.拉来测试大神“junit”为我们代码质量保驾护航。</p>    <p>3：找一些敌军的优秀精神领袖，观察其处事风格，正所谓知己知彼，百战不殆！（当然具体的寻找思路就是GitHub喽！）</p>    <p>4：链接一些api大哥，为我们的一些底层操作实现无缝接入。</p>    <p>5：请教算法大师，为我等思维模式的提高锦上添花。</p>    <p>6：拜访设计模式，了解高可用软件开发之道。</p>    <p>列 完了这些，我苦思冥想，接下来该干什么呢？作为一行有着完美主义血统的代码，我忍受不了自己的todolist不完善，然而我却忘记了，完美不存在，我们 只是能尽量做得完美而已。下面的事情，还用我多说吗？那当然就是个”做“；当然，我们开始的话就要分析一下我们的todolist中计划可行性。</p>    <p>首先，我们大致将其分为两类，受外部影响的和内部可消化的。</p>    <table>     <thead>      <tr>       <th>类别</th>       <th>计划编号</th>      </tr>     </thead>     <tbody>      <tr>       <td>受外部影响</td>       <td>1,4</td>      </tr>      <tr>       <td>内部可消化</td>       <td>2,3,5,6</td>      </tr>     </tbody>    </table>    <p>大家觉得是哪一项更加重要呢？当然，是受外部影响的重要啦！在这里的话，以计划4说明下：</p>    <p>几 个月前，一名NPM（NodejsPackageManager）社区的贡献者AzerKoçulu出于对NPM管理层的怨愤（详情），不声不响删除了自 己在NPM上面的全部代码，其中就包含只有11行代码的“Left-pad”，没想到从中国北京 到美国硅谷，从大学宿舍学习Nodejs的新手到非死book的资深工程师，整个互联网界都炸开了锅，他们手中的许多Nodejs模块，全罢工了。</p>    <p>据NPM官方博客，“left-pad”删除后， 受到影响的模块达到数千个。</p>    <p>这 可真是我代码界的前辈啊，但是这是一个典型的反面教材，有人就质疑了，为什么不设计一个官方标准库，把那些引用次数很多的api都放进去呢，（这一点 上，jdk就做的比较好）还有一个更典型的例子，真有一个一行代码的模块，叫做isArray，下载量达到88万次，万一有一天，代码拥有者的账号被黑客 盗走了，黑客一时兴起，删了这个小模块，到时候真可就是呜呼哀哉了！</p>    <p>这说明了一个道理，外部模块有风险，且用且谨慎。在举个例子，你要开发 一个项目，请了好几个大神，大神也答应你好的，结果真到交付的时候，大神说最近没时间，还没开始干，这时候，有着一颗玻璃心的我，岂不是要抓狂，在加上我 们代码界又都是一些耿直boy，有啥事会发生还真别说不来，就像上面node社区的那位小哥！so，首先确认外部的风险点，保证项目进度可控。</p>    <p>做 完了todolist，也确认了外部的风险点，接下来该干嘛呢？哼，让我好好想想，该干嘛呢？突然灵机一动的我都被自己机智到了，当然是确认验收标准，什 么才算的上是一段好的代码呢？我们在开发的过程中也一定是在有着明确的验收标准后才会开始的，要不你怎么知道什么时候该停下来！如果不知道什么时候停下 来，就像递归没有终止条件，到最后你只会因为资源耗尽而亡，就像遇见了程序里面的栈溢出。那么，我们就来定义下，当然，我希望我们友谊的小船能升级为巨 轮，会尽量写好的，列举如下：</p>    <table>     <thead>      <tr>       <th>项目</th>       <th>标准</th>      </tr>     </thead>     <tbody>      <tr>       <td>1</td>       <td>人脑可阅读（代码不仅是写给机器的）</td>      </tr>      <tr>       <td>2</td>       <td>直线化的思维（方便理解）</td>      </tr>      <tr>       <td>3</td>       <td>完善的注释</td>      </tr>      <tr>       <td>4</td>       <td>优化，但却不能过早优化</td>      </tr>      <tr>       <td>5</td>       <td>可测试并且已经测试</td>      </tr>      <tr>       <td>6</td>       <td>可维护的</td>      </tr>      <tr>       <td>7</td>       <td>和业务相关的</td>      </tr>     </tbody>    </table>    <p>当然，不同的项目有着自己不同的项目标准，而我们这里仅仅是一点好代码的验收标准，当然，若有不妥之处，还望指正。有了这些，我们就要开始动手了，想想也激动。</p>    <p>于 是我们进入了正式的开发编码，能一直编码的话那也真是人生一件乐事啊，正当我们激情满满的时候，产品小姑娘跑过来，这有几个需求需要改一下，顿时有莫有觉 得心好累啊！但是不怕，我们设计的巧妙的结构还是足以容纳这一点的改动的。看吧，前期规划的重要性，于是乎，一切好像都向着美好的方向在发展着，我们的小 心脏也可以放下来了。似乎马上就要成功的到达彼岸了。终于开发完了，自己完成简单的自测之后，觉得这样的小模块提测不会有问题的啦，然而，我们还是想多 了，还是有着这样那样的问题，最终，我们的小模块终于上线了，而我们学到了什么呢？从一行代码的角度思考，我们又能学到什么？</p>    <p>我们得到的启示</p>    <p>为了更直观的看到我们得到的启示，我们来试着将我们的思考过程以图表的形式呈现出来。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/210a2cf2d2c3619591e0917989ef5f24.jpg"></p>    <p>看 到上面的图表，我们的思路是不是更加清晰了一点呢？我们把这幅图倒着来看，俨然就是一张倒着的金字塔，而不同的是，我们这次是从塔底向塔的最上方爬，也就 是采取归纳的方法，一步步的向我们的目标靠近，这是一种逆向的思维，同时也是对我们思维方式的一种锻炼和提升，我们常规的编码就是站在一个比较高的角度上 去思考，去进行脑暴，把我们需要考虑到的点归纳进来，从而实现我们todolist的完整性。最终为我们的这一段可验收的代码贡献自己的力量。从这里我们 还可以联系一点，那就是当你站在一个比较高的层次的时候，也要去考虑底层运行的机理，比如说在项目管理的过程中，身为项目经理，一般都是从技术岗位一步步 的干上来的，所以在思考问题的时候，会站在底层开发人员的角度去思考，而如果这个经理非技术出身，那么他在进行项目管理的时候就会想当然的站在自己的角度 去进行思考，忽略一些细节，往往这样的项目，开发人员累死累活，却没有什么成果！我们不该想想背后的原因吗？</p>    <p>在本文我们可以看到，推演和归 纳的思想在我们项目进行的过程中，构建一段普适性高的代码的时候，扮演着非常重要的作用，当你站在一个较低的层面的时候，你可能会看到不一样的世界，一句 打印的代码在那个世界里也可能举足轻重，而你，收获的不仅是归纳的思维，在现实生活中，还可能收获的是理解和尊重。</p>    <p> </p>    <p>来自：http://www.techug.com/if-you-are-one-line-code</p>    <p> </p>