软件开发需要注意的，都在这儿了

许多开发人员在程序编写许多年以后，常常在具体工作中的经验教训中学会了许多本应在大学阶段就了解的程序开发王道。我太难了，早干什么去了……

1、不必太在乎“代码行数”

你或是听见过许多有关“代码列数”的疯狂基础理论，但请不必把他们当真。根据代码列数来做技术性策略是一件很荒诞的事儿。代码列数能够 为我们出具的信息内容是很有限的。实际上，在大部分情形下，代码列数能够 为我们出具的信息内容为零。根据代码列数来做技术性策略相当于根据一本书的页码来分辨书的品质。

有些人觉得，新项目的代码越小就会越易于搞懂，但这一看法只说对了一小部分。我觉得，有着易读性的代码应当具有下列这类特点：

一致性；

自描述；

保持良好的文档；

应用了稳定性的特点；

不会太繁杂；

特性不会不好。

假如是因为减小代码列数而损坏了这类规范，那才算是疑问。实际上，假如你尽可能去遵照这类规范，代码列数自然会处于1个很极致的位子，压根不用刻意去测算到底有多少行代码。

2、并不一定要把开发语言区分“优劣”

大家常常会这样说：

C 语言比某某语言好，是因为它的特性更佳。

Python 比某某语言好，是因为它更简约。

Haskell 比某某语言好，是因为这是异类。

应用一段话来评定和对比一种开发语言是对语言其本身的抵毁。他们是开发语言，并不一定什么口袋精灵。

开发语言相互之间的确存有差异，并且极少存有“没有用”的开发语言（除开一些落伍或是早已死了的语言）。每一种开发语言都是在一些层面做到了衡量，他们就如同工具箱里的工具。起子能够 做铁锤没法做到的事儿，但你能够说起子比铁锤更佳吗？

在讲出我的开发语言评定规范之前，必须先弄清楚1个疑问。开发语言的挑选极少会对1个新项目起着实际性的功能。假如你写的是前端开发代码，挑选不会过多，但一般而言，开发语言的挑选仅仅取决于新项目成功与失败的1个不那样关键的要素。

下列就是我觉得在挑选开发语言时必须考虑到的许多要素（早已排好序了）：

是否有许多有关实例教程；

开发设计速率；

出现 bug 的概率；

库生态系统的品质和深度广度；

特性；

容不容易招工。

只不过，有许多场景是你没办法操控的。比如说，假如你是一位大数据工程师，那或是就要用 Python、R 语言或 Scala。假如仅仅1个个体新项目，那完全能够 挑选应用你最喜欢的开发语言。我在挑选开发语言时仅有一条规范：假如 StackOverflow 上与这门语言有关的疑问不多，我便不会应用这门语言。并不一定说碰到疑问自身搞不定，只是是因为花过多时间在这类疑问上面不怎么值得。

3、浏览他人的源代码是个烦心事

浏览他人的源代码我觉得并非易事。Robert Martin 在《整洁源代码之道》里提及过这一难题：

实际上，大家花在浏览源代码和花在敲代码上的时间比例超出了 10 比 1。浏览旧源代码是写新源代码的1个组成部分……因此，容易读懂的源代码会让写新源代码的工作变得更容易些。

有很长一段时间，我被浏览他人的源代码这件事情所困惑。以后发觉，我觉得有很多人都跟我一样，每日必须应对这一难题。浏览他人的源代码就好像在浏览1本用外文写的书，即便源代码是用你熟知的语言写的，源代码的设计风格和构架依然会不太一样。这一难题不大好处理，但是我发现了下边这类做法将会会对你有一定的协助。

审查他人的源代码有利于提高浏览源代码的工作能力。在过去的2年中，我审查了许多 GitHub PR。每审查完1个 PR，我就越能够融入浏览他人的源代码。GitHub PR 很合适用于提高源代码阅读能力，是因为：

随时随地都能够审查，只需要找到你要想添加的开源项目；

在规定的范围之内开展训练（1个功能、1个 bug）；

需要专业专注关键点，驱使你细心查询每一列源代码。

第二类方法有点儿特殊，这同样是我一直都在树立的，能够给我节约许多时间。在掌握了某一项目的源代码设计风格以后，就用这类设计风格来敲代码，如此能够提高浏览这类设计风格源代码的工作能力。由于你早已感受过相似的设计风格，因此再去浏览如此的源代码就不会感觉生疏。

4、不必尝试编写“完美无缺”的源代码

一些时候，原以为每1个程序猿都是会编写完美无缺的源代码，而编写“完美无缺”的源代码是需要支付时间和支付的。

曾经的我因此感觉焦虑，但在添加了团队以后，我才发觉，没有人会写“完美无缺”的源代码。但为什么进入到生产环境的源代码总是那么“完美无缺”呢？答案是：源代码审查。

我所处的团队里有许多聪明人，他们全部都是很有工作能力且有信心的程序猿。假如有人胆敢递交未经许可审查的源代码，他们必定不会善罢甘休。即便你感觉自身是另一个比尔盖茨，也没法防止犯错误。我讲的不单是逻辑性错误，还包含拼写错误、丢字符这类的。

取得与一些乐意跟你抠关键点和给你建议的人协作。忠言逆耳，但这同样是提高自己的1条路径。在接收源代码审查时要谦虚，不必把它跟个体联系在一起。他人审查的就是你的源代码，而并不是专门针对你。

在审查他人的源代码时，我会用谷歌搜索引擎解决方法，看一下源代码的解决方法与时兴的解决方法有哪些不同之处。一般而言，怀着“初学者”的心理状态会发觉很多他人发觉不上的难题。

5、程序猿并不是无时不刻都在敲代码

它是个很常见的问题，但几乎没人可以列出1个清晰的答案。

非常少有人每日敲代码的時间会超出 4 个钟头。

假如有人并非这样的，那说明他们的企业应当对他们更好一点。程序编写是一项很消耗头脑的活动，一个人一星期 5 天、每日 8 个钟头都是在敲代码是根本不科学的，除非是是以便赶项目进度，但这样的事情不应当是常态化。假如一所企业由于管理上的问题或是不愿招更多的人而让你加班加点，那就没有必要忍受！

另一方面，即便你每天花费 8 个钟头敲代码，对你的企业而言也未必有益处。你的老总很有可能会觉得这样子非常好，但我觉得它是一类短视，由于从长久看来，这样做会危害到生产力和职工的身心健康。

需要说清晰的是，我并非提议你每日只工作 4 个钟头。此外的 4 个钟头你还需要：

做调查研究；

与同事探讨；

帮助他人解决困难；

计划以后的工作；

参与编码审查；

开会。

我本人强烈要求每日必须按时歇息，做一点健身运动，即使是简易的健身运动。我发现了，健身运动有利于缓建心理压力，帮你能够更好地集中精神实质。