|
“ （工作任务）要像乐高一样模块化，相互间不影响” 01 — 抗干扰模块 有朋友说，“我工作时经常被打断，每每重头再来，十分泄气。” 相信这也是妈妈们在家里手忙脚乱的写照。但不用担心，我们借鉴程序员编写代码的“模块化”原则就好了。 1982年IEEE《软件工程汇刊》发现，大程序拆分为子程序之后，错误数会减少。1万行的整块程序，会有317个错误，拆为三个子程序，错误则减少为265个。当子程序足够小，可以实现没有错误。打个比方，代码要像乐高一样模块化，相互间不影响，而不是3D打印一次成型。 回到完成工作大任务上，比如写新闻稿，就可以细分为“收集素材，写作初稿，领导审核、再次修改和发布”五步。这样就可以随时开启、暂停任务了。 你每隔几分钟就会被打扰呢？现在就把大任务细分成一个个对应分钟数就可以搞定的小任务模块吧。
02 — ETC原则（《程序员修炼之道》得到听书节选） 作者就强调了一个编写代码的核心原则——ETC原则，也就是Easier To Change的缩写，让变更更容易。可以这么说，所有的编程技巧本质上都是在实现ETC原则。 举个例子，对于程序员来说，普通台式电脑的硬件设计就符合ETC原则。如果内存不够了，可以打开机箱增加一个内存条，如果速度慢了拆下CPU换一个。也就是说，你的需求发生变化后，通过很少的变更就可以继续满足自己的需求，不用把整台电脑都换掉，那样成本会很高。相反地，现在的手机就不符合ETC原则，别说增加内存了，就是电池都不能随便换，如果你需求变了那就只能买新手机。 当然了，这里是用硬件来举例子，硬件更新周期长，不那么容易变更也是没有问题的。但是软件就不一样了，前面讲了程序员可不是做到“完成大于完美”就完了，最重要的是能持续改善。软件的持续改善，那很可能是上午发布的内容下午就有了反馈，就需要进行改善了。如果程序员写的代码不能应对这样的变更，每次都要把代码重新写一遍，那么成本可就太大了。 所以，别看前面说了，要先做一个最小可行性产品，要赶快投放市场获取真实反馈。这的确没错，但是这也只能说对了一半儿，还有另外一半也必须保证才行。那就是这个最小可行性产品的实现，要符合ETC原则，容易变更。 当你听别人说，他有一个绝好的想法，现在正在做最小可行性产品，很快就要上线投入市场了。你可别马上就认为他很了不起，他很务实。你一定还要去问问他，对于变更他还做了什么。如果他什么也没做，只是单纯地追求最小可行性产品，那么最后的成本反而会很高，甚至还不如最直接的做法，把所有功能做全了再上线。 其实ETC不只是实现持续改善的一个简单原则，它本身就是一个实现持续改善的解决方案。如果给程序员最深恶痛绝的事情排个序，需求变更绝对可以排在前三。这其实可以理解，假如说老师给你布置作业，说今天晚上要把《出师表》背下来，第二天检查。结果你晚上都快背完了，收到了老师发来的信息，说作业布置错了，明天不是考《出师表》，而是考《鸿门宴》。知道这个消息，你是不是也得崩溃。 程序员也一样，每当产品经理提出需求后，他们恨不得让产品经理签字画押，承诺一定不改需求了。可是，需求不是产品经理说了算的，真正决定需求的是用户。要想对用户负责，那就要允许需求变更。 在《敏捷宣言》提倡的价值观里面也有一条，响应变化高于遵循计划。其实这也是普通程序员和高手程序员的重要区别，只有先具有了灵活的意识，才能有灵活的解决方案。当一个程序员认为一个需求就应该是板上钉钉的时候，错误的种子就已经被埋下了。 一个高手程序员，面对需求变更，想到的不是让产品经理签字画押保证不变，而是利用ETC原则，让变更更容易，为变更做好准备。
|
|
|
