什么是好的习惯？

------声明-------

请不要转发我的文章，也不接受评论。

-------------------

 

我经常批评我们的程序员同学没有养成好的习惯，至于什么是好的习惯，每个人都有自己的解读。我想说一下我的见解：

1. 遵循事物发展的客观规律，按照正确的软件工程模式来工作。

怎么理解？

案例1：有很多同学接到一个任务后，马上想做的事情是百度搜索，看看有没类似的项目，然后施展我们的长项 - copy and paste。

首先我不反对去复制现有的东西，因为站在巨人的肩膀之上，可以省掉很多的effort，但是你首先要问一下自己你是否懂这个“巨人”吗？ 一般来说复用代码需要更高的技能， 我希望你们可以去学习，但不要复制，即使你复制，复制的时候也要一个个文件代码来复制，至少读过一遍，让自己完全理解他在干啥。从初学者的角度，很难理解别人在用什么技术栈，背后用了什么magic的framework？

一种框架有n种变体，而作者的用意可能需要很长时间才能GET到，而这些来回折腾，将耗掉你宝贵的项目时间。

案例2：有同学说“我已经理解需求了”，所以我可以跳过做页面原型直接直接开工了。

这发生在我叫某些同学去做一个系统页面原型的时候，他只做了个结果列表，加上一个非常简单的新建页面。

这就是功夫不到家的问题，首先，你理解需求，我作为老板可能不清楚你是否完全理解，因此你作为程序员应该做足功课把你的理解完全展示给我看，而且，我是给你足够的时间去做事，你却自认为自己需要做高级工作不去做足这些事情，

......

软件工程说到底还是需要覆盖必要的生命周期，比如需求、设计、开发、测试、部署等，无论如何敏捷，都是为了更好地完成这些环节。

我们推崇原型法，无非就是想把需求管理做到更直接（并实现UI重用），我们做show and tell，告诉用户我们的理解，100%呈现产品最后形态，减少rework的机会，因此你必须重视，每一个输入框的表现形式，问清楚数据源，搞懂数据流程的来龙去脉。

我们还推崇了VMC法则，让你们通过视图分析出模型和接口，一步一步，把功夫做到家。

 

2.“工欲成其事必先利其器”，做好配置管理工作，不要浪费时间在低级错误的事情上面

工具：我上个月至少帮过3位同学设置本地环境，我发现的通病就是“命令行无法跑java”， “无法跑mvn”， “无法跑git”，pom.xml没有设置正确的编码，pom.xml没设置正确的文件编码、库和插件.....许多这种好像微不足道的事情，实际上会浪费你几天的时间，JAVA是非常简单容易安装的，JAVA_HOME没有设置正确你可能都不清楚你的java是用哪个JDK跑的，IDE有问题的时候，你首先应该检查没有IDE的时候是否正确，然后进行排除法。

一个干净的工作坏境对任何程序开发都相当重要。

除此以外，我整体强调必须设置好DevOps工具链的重要性，很多小伙伴喜欢在本地打包，然后war包或jar包在服务器有这样的问题那样的问题，这些都是配置管理问题。一个非常简单的例子，oracle jdbc肯定不在maven central，那那你就得在本地把这个jar加进去。

还有，很多小伙伴需要本地改了代码，打包给测试，再改配置，打包给生产，这些都是非常不好的习惯，为什么不可以一份代码，到处部署，为什么不可以分离配置与程序？你试想一下，如果你花多几个小时把这些细节搞好了，以后会节省多少时间？这就是我为什么要强推一键部署工具的原因。

 

日志：日志是程序员的眼睛，很多同学很不注意，到处打system.out，甚至不打印任何日志，因为他觉得本地IDE可以DEBUG，我根本不需要日志。这就是非常幼稚的想法，难道你会在生产环境跑IDE吗？

你在编码的时候就应该想象一下未来技术支持的困难。正确把日志打印，什么时候需要debug日志，什么时候要写info，什么时候写异常，这些都是基本编程技能。至少你得培养这个习惯意识。

 

伪代码：很多人是programming by coincidence，在《Pragmatic Programmer》中有这章节，说的大概是，有些人写到哪儿，碰巧就去处理什么问题了，也就是说他编码的时候是没有思考的，只是这么写着写着就去处理那些问题了。

（In a nutshell it means writing code without really understanding what you're doing, how your snippet of code or app works. While everything seems to be working just fine on the outside, it might break later on for reasons unknown to you. ）

我觉得习惯非常不好，一版比较好的做法是，先写伪代码或注释，理清楚自己想怎么下手。

比如我希望有几个类，这个方法的处理流程是1、2、3.。 这些注释可以让别人更容易理解你想做什么。

 

命名：我之前有发现部分同学的命名很大问题。这也是习惯问题，必须要让人“懂”，有些人以为做页面原型就不需要良好的命名，这也是大错特错，因为你的命名代表了你的domain和function到底是怎么设计的。这也是我强调程序员必须要学好英语的原因。至少你得懂查词典，不要用拼音。命名的好坏可以看出你是否专业。

 

3.抓住核心矛盾，优先完成MVP（Minimal Viable Product）

我也曾经批评过一些同学，做事情不专注，因为他做A的时候，会想到无数的其它问题，而忘记了自己连基本的A功能也没实现。这也是习惯问题，我觉得这是思考习惯的问题，思维该发散的时候要发散，集中的时候要集中。

我们有非常好的例子，有的同学会很专注把一件事情做完，遇到任何不懂的东西都会仔细研究，这是非常好的习惯，因为企业老板就喜欢这样的做法。

我们的项目有非常多不确定性，但是我们更需要同事专注的是完成确定性需求。

 那些无关重要的事情，在老板眼里往往是钻牛角尖。

 

4.养成好的时间管理习惯 - GTD （Get Things Done）

非常简单的道理，做事不要拖泥带水，该完工的把它结束掉。

没有完美的软件，只有在不断完善的软件，而我们需要有节奏地去做事情，所以有些事情需要结束就要结束。

 

5.好的习惯要以交付为目标

没有发布的软件没有商业价值，这是基本的共识，因此如果你要告诉别人你已经做完了，就需要把你的东西及时发布出去。

好处显而易见，让人看到你的成果，让客户实现业务价值。

 

6. 养成使用GIT的习惯

我有说过当我们ERP/WMS组在做页面原型的时候，大家并没有使用GIT，虽然我们早就创建了仓库，但我发现是空的，也说明你们浪费了一个练习使用GIT的机会。

GIT作为业界流行的工具，应当作为我们日常最重要的工具之一来使用。

如果打tag，什么时候打tag。

什么时候做feature branch。这些习惯等你养成之后，你会发现你不会再因为代码丢失或者无法回溯而感到烦恼。

 

7.记录你每天做的事情，比如些笔记或者JIRA记录每天的工作

我建议JIRA，因为这个会便于日后去评估团队的绩效。

有同学做得很好，把每天的工作都记在本子上，目标性非常强。

 

 

暂时写到这里，希望认真阅读。