2022年，我一共写了136028行代码

你好，我是阿秀。

2022 年底的时候，gitlab 给我推送了我这一整年的数据，过去一年我一共写了 136,028 行的代码，代码合入一共911 次，研发活动一共参与了 476 次。

我的gitlab年终报告当然，这 13W 行代码是有水分的，实际上并没有这么多，比如后端Swag文档自动生成，前端NPM包安装之类的都会引发代码行数的变动，嘿嘿。

每月四周，去掉双休的八天，那就是每月 22 天工作日，一年 12 个月，就算我过去一年都是铁人，没请过病假事假等等乱七八糟的假，那么过去一年中我每天差不多都会写 136,028 / (22 * 12) = 515，差不多每天 515 行代码。

一天500来行不算多，但不算少了，2022年算是我比较忙碌的一年了。

在写这13W行代码的过程中自己也养成了一些好习惯，今天就分享一下一个合格的程序员在写代码过程中应该具有的好习惯。

前言

我先把结论放在这里

• 重视模块化
• 需要重视抽象但不应该滥用
• 保持代码美观易读
• 先理顺逻辑，再写代码，而不是一边写一边想。

当我们刚接触编程时，会在网上看到许多大牛写程序都十分注重模块化，因此许多同学就会模仿他们，之后同学们可能会去看 SICP，了解到了抽象的好处，然而就会记住在写代码时思考抽象类的问题，这些都是比较有帮助的。

以往一直有这么一句话：“程序员的成长与代码行数之间的关系非常微妙”。

之前看到一个大牛写的一篇文章中有这么一段话：程序员在 2K、20K、200K 行等规模时会觉得自己明显的遇到瓶颈。

如果不用科学的方法学习，可能超过上述这些行数的代码就会难以自立。

所以说，保持一个良好的编程习惯，一定会让你在学习和工作中事半功倍，受益终身。

取个好名字

曾经在程序员论坛发起过一个投票“程序员最头疼的事情有哪些”，结果非常有趣，近半数程序员会认为命名是最头疼的事。

规范的命名对于阅读程序是如此重要，所以在阅读代码时，理解一个变量和函数都是从名字开始的。

它是什么？它的职责是什么？

这些问题从名字就应该看出来，如果名称需要注释来补充，那就不算是好名字。

例如：将变量名

// 记录提交结果

修改为：

valcommitResult;

将函数名

/**

修改为：

fungetOfficeTelephoneNumber(){

宁可名字取长一点，也不要起个模糊的名字。一个清楚的变量名还会带来可搜索的好处。

即使在写二分算法时，也尽量别用"l"和"r"来指代左右边界，换成"left"和"right"会更好。

不过，变量名也并非越长越好，去除变量名中的冗余也是一个好习惯。

Variable 一词永远不应当出现在变量名中，Table 一词永远不应当出现在表名中。

nameString 与 name 没区别，moneyAmount 与 money 没区别， customerInfo 与 customer 没区别， theMessage 也与 message 没区别。

命名风格应该保持统一，每个概念对应一个词。

如果一堆代码中既有 Controller，又有 Manager，还有 Driver，Presenter，就会令人困惑：他们之间有什么区别？为什么不全用 Controller？如果同一概念可被多个词语描述，请确定其中一个名字，并在你的代码中一以贯之。

总之，取一个精准的名字是一名优秀程序员的基本功。从一开始学习编程时，每次取名都应仔细思考，切不可草草了事。

代码美观

大家可以感受下两种格式的代码：

classSolution{
classSolution{

一定记住需要先理顺逻辑，再写代码

有些程序员可能每天都在修复昨天和大前天的 Bug

你是否有过这样的经历：代码删了又写，写了又删。

在敲代码之前，先问自己一个问题：我写下这行代码是真的能用上吗？会不会有逻辑漏洞？思考清楚业务流程之后再写代码，往往事半功倍。

以之前同学经历的项目为例，项目已经做了一年， 除了三方库，代码量共有两万行，平均算下来，开发者一年来每天只需要写 55 行代码。

这样看来，开发者的每一天都差不多是”很闲的“，然而开发者每天都忙得不得了，从早到晚都在码代码。

这些代码量如果纯粹敲出来，最多十个小时就可以完成。

我们应该用大部分的时间思考代码逻辑，不要花大量时间将代码删了又写，写了又删。

磨刀不误砍柴工，事先做好全面的考虑，争取让写下的每一行代码都有价值。

代码需要“美观”

美观的含义是整洁易读，之前看过一个实验，一个程序员非常不认真的写了混乱不堪的小程序，这种情况下，程序行数超过 200 行就觉的非常难受了。

在需要进行一点小的修改时，往往需要花很长时间去寻找到底该改哪里，十分吃力——这种吃力感大概只有经历过的同学才有体会。

这说明了，大部分人并没有过人的天赋能在混乱中轻易找出清晰的脉络，也就是说，好的习惯一定会带来好的结果，想如鱼得水，那必定需要注重美观。

梳理代码逻辑是有一定方法的，例如：

• 通过画图工具先将逻辑画出来，流程图、UML 图、时序图、思维导图都能对你有所帮助。
• 写接口之前先模拟出假数据，测试逻辑层没有问题之后再写接口，可以避免写出的接口不合适。
• 善于写伪代码，将程序需要实现的每个步骤先用抽象的伪代码写出来。具体实现时再将伪代码细化。
• 写代码之前先编写测试用例，将你期望的输入输出写在测试用例中。

适当重构

开发者应该保持爱折腾的习惯，不安于现状，才能做到与时俱进。

软件之所以叫软件，正是因为它是”软”的，需求随时在更新，上星期的代码放在今天也许就不再合适。

也正因为软件是软的，我们可以很方便的通过重构改进它。

只要有良好的测试用例，就大胆的重构吧！这里列出一些应该重构的时机：

• 当你需要添加一个新功能，突然发现程序耦合严重，导致新功能不是那么好添加，那就先将程序重构到可以方便的添加新功能。
• 当你阅读代码时，发现程序可读性低，导致理解上的困难，显然代码还不够清晰，先将其重构到一眼能够看出结构。

你找到一种更好的实现方式，千万不要因为现有的代码仍然可用就置之不理。

尝试将你的想法实现出来。即使失败了，你也会更能理解为什么代码是现在这个样子。

定时备份

如果程序中用到数据库操作，一定要记得定时备份。

数据库备份有诸多好处：

• 可以防止数据丢失
• 可以在程序出错时方便数据回滚，并且成本很低，只需要写个脚本完成定时自动备份，并删除过老的备份数据即可。

如果数据库没有做备份，而数据库又被误操作删除了的话，那就等同于晴天霹雳。

所以代码也需要及时备份，使用版本管理系统可以解决这个问题。

用上 Git，随时 commit，丢失代码的情况几乎不可能发生。

写在最后

养成这些看似不经意的小习惯，真的十分让人受益。

如果没有，那请尽快重视起来。

如果有，请一定坚持。

本文转载自公众号：拓跋阿秀