动态语言就是有这个问题
如果你需要集合为空:
那么使用 if collection.isEmpty 或者是 if collection.size() == 0

如果你需要集合为 null/none:
那么使用 if collection== null/none

这样写代码的时候意图清楚, 看代码的人也轻松.

复制粘贴代码还需要理解?

在 vmware 上测试一下, 一起克隆虚拟机的时候遇到过, 重置地址并重启后就 ok 了, 没有深入研究

当你在前端遇到任何不理解的问题去后端找找就清楚了, 毕竟都是借鉴(chao)后端的

固定大小的缓存区?

光驱 + linux mint

内存和 cup 一样贵系列

soft wrap?

如果这段代码出错后直接 pass, 我觉得可以直接删了这段代码了, 毕竟也没什么用.

今天很卡

取决于你的异常是不是真正的异常, 不要让异常作为你的条件判断或者是前置条件判断.
前置条件判断就是运行这个函数必须满足的条件, 比如你所说的类型错误, 这些条件应该在业务逻辑之前就检测并做出相应的应对措施, 而不是等待运行到业务代码的时候才退出, 这样的话你系统的状态就改变了, 你所谓的 try catch 也就没有什么作用了.

举个例子:

原版
用户输入: 正常参数 1, 异常参数 2
程序执行: 使用正常参数 1 执行删除操作
使用异常参数 2 执行添加操作
程序爆出异常, 你捕捉并打印
现在你系统的状态已经改变了, 用户参数是异常的, 但是用户却执行了删除操作.

改进 1:
用户输入: 正常参数 1, 异常参数 2
程序执行: 参数校验, 发现异常参数并提示用户

这样的话你就保证了系统的状态不会处于中间状态. 这叫做提早失败(我也忘记怎么翻译了)

改进 2:

用户输入: 正常参数 1, 异常参数 2
程序执行: 使用正常参数 1 执行删除操作
使用异常参数 2 执行添加操作
程序爆出异常, 你捕捉并在异常处理中执行回滚操作, 把删除操作回滚

这样也可以保证你系统的状态, 这叫做失败的原子性, 缺点也很明显, 你需要记录很多状态并手动执行事务管理, 而且有些状态是不可回滚的.

改进 3: 参考 java spring 中事务管理的实现, 我目前还没有看到这一块.

以上内容来自<effective java>.

@Admstor 这样啊

@lolizeppelin 目前我也在探索如何使用较为轻松的使用 Python, 现在主推 Python3 的呼声太大, 导致我在选择版本的时候没有考虑使用场景, 在系统运维方面确实只需要考虑 python2.6\2.7.

@lolizeppelin bash 管理软件包就是指用 rpm 和 yum 写 bash 脚本, 关于参数问题, Popen 的例子可能不太准确.

@lolizeppelin java 打包好之后确实不需要包管理

最近打算写一些脚本来做自动化服务, 大概说说我的感受.

1. 首先排除 Bash, 功能太弱, 可读性太差.
2. Python,
- 首先 Python 的版本问题.
在 Centos6 中 Python 是 2.6 的, 如果你想使用 Python 的一些新的特性, 最起码应该是 Python2.7 加一些向后兼容的性的库, 比如 future 库, 不然你会在 byte/str/Unicode 之间备受折磨.
so, 使用 Python 的第一个条件是使用 Bash 来维护 Python 版本, 你不可能每台服务器都手动装 Python.
- 其次, 包管理.
同样的, 你想让自己的生活好一点, 那么你就需要使用一些第三方的库来简化一些原生的脚本, 那么你就涉及到了使用 pip 来管理 Python 的第三方包.
so, 使用 Python 的第二个条件是使用 Bash 来维护 Python 的第三方包.
当然你可以说: 我只用 Python 的原生库, 不需要第三方依赖, 减少维护工作. 当然你可以,但是恭喜你, 你开始重复造轮子了, 而且这些轮子都不能复用, 所以你每次都只能把以前的代码 Copy 过来, 写出了真正的"脚本". 比如你想写一个小爬虫, 那么你是用 requests+BeautifulSoup/Lxml 还是原生的 urllib + dom 解析库呢. 从这个例子中可以总结出来: Python 并没有简化运维这项工作.
- 最后 Python 语言本身的问题.
Python 语法确实接近自然语言, 而且提供一些方便的内置函数, 写个 Demo 确实很漂亮, 可是当你一旦开始写真正的项目, 你就会发现动态语言带来的问题, 前几天打算写一个 Python 脚本调用 Bash 命令, 下面是这个函数的参数列表:

```
class subprocess.Popen(args, bufsize=-1, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=True, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_signals=True, start_new_session=False, pass_fds=(), *, encoding=None, errors=None)
```
请数一下这个参数列表有多少参数, 请告诉我这叫优雅? 参数列表一旦变长, 参数间的组合就有很多可能, 而且还有许多开关参数(布尔值), 导致文档中的许多描述都是: 如果这个参数 XXXX 或者那个参数 XXXX 就会 XXXX. 稍微有点工程代码规矩的人都会避免参数列表超过 3 个, 不然会导致调用者难以使用.
当然我发现有一些在这个函数上的封装函数, 看起来不错, 刚打算使用,发现是 Python3 之后的特性, 我停下写脚本, 开始考虑我这个脚本是否需要兼容 Python2, 如果需要兼容 Python2, 那么我就需要把我服务器的版本升级到 Python2.7, 然后我就需要维护一个 bash 脚本管理 Python 仅仅是为了一些新特性.

总结: Python 并没有减轻一些运维负担, 而是把更多的负担交给了开发者, 包括包管理以及语言兼容性.

3. java
java 作为运维目前还在考虑中, 但是可以知道的是开发者并不需要关心包管理以及语言兼容性的问题.