一周技术思考（第17期）-废墟的召唤

大家好，这里记录，我每周读到的技术书籍、专栏、文章以及遇到的工作上的技术经历的思考，不见得都对，但开始思考总是好的。

 

废墟的召唤

 

我诅咒废墟，我又寄情废墟。-余秋雨

 

当我看到这句话，很合意了我近段时间所面临的要解决的问题情境。因为是我在写文章，我便自己做了主，借此机会，接下来我想抒情一下。

 

回想这么多年的程序员生涯，大体很符合一个架构上的场景，读多写少。大部分是在读别人的代码，小部分时间是写自己新的代码，更确切点说是大部分在读别人代码的基础上，来写自己的代码。

 

那些混乱的代码就是废墟，但你又必须在废墟上工作。

 

直到读了《遗留系统重建实战》中的序言里面的下面这段话，就更戳中了心中的疙瘩。

 

曾看到大段大段混乱的代码辗转反侧，不得入睡，生怕改错了一行而引起其他未知功能的缺陷；

 

曾对代码中一个几千行的方法中某些奇怪的注释--”请勿动这段计算逻辑“ 而深感无力；

 

有没有一丝阳光能够划破这重阴霾，照亮我的空间，驱除那一片片废墟，是有的，直到...

 

我维护了一个电信的系统，其设计精良简单、实现稳定可靠，且容易修改与添加新的功能。其设计思想让我发现了代码的奇妙之处和威力所在，从此点燃了我的软件开发之路，一往直前。

 

营造之初就想到它今后的凋零，因此废墟是归宿；更新的营造以废墟为基地，因此废墟是起点。--余秋雨

 

 

《重构 改善既有代码的设计》你没看过，《软件修改的艺术》你没看过，《遗留系统重建实战》你没看过，《代码整洁之道》你没看过，但你从业这么多年，真的就没有闻到过下面这24种味道？还是你已经麻木了，只顾交付需求了事？

 

摘自《重构 改善既有代码的设计》目录栏

 

但是，又在你交付的需求过程中，真的就没有被混乱代码坑过吗？就不痛？

 

就不想着哪怕一丝丝改变？

 

你缺少的不是梁咏琪，就是实在的勇气，拾起勇气，去做别人的那道光吧。

 

图自网络

好了，到这里，应该有一根分割线。

 

上面，我承认是我感性的表达，在这第一个主题结束前呢，我想再理性理性。

 

你说代码质量好坏，是用什么来评判的。

 

那我先说下，基于一个应用系统的基础，我们通常会面临的两个问题。第一个问题是，需求交付时长的问题；第二个问题是，线上出现事故的问题。那么，如果一个应用系统自上线以来，一直没有发生过这两个问题，是不是就默认你的应用系统架构是好的，应用系统的代码也是好的。

 

你会在这样的情况下，捯饬自己的代码吗，当然，是会有同学去做的，我之前也说过，每个团队中，都还是有一些有追求的程序员。他们所追求的正如下图所示的那样，要编写可维护的代码，能用业务语言识别的代码，能让同伴容易阅读的代码。