由“程序员三大法则”想到的
今天无意中看到《程序员三大法则》，很搞笑：
第一法则
程序员不得损害产品质量，或袖手旁观产品质量受到损害。
第二法则
程序员必须服从产品经理的命令，除非违背第一法则。
第三法则
程序员必须保护自己，除非违背第一和第二法则。
据说还有一条繁殖定律：
繁殖定律
程序员不得参与程序员的孕育和培养，除非新程序员的行动符合以上三大法则。
其实就是改编的《机器人三定律》，参见wiki上的定义：中文或英文。我比较感兴趣的第一条和第二条。结合自己最近做的项目，不免有些感慨。
从自己开始学习编程，到接触开源项目，再到现在参与、主持项目，虽然自己的编程能力有所提高，但是仍然觉得自己编程远不够规范。记得上周我所在的兼职翻译小组有篇文章，我大体扫了一眼，大致就是说项目换人之后，后来的人看到代码大都会骂垃圾代码。我没有再往下看，笑着就把这篇文章pass掉了。又有前一阵子我一个师兄去实习，MSN签名改成了“ugly code”，我一看就想笑。
很久以前觉得自己写的代码很好，而且还洋洋自得。后来接触了一些开源项目之后发现人家的那代码写的才叫漂亮：
(1)无bug，经过严格测试。
(2)robust，代码严谨，考虑周到，异常该在哪层处理就在哪层处理。
(3)简洁明了，可读性性好，有注释。
(4)设计合理，代码冗余少，合理而充分利用各种模式和数据结构。
(5)功能强大，可扩展性好。
以上是我的一些看法，至于什么样的代码是好代码，关于软件工程的书上有论述。其实我觉得好的代码至少应该满足或部分满足：
1.代码本身能运行，跑起来没问题。
2.需要使用代码的人能读懂。
3.尽可能的被复用。
4.给别人留下改进的空间。
还有两条我没有写，因为不同的环境要求不一样，它们是效率高和安全性好。
见识过漂亮的代码之后，我就一直朝这个方向努力，不再写垃圾代码。但是事与愿违，垃圾代码还是不时出现在我的笔下。客户的特殊需求/需求变更、考虑的不全面、设计的不好都是出现垃圾代码的原因。比如说有时候程序设计好了，编码的时候客户突然说要实现某某功能，结果只能添加许多if-else语句来改变业务流程；比如说有些String或者对象没有判断是否为空；再比如说有时候为了实现某个困难的功能，采取了堆砌代码或者使用过多变量的策略。
可能以后进了公司会有需求分析师和架构设计师，但是现在情况是一个人什么都要干，包括分析、设计、测试等等。因此以后要注重提高自己的需求分析能力和设计能力，不能整天以程序员的眼光看待事物，要不以后真成代码工了。代码工和农民工没什么本质性区别，只是干的具体活不一样罢了。
至于项目经理，这个就不多说了，这是下级与上级相处的办公室规则。跟个好领导比什么都重要，要学会与上司相处。
还是有一定意思，哈哈！
那个繁殖定律好没道理。。这不是说程序员不能教出程序员么。。。。
只是为了套用机器人三大定律而已。
当程序员是机器？？？？？？？？？？？
呵呵 程序员有这么惨吗？
真把程序员定义成机器了……