做合格程序员

程序员，是有高低之分的，区分的标准挺多。　我们知道，一些事情可以通过本能（潜意识）完成，一些需要思考（意识）完成。如果我们能够养成一些习惯，在潜意识中就完成一些人物，那么这个效率是非常高。好程序员的素质之一，就是将一些基本操作习惯到融入到潜意识中。

输入的习惯

　　有人不会用键盘，这可不是夸大其词。不会用键盘的大有人在，对比一下，看看我们自己是否是这种情况

看着键盘输入

　　对键盘不熟悉，以前没有仔细联系过，没有意识到需要练习。

单个指头敲键盘

　　看起来很酷，没量化得测量过，凭感觉，应该速度不快。
　　键盘是目前电脑输入的主要工具之一，单个指头输入，通常情况下是要消耗大脑注意力的，所以效率应该不高。

键盘敲的很响

　　看起来速度挺快，但是按退格键的比列非常高
　　观察一下自己，按退格键的比例高吗？这会不会是因为，我们重来没有联系过自己如何打字？我也是这两年才意识到这个问题，开始有意识练习打字，减少退格键的使用。

错误别字一堆

　　自从有了输入法之后，我们就开始习惯写别字，手逐渐跟不上脑的速度了。我也需要大量练习

解决之道：减慢速度，刻意练习

　　使用双手输入，减慢速度，强制自己不看键盘，提高准确率。熟练后逐渐提速，习惯进入潜意识后，打字就成了本能。
　　大脑是我们的cpu，让cpu去做IO的事情的，叫DOS时代，你out了吗？

使用快捷键

　　自动有了鼠标之后，一些人就觉得事情简单了，的确是简单了，不过这个简单是针对用户的。我们做软件开发的，和打字员有点像，还得用键盘。所以有段时间我很纠结，为什么鼠标和键盘是分离的，而不是集成在一起的。于是我就找这样的产品，还真被我找到了，遗憾的是国内还没有。
　　回到主题，使用快捷键，是为了减少鼠标使用。减少收离开键盘事件，不容疲劳。看起来还挺酷的。

文本编辑快捷

编译相关的快捷键

调试快捷键

好处

　　将快捷键的使用，变成本能，我们的意识层的思考，就不会被这些IO操作打断

开发习惯

　　日常编码过程的习惯，决定了开发的效率。这也需要大量练习

写一行，就按F5运行

　　F5，是用来调试的，所谓调试就是发生错误了，要重现错误。程序都没有做完，就开始调试，何苦。F5浪费的时间：编译时间，启动运行时间，界面上操作并进入断点的时间。一行代码，要那么多的调试时间，不觉得累吗？
　　之所以要F5调试，我们猜有几个可能：1、不熟悉语言，对自己没有信心；2、写完代码急着看成果，没耐心；3、对业务不了解，在猜代码；4、只是习惯而已。不管哪种可能都是不好的，为什么不把这个函数写完，再一次性确认呢？

思考的习惯

习惯没有界面的程序

习惯看代码推演

测试的习惯

　　我一直都有说单元测试，真的做了吗？ 一段程序都没有运行过就上线，胆儿可真够肥的。

养成测试的意识

　　我一直提醒自己，测试人员是帮我确认工作的，他们工作重点在发布上。我们开发应当保证自己代码的质量。所以我们自己得测试，而且要不断测试。作为程序猿，重复做事情，是可悲的，为什么没让机器做重复事情呢？

　　所以，我们有了单元测试：

• 把以往的单元测试过程固化下来，时不时运行一下，快，又稳定
  
• 次重构，不会痛苦的，因为业务、以前犯过的错误，都已经在单元测试中固化下来
  
• 你有足够的信心说，程序出问题的概率很小

　　程序出错了，我猜可以分成两类：

• 没想到。 通常的教导是要严谨。 如何严谨，我还在研究，所以目前，我没招
  
• 没有做。代码没有运行过，单元测试没有做。 这个很好做到。事实上，绝大多数的错误都发生在这个上面

　　所以，别的不说，单元测试，能提高测试的覆盖率，多数代码都运行过一遍，就是一种 “做过事情” 的保障

测试驱动开发

　　要做单元测试，先要扭转一个思维方式。通常我们都是先想函数实现，再想如何确认。

• 想好函数实现的时候，
  
• 要想好如何确认函数的正确性
  
• 把函数的输入输出确定好
  
• 把函数的单元测试做好
  
• 实现函数（过程中可以通过编译解决语法问题，坚决不运行，我们的大脑有推演的能力，别荒废了）
  
• 运行单元测试，解决没有通过单元测试的代码
  
• 调整代码，做得漂亮一点

做可测试的代码

　　解决代码能测试的问题。常常有人提起，单元测试是好，可是这个代码做不了呀。
　　问：那么多初始化的动作，一个函数要运行，得要周边很多数据加载了才行，初始化完了，黄花菜都凉了，搞个单元测试，测试代码比生产代码还多。
　　答：你看那些开源的项目，下载的源码里面除了生产代码，还有单元测试代码。别拿单元测试不当代码，他们精贵胜过你的函数。他们为什么可以？
　　我们单元测试，一函数为单元，所以一个函数是否可以测试，取决于函数对外的依赖。
　　通常我们说的函数，有确定的输入，有确定的输出，有幂等性。一个这样的函数，能有多少传入的参数？１０个、２０个？不会吧。所以这样的函数是好测的，称为可测试的。如果一个函数，处理传入参数，还依赖对象里面其他的属性，实际上代表这个函数有隐含的输入，幂等性上差一点，可测试性就差一点。如果还依赖其他类对象的属性，那么就更差了。
　　所以，我们做的函数是否可测试，取决于这个函数隐含输入的数量和复杂程度。隐含输入高了，就是不可测试的函数。
　　为了解决测试的问题，我们需要做可测试的函数，有几个方法可以用：

• 把函数进行拆分，往纯函数的方向上去靠
  
• 确实拆不了，通过模拟数据的方式，规避掉

　　你的代码还不能测试吗？写可测试的代码，就可以写单元测试了

经常运行单元测试

　　单元测试就是要经常运行的，它能够报告修改后发生的问题

维护单元测试

使用工具的习惯

　　合适的工具能够帮助我们提升代码质量，加快对代码模块的了解

编码工具

• ReSharp 帮助规范代码，命名，语法糖，进行简单的重构
  
• VS 中的 功能 依赖项关系图 理清模块的依赖关系
  
• UnitTest 单元测试工具，做压力，测试也不错，代码覆盖率统计，挺好的

性能分析工具

• DebugDiag Analyse 分析进程怎么死的，线程在什么地方死锁了
  
• .Net Memory Profiler 进程里面的究竟有哪些对象？
  
• WinDbg 古老而有用的调试、分析工具，就是有点难

开发管工具

• Svn 版本管理
  
• Jira 问题跟踪
  
• CruiseControl.Net 持续集成