转载 - 《开始做软件开发时，最希望听到的七条建议》

本文来自依云’s Blog，转载请注明。

看到的一篇很棒的感想，我觉得准备进入软件开发行业的童鞋们都值得一看。以下为转载内容。

在 Twitter 上看到一张写在长图片里的文字**《当我开始做软件开发时，最希望听到的七条建议》**，记录一下感想。

读书
书确实要读，但每年都读软件工程方面的书，会受边际效用递减的影响的。毕竟软件工程并不是很大的话题，而工程还是得实践出真知。看过几本之后，不如把精力花在更理论和学术的方面，比如编程语言理论、分布式算法、概率论与统计、博弈论，等等。总之就是要「move on」。而实际上我读的书更杂一些。

编程语言
学习多种编程语言是极好的。但也千万不要限于两种，尤其是别 Java + C# 或者 C + C++ 这种组合。会一叶障目的。我在大学期间学习过非常多种编程语言（几乎是把我听说到的都学了个开头）。

我的建议是，至少 C 系一门，ML 系一门，Lisp 系一门，脚本系一门，简单学一学。然后挑自己感兴趣、用得上和有钱途的深学。了解过的编程语言越多样，学习新语言就越容易，甚至可以在不学习的情况下上手阅读、做小改动。

测试
测试确实挺有用的。但更多的时候，它挺烦的：不是代码本身坏了，而是测试坏了……

现在我更看重的是，一个像 Rust 甚至是 Idris 那样强大的类型系统，能在省力的同时发现更多的疏忽。

Python 的类型注解不是很强大，不过也是非常有用的。

重构
我不太明白作者在这里讲重构是什么意思。

我的习惯是，按需重构。如果一份代码一直良好运行，我才不管它写得有多糟糕呢。但当我要修改它的时候（不管是为了添加新功能还是修 bug），我会把看着不舒服的代码给顺势改掉。

一个很重要的点是，不要为了重构而重构。另一个点是，重构中的代码应当是可以正确运行的。至少每天工作结束时提交，提交的时候代码应当是可以正确运行的（可能有 bug，但不能有未完成而无法运行的部分）。这样，重构可以随时因为各种原因中止，不会影响后续不相关的工作，也不会分出分支来时间一长根本合不回去。

我才不要假设我的代码可以使用五年。再过两个月 lilac 就要六岁了，而 nvchecker 已经七岁了呢。

lilac 经历过三次重构。开始重构的原因是，一开始并没有想到会发展成现在这样子，管理一千多个包，每天都要打好几十个。所以那时候的代码写得很烂，全局变量也很多，以至于新功能加不上去。前两次重构都是在我有闲的时候，拉一个分支出来，看哪里不顺眼就改哪里。可问题是，改了几天之后，我完全无法预测这代码还跑不跑得动。另一方面，修新 bug 当然是在老代码上改的。那我重构到一半的新代码怎么办呢？作为业余项目，这种情况持续一些天之后，我稍一忙碌，把它放下之后，我就再也想不起来我当时的重构思路了。

第三次重构，并不彻底，但是它很有效。因为每次改完收工的时候，我会判断它现在能正常跑起来吗？如果觉得不行，那就 git checkout .。有希望才提交，然后上线。跑出 bug 就去修。忙了就放下，等有时间才继续。思路不那么重要了，因为代码是好的，换个思路也可以继续。

当然了，类型注解在重构过程中我加上了许多，也避免了很多疏忽导致的 bug 被提交上线。

结对编程
并没有人和我结对啊……

工作经验和舒适区
我不是很理解什么叫「舒适区」。不过我主动做的工作，要么能解决我当前面对的问题，或者是想要达成的目的，要么能让我学到有意思的东西。一直重复昨天的事，你们把这个叫「舒适」？？

分享
这正是我正在做的事情呢。不过很可惜的是，我并不太会讲话，所以现在流行的直播我还是算了。写作还是比视频有意思，又省力、又能有深度，多好。