在没有体验过一整个软件开发过程并参与其中的工程师是很难说自己是一个合格全栈工程师或者说是独立开发者的。在工作了整整四年后，我可以说我已经是一个合格的独立开发者了。这其中踩过了无数的坑，也付出了很多精力去解决这些问题。
在各个群里面，其实我也遇见了很多觉得自己很厉害的php工程师或者nodejs工程师，觉得自己能够写（App，Web，Backend，Desktop）当中任意排列组合的两三个后就会觉得自己很厉害，觉得自己是一个全栈工程师了，并且也被很多不明觉厉的小白称赞两句，哇好厉害。
然，php5。With all my respect, well, I allege that you guys thoroughly suck.
私以为一个完整且健壮的产品是应该涵盖以下八个方面的：
- 规划
- 设计
- 代码
- 测试
- CI/CD
- 沟通
- 交付
- 贡献
规划
我们并不是大师，但是我们是一群为了理想而奋斗终身的敏捷武士，我们坚持精益的理念：通过不断的学习和有价值的用户反馈，对产品进行快速迭代优化。
在项目开始之初，就需要对整个项目所涉及的行业有一个大概的了解，也需要去了解一些专有名词，并熟记于心。不同的行业可以共用很多模块，但是在细节的处理上就能够体现出一个优秀的程序员所具备的素质。 这个阶段最重要的角色并不是Programmer而是一个Planner，在这里你需要给User和Client讲故事，并把写好的故事做成一个Storyboard，然后让Client以及User自己挑选符合自己口味的Story以及Timeline，没错，就是让User和Client演绎自己的故事。与此同时，你需要根据你的经验并且用“恰当”的方式去引导他们的观点，我把“恰当”拿出来单独讲是因为很多时候，一个Planner的角色是由产品经理或者项目经理去担当的，但是作为一个全栈的程序员，这里就要求不要把自己的角色固定住。只是觉得自己是一个程序员，而不去思考产品的本身是对与错，在任何时候，用“恰当”的方式去据理力争是卓有成效的，但也不要盲目的更具自己的经验去据理力争，你需要去了解这个矛盾背后产生的原因，这需要调查，收集一些信息，不能盲目的下结论。 实践是检验真理的唯一标准。
设计
很遗憾，我不是设计师，但是我见过太多设计师了。 我依旧不能设计出一款好看的产品。 其实很多工科生的审美是奇怪的，特指做出来的东西，他们的爱好可能很文艺很清新，或是很有艺术细胞，那么为什么做出来的东西会一塌糊涂呢，这个也是我反思了很久的问题，究其原因我觉得应该是我把很多固有的思维生搬硬套进来，然后做出了一个四不像，尽管能够从各种渠道去怎么完成一个效果，但是由于缺乏专业人士的指导，所以做出来的东西往往是更符合自己的审美，但却不是一个普遍美观的产品。 在推荐使用Sketch以及一些设计协作相关的产品搭配使用。
代码
在交付软件的过程中，代码其实只是其中的一个小环节，说到底就是把你解决掉问题的方法翻译成电脑能够理解出来的语言。 而如何Ship Better Code呢？ 需要考虑很多边界条件？没错。 需要写更优雅的代码？没错。 需要动脑？没错。 在写代码之前，你要思考这样写是不是很"得体"，如果你用了很多层很多次循环反复绕自己，那么你完了，也不要喷别人的代码差了，反思一下自己。 常言道，三思而后行，代码本身并不是一个体力活，一味的堆砌一些shit code并没有什么作用，就是传说中屎糊的代码；作为一个脑力劳动，写出来的每一行代码都是需要提现出自己思考的价值的。
测试
测试其实是一个老生常谈的问题，无论是从Unit Test到Integration Test还是到Acceptance Test，从任何一个地方增加测试都可以让你更有信心的写代码以及方便的修改代码，因为测试结果会告诉你，Everything is under control。
很多人一开始会偷懒不写测试，只是一个很小的功能，或者说不知道如何去写一个测试，我就是这样的，随着项目的code base增大，你每一次很小的修改都会带来不知道会发生什么的结果，比如程序崩溃，比如少了一个值等。这些都可以通过测试来给你解决掉。
这些比单纯地调用Postman查看结果会更加的优秀，代码可以使你更加自由的组合你需要的测试工具，比如每次测试完你都需要clean database，在某一个模块面前，你需要mock一些数据，或者stub一些第三方的返回。
CI/CD
如果说在上一部分是让你更加自信的写，修改代码，那在这一块就是让你更加自信的交付代码，可以保证软件在各种各样的环境下面尽可能的统一起来。通过Git加上一些CI/CD工具就可以很方便的设置起来，可以减少很大一部分的手工劳动，9102年了，大家可以尝试一下Git配套的CI/CD服务了。
无论是Github，Coding，BItbucket这些提供Git服务的供公司，其实都会提供配套的持续集成服务，毕竟代码不能跑起来就是一坨代码，而不是一个产品而已，而一个好的产品是需要不停的打磨的，与此同时持续集成显得尤为重要。BTW，推荐阅读 GitHub 为什么免费了
沟通
沟通贯穿始终，无论是项目开始之初，亦或是开发正在进行时，举个例子，作为开发，你需要和产品，设计，测试等角色沟通，而作为设计师，也同样需要和各个角色沟通。
所以大家在这张强连通图里面，更多时候是需要扮演各种各样的角色，去交流，而不是Play your part well就够了。交付
生产从第一天就开始了。从第一天写下第一行代码开始，我们就把软件看作了已经投产，而不是遥远的明天。通过持续集成，保证我们交付的代码已经生产就绪。
参考
- 测试
- 代码
- CI/CD
贡献
Last but not least，分享你所学会的并且教会别人也是一件值得肯定的事情，在教的过程中也是在学习的过程，卖视频，卖课程是可耻的，如果有心，知识是不需要付费的。 在分享之前，你需要对自己的knowledge base进行梳理归档，然后把它们写下来，再进行分享，这样对于自己所掌握的知识是一个很好的复习与巩固。
最后
语言不是想通的，Lisp的代码与Java的代码看起来也是截然不同的，背后所体现的思想也是截然不同的，也许他们没有好坏之分，但是你一个英语都学不好的人和我来说语言是相通的。