10年老程序员告诉你的10条编程原则

在我写了10来年程序之后，或多或少有一些心得，希望在这里做一个总结分享给大家，为了不让本文变成一篇和其他总结问类似的水文，我尽可能用自己的亲身经历来告诉大家编程中遇到的问题和解决思路。

1：磨刀不误砍柴工

磨刀不误砍材工这个故事相信很多人都听过，但是用到自己身上可能就是失效了。

我们很多时候都是在边写程序边思考如何去写，中途遇到问题又可能会推倒重来，不管软件开发的规模大小，一开始都需要对需求做详细的分析和设计才能开工。

多花时间在倾听用户的需求和问题上。

“思考-编码-测试-改进“，不断的重复这条路去做。

2：自动化一切

作为程序员，我们干的事情本质上是让世界的所有事物变得高效、有序，但是很多时候我们自己的工作过程却不是这样的。

比如我写完代码后通常会重复以下一系列的操作：提交代码库--合并分支--检查冲突--集成测试--登陆线上服务器--拉取最新的代码--重启服务实现版本更新。

这些操作都是重复而机械的，每一步操作可能都要噼里啪啦敲半天键盘，输入大段大段的命令才能搞定，看起来很酷很炫，其实非常低效，毕竟我们是程序员，不是演员(黑客娱乐圈。。。。。。)

每次做完这些事情，起码要花掉我1-5分钟的时间，如果每天重复10次，可能最多需要花掉我接近1小时的时间在这上面，完全不值得。

而把它自动化之后，我可能只需要敲击几下键盘就可以迅速把最新的代码变成产品上线了。

自动化的方案有很多：大到各类CI/CD工具，小到一些具体的自动化工具，例如(Fabric、Ansible等等)都可以帮我们自动化这些琐碎重复的事情，不要嫌编写自动化脚本很麻烦，你只需要编写一次，但是永远受益。

3. 最小可行性产品

什么是最小可行性产品?以下这个图所表现出来的现象经常出现在软件开发领域。

客户以为的产品和我们做出来的产品完全不同，究竟是需求不明确、研发能力有限还是什么?

其实换个角度想想，如果我们一开始就把最小可行性的产品以最小代价、最快速度拿出来给客户演示也许效果更好，他会更加了解自己想要究竟该是什么样子的产品。

4：有效的调试

软件开发离不开调试，很多人都习惯用print在程序里到处输出变量值来调试(当然我很多时间也这样，因为简单)。

通过输出日志或者编辑器自带的各种调试功能，可以更方便的我们收集错误信息。

习惯用调试工具来寻找问题吧，print真不是个好选择。

5：代码优雅与有效的平衡

作为一个有追求的程序员，我们无时无刻都在追求代码的优雅简洁。据我自己的经验，通常我们在做出复杂问题思考的时候写的代码都是测试性的代码，它可用，但是不好看，因为通常在思考复杂问题时写简洁优雅的代码，会加重我们的大脑负担。

最终当我们把问题解决完之后，之前测试性的代码已经作为正式代码开始工作了，我们又舍不得或者说懒得删掉它重新用简洁优雅的方式来写。

这需要我们给自己设定一个下限，哪些代码是必须要马上重写的，不能欺骗自己说一个月之后再来重写，相信我兄弟，一个月之后你早忘了这件事了。

你能说出以下两段相同功能的代码哪段更优雅，哪段更适合阅读吗?

if obj.is_anonymous:   return obj.user.nickname else:   return '匿名用户' 

return obj.user.nickname if not obj.is_anonymous else '匿名用户' 

6：良好的沟通与交流

作为程序员要记住一个准则，同事和客户不是敌人，他们只是想以自己擅长的方式完成工作。

我们也是一样，可是不同背景、经验的人出发点可能是不同的、程序员经常觉得产品、市场的同时都是智障，相反他们也是这么认为程序员的，矛盾通常在工作中产生

学会以温和的方式倾听诉求，克服自己的不适感，当我们真正理解对方的想法时，我们也就知道该如何做事情了。

7：完善的技能栈

程序员除了编程语言之外，感觉还要学很多东西才能满足工作的需要。

实际上是这样的，如果我们的经验和知识只是在程序如何编写上，其实不配称之为一个程序员。

网络你要不要了解?操作系统一些基本原理呢?编译性语言语言和动态语言是不是都得会一点?数据库要不要了解一下?

有些工具型的知识我们不需要了解，但是有些基础型的知识我们必须知道。

8：学习能力与技巧

遇到一门新的技术，我们最快多久能学会它并开始做出产品来?

学习一门新的语言，学的不是语法，那玩意大同小异，我们学习的是它的特点是什么、在什么时候最适合用它、它和别的语言最大的区别是什么。

在技巧方面我其实没太多可说的，只有一句话 带着问题去学，当我们抱着解决问题去有针对性的学习新知识，效率会更高。细枝末节太多，需要优先找到主干。

9：分享精神

我们在网上遇到了问题就去搜索，严格来说很多程序员都是面向百度编程，面向google、stackoverflow编程。想象一下，如果没有人分享自己的心得，把解决问题的方法贴出来，我们去哪里搜索，只能自己抱着书慢慢看了吧?

有人说我怕写出来写得不好或者懒得写，其实分享自己知识的过程就是一次学习提炼的过程，你可以通过这个过程来回顾整理自己的知识点，看看是否有盲区。

10：好的产品定义

能解决问题的产品就是好产品，不在于它的界面多么精美、操作多么顺畅、功能多么强大。

用户希望做一个电商小程序，让他的客户通过小程序选择商品、下单购买，如果用户能建立几个微信群，他所有的客户都在里面，然后每天发几个表格收集、用户微信转账就能完成商品的选择和购买行为，是不是一定要做一个程序才能解决问题?

个人好的产品在于解决问题，不在于程序员的自我满足。