一、背景
今天在知乎上看到一篇《作为IT行业过来人，你有什么话想对后辈说的？》问题的答案，其中一小段摘录如下：
非常值得在这里给大家分享一下。
二、感悟
2.1 亲身体会
见过很多刚毕业的同学缺乏工作经验又急于表现，为了尽快做完项目，在没有了解清楚相关背景和价值，没有做好完整的技术方案时，就着急开始编码。导致很多项目后面会有推倒重来的情况，也没有充分自测的意识，导致项目质量也不是很高。
这或许就是所谓的“欲速则不达”吧。
2.2 重视设计
这里所说的写文档更准确说应该是编写技术方案文档。
在技术方案文档中，将业务逻辑梳理清楚，设计好核心功能的技术实现，梳理好依赖的接口，画清楚系统之间、接口之间的调用关系，考虑清楚各种异常场景等。
然后对技术方案进行评审，让其他经验丰富或者了解该块业务的同事提提建议，对方案进行优化。
当技术方案设计清楚并评审通过，然后再编码，心里就会非常有底。
方案设计合理，编码只是一个时间问题。
如果编码完成后能进行充分自测，并进行代码评审，那么项目质量应该不会出现大问题。
2.3 百分比问题
文中提到，设计应该花 80% 的时间，编码和调试应该花 20% 的时间。
我不是特别认同这个百分比，实际工作中，比如10天编码的项目，可能要2-3天熟悉需求，然后进行技术方案设计。
如果把这个百分比当做是重要性我道是更倾向于认同。
大家要抓住重点，文章想表达的是技术方案设计的重要性。
三、总结
本文虽然内容不多，但在此呼吁大家在动手之前一定将核心的逻辑，核心的方案想清楚，尽可能落到文档中。
在项目编码完成之后，一定要自己先自测，自己先审查一下自己的代码，然后再提测。
在提测期间，强烈推荐通过 tail -f error.log 或者其他方式随时观察错误日志，项目相关问题早点修复掉，而不是等测试找到你再去改。
这种意识非常重要，希望刚工作不久的同学一定要重视。
PS: 改天有时间我会写一下如何写技术方案，如何写提测文档。
