>백엔드 개발 >파이썬 튜토리얼 >过度追求代码短小优雅有什么害处?

过度追求代码短小优雅有什么害处?

WBOY
WBOY원래의
2016-06-06 16:24:021573검색

本人目前是尚是一枚acmer,方向web开发, 同时python,php,golang,js等语言都有所涉猎.

由于接触python较早.深受python拿来主义的影响.平时写过很多小项目,但几乎每个项目都引用了很多开源项目,而且代码长度都极其的短.

如最近的一个某某管理系统.整个前台只有一个静态页面,数据全部使用json格式传输,用angularJs渲染界面.主体angularJS+Bootstrap+jQuery然后还有几个Bootstrap和jQuery小插件.服务端是php+mysql+Memcache,同时设计服务端时甚至想过升级nosql数据库和使用golang替换php.这样的阵容估计比某些大型企业的管理系统还大.自己都觉得有点小题大做.
然后完成整个前台增删查改,统计了一下自己的代码发现代码量还不到1000行(除去引用的库代码).估计全部完成撑死1500行.

别人一个页面模板代码就1000行..经常听到某某学长一个星期开发出某某网站,然后上万行代码.那个惭愧

然后自己写的一些数据抓取的脚本什么的.代码量也小得可怕,撑死200行.但是却引用了一大堆不知名的开源项目.而且像下面这样的代码到处都是

userList = [ i.split(":") for i in open("user.txt").read().split("\n") if len(i) >0]

回复内容:

其实嘛,在微软,如果有一个人用了牛逼的算法,或者什么奇技淫巧,反正很高大上的把一个东西搞了出来,但是别人看不懂,这个时候我们会被要求开讲座和写教程,来教会同事们,不然方案很可能就会被否决。

所以说只要这个代码的作者也可以时刻做到这样的话,害处大概不大吧。

凡事都讲个“度”,你自己都说“过度”了。
最大的坏处就是可读性差了吧。

ps:最后那个例子我倒觉得还好,不算很过分,还不至于影响别人理解。

问题中多处提到"过度", 提问者恐怕心中大概都有自己的答案了.

追求代码短小, 可以通过不同的方法, 只要是选择能提高可读性的方法, 其实未尝不可. 例如题目中的代码, 其实还没做到短小优雅, 这样做可以更短小易读(这行还不到80个字符), 通常是更推荐的做法.
<code class="language-python"><span class="n">userList</span> <span class="o">=</span> <span class="p">[</span><span class="n">line</span><span class="o">.</span><span class="n">split</span><span class="p">(</span><span class="s">":"</span><span class="p">)</span> <span class="k">for</span> <span class="n">line</span> <span class="ow">in</span> <span class="nb">open</span><span class="p">(</span><span class="s">"user.txt"</span><span class="p">)</span> <span class="k">if</span> <span class="n">line</span><span class="p">]</span>
</code>
浪费时间在别人制定的规则系统里“优化”自己的行为
while (i >= x || j >= x) { x = (i % x == 0 && j % x == 0) ? (y = x) + 1 : x + 1; } 曾经写着玩儿的一个求最大公约数的方法,现在连我自个儿都看不明白了,可见代码的易读性是多么的重要!
——成心文的微博|新浪微博
过度追求代码短小优雅有什么害处? 如果产品开发要求快速迭代,在满足时间和性能需求的情况下使用开源库,又能保证代码精简,我认为这本身无可厚非。

从我的经验来看,可能有以下几点需要注意的:

1、公司的法务部门是否允许使用这些开源库

开源协议那么多,也许某个库的协议会造成公司产品的法律纠纷,这种事情应该尽量避免

2、快乐的使用各种第三方库的时候,也请注意优化问题

除了性能优化之后,还有一些奇怪的问题需要优化。

前两天看豌豆荚的一个视频 “豌豆荚:成长的烦恼”,里面提到随着代码的膨胀,遇到了一个dex的函数上限65536的瓶颈,不得不反复合并函数。
其中提到对第三方库的选择时,要注意不要为了使用一个功能,却引入不必要的包袱。

Python我不熟,不确定会不会也有类似的坑,仅供参考吧。

3、最后一点,却是最重要的一点,越精简的代码,越要有充分的注释


一行糅杂了多个库函数的NB代码,当时写出来可能爽的一笔,心中暗骂自己真TMD的是天才。
过两天再看发现完全搞不懂当初为啥这么干了。

这种事儿我干过,不止一次。

比方说长长的正则表达式,注释里面写上匹配目标的范例,绝对没错。
在你需要更换平台时,很可能需要改写正则表达式的写法,参考范例放在那儿,写单元测试也好搞。
但是有一次我忘了……

所以,充分的注释是必要的,不仅为别人,更为自己。 对于Python
建议看看PEP 8 -- Style Guide for Python Code

我初学的时候也喜欢用各种「trick」来让代码看起来「碉堡了」
但是其实易读性太差了, 其他人看的时候都会一边看一边骂... 某牛人说过:“代码先是给人看的,再是给机器执行的”。
某古人说过:“物无美恶,物极必反”。

所以追求是好事,但过分追求,不免带到极端。
人生苦短,追求什么得想清楚。:) 大型项目开发时可维护性和可扩展性很重要..短小有时候可能会和可扩展性有矛盾。过度引用, 尤其不知名的开源项目可能会和可维护性有矛盾...优雅嘛...如何定义优雅...?

P.s.: Go + AngularJs是很正常的搭配...没有特别觉得这是一个overkill.... 短小的代码主要看一个问题:对后续程序员的理解是否增加了难度。

如果理解容易的话,这没有问题。

如果不容易理解的话,那尽量还是写多一点代码,方便容易理解为主。

实际的开发工程中,代码往往是会经过多个程序员的手,容易理解很重要,过度追求代码短小是不提倡的。

这个度的把握要靠经验的,根据不同项目不同团队而不同。

上面的代码有一个小问题: 你用了变量i, 如果用line可能更好理解。
성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.