大家好，我是多选参数的一员 —— 大炮。
本篇炸鸡大抵是这个系列炸鸡最后一篇了，感谢各位的阅读和支持。本篇炸鸡依旧是 在编码前就考虑如何减少不好代码 的角度提供一些代码可读的建议。
上一篇炸鸡主要是讲了 「小黄鸭编码法」，是提供一个与自己对话的机会，再将想法写成代码的一个过程。在之前的炸鸡中，我们就知道变量的命名就可以加入更多的信息来提高可读性，但是如果加入过多的信息就可能导致命名过长，可读性反而下降。
这种反弹行为在小黄鸭编码法中也会出现。如果我的想法过大，那么接下来为之的编码也是庞大的，这时候就需要权衡，这样的想法是否必要。
因为我们为项目添加的代码，通常来说，真正的覆盖率是很低的。而且添加的代码由于存在影响范围不确定的可能，需要大量的测试(当然，有些项目就不会这么干，小作坊，但对自己的要求还是不要放松)。同时代码的庞大会导致代码的抽取成库，这些库也会 臃肿，更何况是为了 许多意义不大的代码 而抽取成的库。
剪子
说了这么多，会发现过于庞大的代码会带来高代价成本，其实就是为了提出一个有丶废话的建议 —— 少 写 代 码。
在写代码前，就应该手持一把剪子，去剪裁可能出现的臃肿。而在上文的引子里，不难发现臃肿是从想法开始生长的 。
剪需求
我在的项目里头，策划提供的需求案子永远是经历 「混乱 - 复杂 - 逐渐清晰 - 简练」这一过程。但很遗憾，这个过程每个阶段我都要为之付出大量无意义的编码。(完全就是在为不专业擦屁股，这是一件非常 NT 的事情)
而这一个过程，其实就是不断剪裁需求的过程。当然不单单是需求方的需求剪裁，我们在设计代码的时候，其实也是对代码提出了一个需求，我们也需要剪裁设计，避免过度设计。
例如我们有一个纯业务需求 checkXXX() 中却大量存在检查剩余内存的逻辑，就是为了在极小内存环境下也能做出反应。这种业务操底层的心也是一种过度设计。
也好像以前的软件，总是想做一个超级工厂，啥东西啥功能全都要，这就是过度设计。
function superApp()
-- 可以买东西
-- 可以抽奖
-- 可以社交
-- 可以智能控制
-- ...
-- ...
end
所以直接操起剪子，剪去过度设计带来的臃肿，checkXXX() 直接删去检查内存的大量逻辑，不必去感到肉痛。
而 superApp 则可以拆分为 buyApp/lotteryApp/socialApp/AICtrlApp。
function buyApp() end
function lotteryApp() end
function socialApp() end
function AICtrlApp() end
然后你会发现，这不就是 一次只做一件事 的做法吗。所以还是之前说的：
代码可读性的提升方法，其本质上都是相似的，在于你怎么去理解与使用。
剪实现
需求上的逐渐确定后，就可以开始实现了。当然你还是可以先让小黄鸭游进脑子，但是手上依旧需要持一把剪子，去剪裁代码实现中出现的臃肿。
熟悉一些 API 帮助剪子挥舞
假设我们需要实现一个存放无重复数据的数据的列表，我身为一个不太熟悉 API 的辣鸡，我可能就是这么写的：
# 利用 map 的 key 来做无重复
def unique(elements):
unique_map = {}
for elem in elements:
unique_map[elem] = True
return unique_map.keys()
但是如果你知道有个东西叫做 set，它就是用来存放无重复数据的结构，那么代码的实现就更简单，写的东西就少了。
# 利用 map 的 key 来做无重复
def unique(elements):
return list(set(elements))
所以，熟悉一定的 API 接口会帮助你提高效率，少写代码。可以试着每天花一些时间阅读以下相关的开发文档， 这样当你进行代码实现的时候，很可能会发现：
诶，这个好像用哪个库就可以帮助实现。
当然许多人包括我是很不喜欢 调包侠 这个称谓的，但是这些库的存在就是为了减轻你的负担，将心思专注于真正的工作 —— 思维转为代码。
但重复造轮子也不应该遭人唾弃，只有试着仿造轮子，你才能有真正的理解与学习，工作中的学习大多都是熟悉更多的轮子，而自己的提升永远离不开造轮子的岁月。
Linux 命令已经是稳定的工具
如题所示，我们很容易会忽视强大的 linux 命令。如果你想开发一个文本分割工具，可能会这样：
def text_split(source, split, pattern):
...
...
...
...
其实使用 awk, cat, grep 等命令就可以实现了，我在我们项目的服务器中，一些工具就是直接使用这些命令组合来实现。
小结
本篇炸鸡主要讲述为什么要少写代码，和如何少写代码。少写代码不过带一把剪子就好，想法上与实现上都要用其剪裁。
需求上避免过度设计
实现上可以多利用已存在的代码库来实现，提高工作效率
好了，大致是最后一篇炸鸡小结了，感谢各位的阅读与支持，让我有动力将这个系列的炸鸡写下去。这个系列的炸鸡完全是阅读一本书时的一时兴起，但实在没有想到能够写到现在，为「多选参数」的成长提供一份浇灌。
我其实自认为， 我学习的还是不够深，从而导致写的东西还是不够好，再加上工作上的怪力乱神，使得一段时间没有动笔过这个系列的炸鸡。但是程序锅同我说，是有人催更这个炸鸡的，这很是鼓舞我，于是我便鼓着气力，开始继续将这个系列的炸鸡写完。
所以再次感谢这位读者，要不然我现在也不会在高铁上写完这篇炸鸡。
至于后头的打算，我还想藏着掖着。因为我对自己的学习还在打磨，还在考虑如何输出更有价值的东西，这是我乃至整个多选参数作者们都在思考的事情。而且我目前也在跨行学习的阵痛期，容易间歇性迷茫，还没有绝对的打算。
但是，当所有人都不相信你的时候，你相信自己，并且走上自己所相信的道路，这便是英雄。
不甘于「本该如此」，「多选参数 」值得关注
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
