我见过最长的方法是5000多行，那段代码没人敢动，只敢往下加 if else，每次需要改这段代码的开发都战战兢兢，生怕出现什么莫名其妙的bug。java 可是一门面向对象的语言，一个方法里面有5000多行可以说是很可恶的事情了。我想一开始代码长度可能没这么夸张，是什么导致这种结果的？一个是当初写这段代码的人本身写的是直来直去的方法，一堆if else ；后面迭代的开发，面对这么长的代码瞬间失去了从头读到尾的耐心，直接继续在后面加 if else 迭代，最后这个方法就变成了一个缝合怪一样的玩意。
好的 sql 可以很大程度上简化代码的复杂程度，但是太过复杂sql 本身就会给后来的开发人员造成阅读困难，结果又是变成一条无人敢动的祖传代码，我想这应该是不少公司极度抵制存储过程的原因之一。当然不少银行应用开发还是大量使用存储过程，存储过程有用武之地的，但是一个又臭又长的存储过程就等着变成祖传代码吧。当年我见到一个60多个join的sql，看到第一眼就惊为天人从此难以忘怀，当然那段sql也成了没人敢去动的代码了。
代码逻辑不明
代码逻辑不明所以是我们开发很容易去犯的毛病，是一个不致命却烦人的毛病。在代码上的体现是，逻辑判断写的比较反人类各种双重否定是肯定，不把你绕晕不罢休。或者是写起代码来东一榔头西一棒槌，让人不知道你想干嘛。导致这个的原因有可能是开发人员在需求理解上出现偏差，做到后面发现不对劲，再回去改又不大可能了，只能硬着头皮往下写，结果就是代码弯弯绕绕；还有很重要的锅是在产品经理，任意变更需求，想一出是一出，开发人员无奈只能跟着想一出写一出。还用可能是开发人员方法或者类命名太艺术了，什么四川方言拼音这种没有十年脑血栓想不出的命名咱就不说了。就说那种国产凌凌漆式的无厘头命名——这看上去是个刮胡刀实际上是个吹风机，就这种不知道让人说什么好。
规划代码的核心思想
吐槽了一堆代码规范问题，接下来我们说说如何去规范我们的代码以及如何做到就算开发人员更换了，或者项目转手给他人了，仍然可以让后面的开发可以无碍的去阅读代码修改代码。当然各个公司/团队都有自己的一套代码规范，比如项目的结构、代码命名风格、代码格式等等。不同团队有不同的风格，但核心思想是大同小异的。接下来我就我个人的开发经验来分享一下一些代码规范的思想。
谢邀。我是一名Java后台开发，还是一名工作没多久的“码农”。写代码作为工作的一部分其实不算难，甚至程序员写代码的时间比其他事情花的更少。我就分享一下咱们Java后端开发的小体会吧:
初级程序猿大部分都是写增删改查的业务代码，增删改查最需要技术含量的是查，归根结底都是写SQL语句，有的业务逻辑复杂一点就SQL语句复杂一点，或者数据库里不好处理就在Java代码里处理。只要数据库学的还行，MySQL比较会用，Java功底有一定基础，基本上都能胜任敲代码的工作。
文|热心哥哥宇文笑
文|热心哥哥宇文笑
业务复杂
，有的系统尤其是一些toB的系统，比如一个上市公司的超市人力管理系统，这是非常复杂的，人事组织，薪资社保，还要针对不同地区分公司不同类别的员工进行不同的代码处理。
业务复杂
需求变动频繁
，有些项目的顾问或者产品经理没把控好，导致需求被客户拖着走，搞产品的可能觉得也就变化一点点东西，实际上有的功能代码需要后端重写，数据库的表结构一变，那改动也是得跟着变。咱们敲代码的朋友最不喜欢的就是返工，我们宁愿去接受更多的开发新任务也不想再去重写自己以前写的代码。（不用说什么重构，这些业务代码重构其实并没有什么技术上的突破）
需求变动频繁
代码优化
，其实比较难得住人得，尤其是难住我们这些刚入行的程序员。有的业务数据量庞大，就得先考虑数据库优化，代码多线程优化，总之优化代码倒是一件比较进阶的拆事，比敲代码难。
代码优化
来说说，作为程序员的你，最难的什么呢？
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）