Heim >Backend-Entwicklung >Python-Tutorial >过度追求代码短小优雅有什么害处?

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

WBOY
WBOYOriginal
2016-06-06 16:24:021566Durchsuche

本人目前是尚是一枚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可能更好理解。
Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn