导语：
最近看了极客时间上面的 10X程序员工作法 专栏，作为一个刚入职不久的程序员，感触颇深，其中一点就是工作高效与否和意识有很大的关系，这里的意识要和技术技能分开来，前者更多的是做事策略，包括做事顺序、大局观，以及怎样沟通等等，后者只是专业能力。今天来讲讲在一个项目开始之前，也就是写代码之前，有哪些东西是需要做的，以及为什么要做，做这些东西能够为工作效率带来什么样的改变，这篇文章就结合自己真实情况，讲讲看过专栏之后的感想与总结。
很多时候我们会带着一种急于求成的心态去开始一个项目，我们常常告诉自己，问题只有在做项目的过程中才会被发现，不去做，永远不会发现问题。这样认为其实并没有错，但是，是不是所有的错误或者问题只有自己犯过才能避免下次再犯？别人的经验有没有借鉴的意义？提前计划能不能避免一些可能会遇到的问题？行业里面有没有一些比较好的实践？这些都是值得深思的问题。
我工作这一年里发现其实工作上面很多问题，并不是专业能力方面的问题，而是做事策略上面的问题。2017 年年底毕业后，由于地域原因，在一家小公司上班，职位是软件开发工程师，公司没有很好的管理制度，很多在大公司里面约定俗成东西，在这里都需要自己去琢磨，去和同事和领导讨论，时常要考虑自己本职工作以外的东西，像似运维，产品等等。有些时候真的挺迷茫，不知道怎么做才是好的，没有经验的积累，也没有资深软件工程师的指点，心里面就更没底了。但是现在想想，痛苦的经历是值得珍惜和思考借鉴的，这其实也是成长的必经之路，与此同时，也会感叹，当初如果早知道该多好。
下面列出来几个点是我觉得在接手一个项目前，或者做一个项目前，必须弄清楚的东西，不然的话，你会发现周围都是坑。
以终为始
这标题其实是郑晔老师专栏的一个模块，意思是开始之前需要考虑到最后的结果，如果你发现这个项目做下去，即使最后做完了，用户也不会满意，那么这个项目就没有做的必要，或者说是设计上面必须有些调整；比如说，你发现自己对这个项目需要用到的技术比较陌生，心里没有底，那也得想想有没有可以替代的技术，或者是否有足够的时间和能力去学习；还有就是这个项目牵扯到哪些人，哪些团队，他们分别负责的是哪个部分，出问题或者开会讨论你应该去找谁。总的来说是，做一个项目，不能够顺着思维想，而是要倒着想，从结果反推策略方法，这么做是因为我们要先确保我们的工作是有保障的，出了问题是有解决方法的，我们的工作成果是有价值的。
多问些为什么
在公司有些时候确实是会哭的孩子有奶吃，很多时候机会摆在那里，因为种种原因你不去争取，那机会就会失之交臂，工作也会困难很多。很多时候，在别人提出了不合理的要求，就得说出自己的真实想法，不要怕不好意思，例如说我的领导叫我用我不熟悉的技术去做一个项目，那么我就得问他，为什么一定要用这个技术？其他的技术行不行？我对这个技术不熟悉，可能不能胜任这个项目，有没有其他人能够胜任？如果一定需要我来做，那我会告诉他，我需要花 XXXX 的时间，之所以花这些时间，是因为我要去学习这项技术，当然我会拆分的更加细致些，这样也会有说服力些。
有一个经典的法则 ，这里的 5 只是一个参考数字，实际情况可多可少，但是这个原则的主要目的就是为了找到 root cause，也就是根本原因。开始项目之前多问些为什么有助于自己了解上级和其他人的想法，这样在这个项目中，会清楚地给自己一个比较准确的定位，同时也能够排除很多不必要的担忧，问题永远是越早发现越好。这里默认所有的需求都不做，直到弄清楚为什么要做这件事，省时省力，帮助了别人，也成长了自己。
分解，定义要做的部分
做一件事情，分的越细就越容易做，还有就是，越牛逼的人，时间单位就越小，例如每 15 分钟做什么，甚至每 5 分钟做什么；一般的人可能会说今天做什么，明天做什么；没有目标，没有计划的人甚至会说这段时间做什么。你如果能够把一个项目要写的代码划分成一堆任务，每个任务用几句简单的代码就能够完成，而且和不会影响其他的任务，那么这样的分解就是好的，但是这些东西确实需要平时的刻意练习，难点永远在于怎么分，怎么计划，而不是怎么做。我现在就是函数写的很长，但是每次回来都会静下心来改改，做做重构，删去代码中的坏味道，每次都会比之前的写的更加的简洁，看着这些代码的改变其实都是对自己的鼓励。
另外就是如何定义这些任务，怎么样才叫完成？有什么样的验收标准？如果你和其他人在这些问题上面意见不一样就开始项目的构建，那么迟早会出问题，往往是你认为可以了，他却认为不行，最后没做好不说，还憋了一肚子的火，还不如提前就把它们定义好。比较好的策略是从用户的角度出发，写 user stories，也就是用户使用产品的整个过程，帮助分析用户是怎样使用这个产品的，这样能够更好地发现设计上面的问题，没有写任何代码就能够发现设计的缺陷，是最好不过了。
定义一些数字来反应一些客观事实
数字相比其他的东西更有说服力，比如说要求在 1 月 1 号 产品上线，那么多一天都是延期；测试覆盖率必须 100%，那么 99.99% 也是不合格的代码。如果在做项目之前，给项目的要求里面加上一些数字，可能最后的评审会相对来说轻松不少，达不达的到，心里面也会有一杆秤，也会合理分配精力时间。
说了这些，我相信这不是全部，这些都是意识上面的问题，也就是知道和不知道的区别，但是有些时候想做到还真不是那么容易，但是我相信痛苦就在开头，学习了，成长了，后面才会长期受用。