作为一名程序员，相信好多人都见过形形色色的项目代码，说实话，很少能见到一些特别完美，特别规范的代码，特别是在一些小公司，我想有好多程序员朋友有这种感觉，对吧，其实，最初的设计都是好的，只不过最后由于业务的扩展，需求的变更等复杂的因素造成目前看到的局面，虽然不想看到这样的结果，但是也不得不硬着头皮去继续维护现在这团代码，近期，一名程序员网友就吐糟了他们的项目代码。
据这名程序员朋友说，他不确定大公司的代码好看不好看，但是他看到他们公司的项目代码跟shi一样，一个函数一眼望不到头，没有注释，逻辑混乱，真是无法直视了，我想他这样的描述，好多程序员朋友也是很有体会吧，在项目中见到一个大长函数，或者一个类文件上万行的情况的确是有，接下来，我们看看其他网友们对他的状况是如何理解的吧！
网友一：我们的工程也shi一样，但不妨碍写PPT时吹牛逼，反正升上去会有其他人接手填坑
上世是朵花：项目代码的混乱其他人是看不到的，只有程序员能看得到，其他人看到的是功能的对外呈现，项目混乱不混乱影响到的是程序员的维护体验，只要代码效率能跟上去，对用户的使用体验是没什么影响的。
网友二：狗屎都差不多，哪有吃起来会香的
上世是朵花：大家这么称呼代码，似乎对代码不太尊重吧。
网友三：见过一个类里就一个函数不？关键是这个类的代码还是好几万行。。。你以为这就完了？no。。。这几万行就做了一个事情，那就是复制数据库中的一条数据然后新插入数据。最关键的是这个代码还是个博士生写的。。。更更关键的是在这代码开始之前我就跟他说过可以用java的反射机能结合数据库查询出来的表字段信息实现。。。原本应该1000行左右能实现的逻辑硬是被搞成这个德行。。。。
上世是朵花：这样的情况是挺糟糕的，有时候发现不好的代码要及时改造，不要在不好的代码上继续累积代码，否则就会发现维护的难度呈现指数上升，最后不得不走向重构的边缘。
网友四：都是屎山堆屎，大小公司的区别无非是坐便还是蹲坑了
上世是朵花：这个比喻有点恶心了，还是麻烦尊重一下代码吧。
网友五：哪里的业务代码都是屎
上世是朵花：在一定规模的软件公司里，代码都是分好几层的，一般像基础数据层部门，他们的代码都是很规范的，变动不是很大，到业务层部门，可能就相对混乱了，因为业务是随市场的变化不停调整的，总不能顺应程序员的维护爱好业务不变动吧，因此业务变动对代码结构的冲击也是一种正常的现象，这就要求程序员们有足够能力去应对业务的变动，对业务层代码可以保持适度的混乱，这也是可以理解的。
网友六：一个文件十几个类，几万行代码，一个函数要翻几页，了解一下
上世是朵花：说这样的状况，我相信，可能这个项目是比较老的项目了吧，估计现在谁在写这么长的函数一定被吐槽了。
从评论中，可以看出，大多数程序员网友们都遭遇代码混乱的处境，这也不能怪谁啊，反正这样的代码都是自己或者自己的同事们一点点累积起来的，因此要想改变这样的局面，就要从自我做起了，养成良好的编码习惯，遵守良好的编码规范，如果你是公司的技术领导层，那就更好了，你应该建立起一个代码管理流程，并确保这个流程制度能够落实下去，只要大家都能遵守并做到了，相信项目代码的状态也会好不少，另外，除了流程上管理，代码的最初设计也是相当重要的，特别是业务层代码的设计，要留出一些变动空间，要设计的足够灵活，相信这样业务变动对代码的冲击就相对小一点了。
以上所有图片均来之互联网
大家好，我是“上世是朵花”。如果你有什么好的看法或者观点可以在评论区展现你的才华，互动交流，如果想进一步了解我，那就关注我吧！
