良好的命名名不正则言不顺言不顺则事不成── 孔子孟子曰“孔子说的对”。命名很重要随便一本逻辑学教材如果读者有兴趣此处推荐《逻辑学导论》里都会有长篇大论来讨论命名的问题我国古代在人才辈出的百家争鸣时期曾经出现过一个学派叫“名家”专门讨论命名的问题比如著名的“白马非马”、“离坚白”等有空读读还是挺有趣的比玩王者荣耀还有趣。笔者认为我国到目前为止出现了三个思想大解放时期一春秋战国时期的百家争鸣可惜被秦皇的郡县制大一统所终结二民国时期西方思想初涌国人似惊雷轰顶如梦方醒三当下技术革命使得中央思想控制力度急剧下降使得底层人民有了选择被谁控制思想的自由请参考如今基于互联网的粉丝文化圈子文化。所以大家一定要好好写代码才不负少年头呀。回归主题命名应该本着不怕长就怕不清楚的原则尽量把一个类、方法、变量的含义交代清楚实际上笔者比较喜欢OC的方法消息命名规则比如(void) buy:(NSString)something from:(NSString)store at:(NSDate*)time;长但是很清楚。下面详述命名接口的命名接口的命名一般都是前缀I加上名词或形容词实际上.Net Framewrok类库就是这样做的比如System.Collections.Generic.ICollection名词System.Collections.Generic.IEnumerable形容词接口往往用来分装一个或一组行为实现接口的类意味着它具有了一个或一组行为的能力所有常用形容词。当实在找不到一个恰当的形容词时名词也可以。抽象类抽象类通常不需要加前缀或后缀也有部分大牛喜欢给抽象类视情况加Base后缀。如下的命名笔者觉得就不错Shape抽象类Ellipse具体类Rectangle具体类具体类尽量使用名词不排除个别情况下把一个行为封装为类时使用动词。方法使用动词或动词性短语。以上。笔者觉得其它的字段啊、属性啊、事件啊出现命名问题的比较少不再讨论。比如有的人喜欢字段用下划线开头有的人喜欢用m_开头都无关紧要求同存异只要使用的词语恰当并不会带来太多麻烦。反倒是如果规定一个巨细无比的规范才有问题一是耗费编撰者的时间二是阅读者也记不住三是阅读者记住了也可能因为和自己的习惯不同而心存抵触。此外需强调一点就是少用拼音多用英文少用缩写多用全称尽量不用拼音缩写甚至是方言拼音缩写还有英语加拼音甚至是英语加拼音缩写......。但也不能排除个别如“计划生育”这样的不好翻译的词语可以用拼音需注释明确或维护词汇表。另外缩写也不是不可以用一些大家约定成俗的缩写比如“Id”使用之并不会带来误解还有利于代码的清晰度。有时候由于英语水平的问题毕竟我们的母语不是英语难免会出现不知道用什么单词的情况。此时可以试试codelf感谢据说是网易工程师unbug开发的此工具。这个应该读作[koʊdɪf]吧但是倒数第二个字母不是I,是L。清晰的结构基本要求if、while等关键字包裹的表达式即使只有一句也尽量使用大括号括起来尽量避免使用直立人时代的goto语句尽量避免过长的方法把大方法拆分为数个小方法方法的职能尽量单一尽量避免重复代码将其转移到公共工具中尽量避免过大的类拆分为数个类各司其职适当的注释注释太多说明代码本身的表达力可能还有待加强。有些实在难缠的逻辑可以写详细注释如果不写注释离职时请注意不要泄露给擦屁股人自己的地址较高要求熟悉以下常用面向对象的设计原则开放-封闭单一职责里氏替换依赖倒置接口隔离再高要求熟悉常用设计模式:工厂方法抽象工厂建造者模式单例模式适配器模式外观模式观察者模式命令模式代理模式策略模式面向对象语言的三大特征人人都知道但是真的用好却是不容易三大特征仅仅是面向对象设计的基础在此基础上建立起了面向对象的高楼大厦。笔者工作多年常感叹虚度年华至今尚未精通面向对象设计之十之五六。笔者想极力推荐一本书《Head First 设计模式》此书乃Head First系列成名之作。此外这个网站不错言简意赅案例经典www.oodesign.com。此外《Java编程思想》开头部分关于面向对象设计的讲解也很精彩。使用成熟的设计模式有两个好处这些解决方案已经经受过了考验用了即使无功但也不会犯错设计模式的名称本来就一种在程序员间流传的概念基于共同的对概念的认识能够降低沟通成本当然也有坏处代码的扩展性虽然是好了但是代码的复杂性也高了这就要求我们最好熟悉常用的设计模式这样就得到了它的好处规避了它的坏处。必须要注意的是不要乱用设计模式只有需求产生了变化或预见了需求将要发生变化才使用这些模式来封装发生的或可能发生的变化。有时候再重构代码时也会用到比如外观模式和设配器模式等。更高要求能力越大责任越大──蜘蛛侠大项目肯定不是一个人能完成的人多了容易发生混乱此时需要团队的领袖勇敢地承担起义不容辞的责任包括但不限于定期维护代码框架、分层结构。写的时间长了难免乱领袖人物要定期排除及时消除臭味引导小弟们做代码审查。审查的意义不在于监督而在于学习和维持良好的态度。学习指通过代码审查学习别人的长处同时帮助别人进步。保持良好的态度是指如果预知了有人会看自己的代码那么就会自觉地尽量把代码写工整即使审查代码的人偷懒没有真真看过正所谓如果人人都相信三尺之上有神灵那么也就没人做坏事了宗教的积极意义就在于此扯远了。过目数据库设计及时更新或委派组员更新文档关于文档还需多说一句只有再非常有必要写文档的情况下才写文档。如果写了一大堆可有可无的文档代码更新后文档也要及时更新很难做到的。一个新手面临着一堆和代码脱节的文档只会起误导作用以代码本身的表达力和口头交流为主以文档交流为辅两手都要抓一只手硬一只手软。不十分差劲的算法相信大部人做的项目都是性能不敏感的只要稍稍注意就能做好。比如该使用分页的地方就使用分页该根据条件查询数据库的就别一次都查出来该优化数据库就优化数据库。此外压力测试也很有必要有的性能问题只有在数据量大了的情况下才出现。很多性能问题都是到了生产环境中才暴漏出来的。代码之外和团队建设比起来以上只能算是雕虫小技只起到了一个锦上添花的作用。如何使团队保持活力保持积极性才是最重要的通常也是最容易被领导忽视的最难做好的这些已超出笔者能力范围和本文的论述重点有机会再写。祝大家工作愉快作文以记之