世界月新日异，计算机技术的变化可是最有代表性，手机基本上每年都更新迭代，每隔几个月总会有让人耳目一新的新技术新体验出现， 让人应接不暇。作为it男，看见这些炫酷的数码产品，真是馋的流口水呀。可惜囊中羞涩，根本跟没钱去买新品，一个手机都只能 到降价平稳期才敢下手，有个两三年都不敢换。作为穷人，只能努力工作咯。
作为互联网从业人员，在各种奇葩业务逻辑中浸淫多年，也有了点自己的小技巧。不然真会被代码折磨致死，从此失去信心，进而患上忧郁症。 还是要抗的住压力，怼的了产品经理，脸皮够厚，体格够壮。 下面聊聊我个人的小想法
$role_has_api = app(ApiForRoleRepository::class)->get($roles_api_has_search);
if (!$role_has_api) {
return false;
}
return true;
return app(ApiForRoleRepository::class)->get($roles_api_filters);
以上两种写法第二种明显简洁，但是我还是偏向于使用第一种。为什么呢 1.函数返回值尽量类型一致，这样调用的地方处理返回值比较简单，由于php为弱类型语言，可以自己在函数内进行变更 2.B代码片段返回值依赖了被调用的函数，这样容易给人困扰，返回值是什么 还要跟进去看 3.B代码不利于调试排错， A代码块在增加日志时不用对已有代码进行更改，只需增加日志代码，B代码却需要修改原始代码，增加变量来进行日志 跟踪。 同时在使用git进行diff比较时 A 也更清晰
if (!$project_is_open = $this->projectIsOpen($params['project_id'])) {
return false;
}
if (!$this->projectIsOpen($params['project_id'])) {
return false;
}
我更倾向于第一种，貌似化蛇添足
1.同样 第一种利于增加代码进行扩展，利于排错
我对王垠大神的《编程的智慧》 中提到的观点很赞同
代码不是一蹴而就的，灵感是星星点点，陆陆续续到来的。所以代码需要反复提炼。每当我们过段时间回头看自己代码的时候总能发现一些改进。 大神都这么说，作为悟性普通，能力普通的程序猿，在面对自己代码缺陷时还有什么可脸红的？ 只要能反复推敲，不断进步就是好的。最怕的是 吝啬代码，不愿意做出改变
优雅的代码大体的结构上来看，就像一些整整齐齐，套在一起的盒子，井然有序，思路清晰.
要能给函数的作用起个名字，如果你没有词汇能给你的函数起名字的时候，说明这个函数可能不是个好的函数，需要警惕了
对重复常用的代码，不管有多短，都 应该提取出去做成函数。
真正的好代码是自解释的，直接看名字就知道干的啥事
这样容易造成混淆，尽量减少局部变量的作用域
由于中间变量具有意义，步骤清晰，变得很容易理解
并不是语言提供什么，就一定要用上它，只用经过千锤百炼，觉得值得信赖的一套
不要盲目依赖操作符优先级
要一眼能看出代码是想干嘛
不要忽略分支，不要偷懒
现实工程中应该看的近一点，不要被"将来"所拖垮