在代码的世界里，是享受的，好多对编程感兴趣的程序员，挥挥洒洒几百行代码，感觉不到累，反而倒是感觉很有成就感，很是享受，我想部分程序员网友有这种体会吧，然而，在代码的世界里，也有很多痛苦，比如，看别人的代码，毕竟代码只是一种语言，每个人的操作章法又是千差万别，大部分人的思维可能都差不多，写出的代码大众化，都能看得懂，但是也不排除有的人思维可能比较奇葩，不按什么套路出牌，再加上遇到一些无注释，无文档，无人问的代码，大牛看了也会忍不住邹眉头，近期就有一名程序员分享了他接手项目的一个情况。
据这名程序员网友所说，他是刚接手这个项目，打开后60%的代码都曝黄线，if判断写的跟爬楼梯一样，controller里面各种逻辑判断一个方法几百行，这个项目的作者前几天离职了，现在轮到他来维护这个项目了，让他感觉很棘手，这名网友说好想把那个程序员拉过来暴揍一顿，这样的情况他该怎么办，让我们看看其他网友们都是怎么看的吧！
网友一：不怕造飞机，就怕修飞机
上世是朵花：有这种体会，毕竟开发新的是按照自己的思路，算是在自己的舒适区内做事，维护别人代码可能就需要走出自己的舒适区去了解其他人的思路了。
网友二：前人挖坑埋后人
上世是朵花：这话不仔细看还以为是：“前人挖坑后人埋”会以为说的是：“前人挖坑，后人填坑”，其实这名网友说的不是“后人埋”，而是“埋后人”，看这情况说的更严重了。
网友三：看着一个七千行的类，抱怨一番，默默加到了九千行
上世是朵花：这句话怎么似曾相识啊，好像再哪里见过似的，这样的做法是逼迫系统一步步走向重构的边缘啊！
网友四：事实就是这样，先解决有无问题，优化？不存在的。老代码更是这样，不敢乱改逻辑只好添加新的分支判断
上世是朵花：能够理解，有时看是荒唐的做法也是无奈之举。
网友五：ifelse完全是职业素养问题，和需求啥的，重构啥的没关系，最简单的拆方法都不懂
上世是朵花：没错，有的时候，我们虽然没有能力去改观整个项目的所有代码，但是我们可以做到把我们自己的那一部分代码写的精致一点，让后人看着很舒服，从而也不会被骂。
网友六：我是接手一个PHP项目，还是用tp3搞的，真不敢直视，接口直接输出html，看的我一愣一愣的
上世是朵花：可见这个项目比较古老了，这样不友好的写法的确有，并且更让人觉得烦恼的是，有的代码虽然很遭，但是业务很火，代码还在高频使用，修改起来也必须很慎重。
华为员工：我在面对一个9014行的.c文件
上世是朵花：家家都有一本难念的经啊，各种各样的高难度维护。
网友八：这就是代码，为什么平均两年一重构的原因，不重构实在不行了
上世是朵花：没错，如果没有良好的代码管理制度，最后都可能走向重构的边缘。
每种不好维护的项目代码，都是从第一行代码写起的，都不是一开始是这样的，前期如果不太注重代码的规范与质量，就已经打下了不好的基础，后人只能在这个基础上一步步累积，最后歪楼。这种现象的产生，我个人认为责任主要不在一线程序员们，比如有的程序员很讲究代码质量，代码写的很精致，但是他接手了一个地基没打好的项目，他也很无奈，只能在这个不好的地基上继续开发，这个原因主要在于技术管理者，技术管理者除了负责技术方案制定，项目的跟进之外，代码流程的管理也是相当重要的，制定代码规范，让所有人写的代码是一个风格，统一大家的思维，让整个项目的代码看着就像一个人写的似的，并且有完整详细的代码注释与及时同步的项目文档，这样的话，相信不论是多少届人员的更替，代码看起来仍然很舒服，从程序员网友们的评论就可以看出有相当一部分公司存在着代码管理的问题，因此，作为公司的一名技术管理者，在这方面要做的事情还是任重而道远啊！
以上所有图片均来之互联网
大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！