iOS开发--从细节做起写干净、清晰的代码

     细节和架构一样重要！

     耐住性子，这篇文章不会有代码出现，要的无非两个字，干净，一定要苛刻的要求干净
     你是否有时候自己的代码自己都不想看？你是否有过改过几次需求之后，你的工程已经完全负担不起下一次改动了？
你有没有见过几百甚至几千行的代码，你有没有看过一些代码，里面都是些a1,a2,a3这样的变量或者方法？你有没有和同事合作时，有些人的代码你喜欢看，有的人的代码你不敢看？你有没有遇到过有的同事如果离职，他的代码不会有人接手，只能废弃重来？

     曾经我以为是架构的问题，是经验的问题，是技术水平的问题，我花了很多时间去学习框架，我觉得一个优美的框架可以解决一切问题，可惜最后发现，这远远不够。

     把设计、架构这些暂且抛开，这里只说一个词，干净！
 
     一定要拼了命的干净！

     我是相当痛恨混乱无序的代码，教训太惨痛了。这里我想借用 《代码的整洁之道》 这本书里面名家说的话。

1. 我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。
   
2. -Bjarne Stroustrup，C++语言发明者

复制代码

1. 整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
   
2. -Grady Booch，Object Oriented Analysis and Design with Applications（中译版《面向对象分析与设计》）一书作者。

复制代码

     我无意做概念上的抄袭，只是今年在做去年开发的总结的时候，对代码加入了一些自己的要求，这个要求对交给我现在的同事和以后组里新来的人手里，作为项目组开发的基本规范执行。然后这个时候接触了《代码的整洁之道》这本书，有点醍醐灌顶的感觉。那些基本要求做了修改，现在是这个样子，大家可以看一下，这个是我纯主观的想法，如果有不同的意见欢迎讨论。

   1,命名，命名就是注释。
        用驼峰法，比如 doSomething
        类名：头字母大写
        方法名：头字母小写
        局部的子方法里允许 int i这种，但是常用的方法中，必须写成 int xxxIndex
        临时变量命名        tmpXXX
        然后，如果发现命名不对，或者后来发觉其他命名方式更好，用项目的命名修改工具修改

   2,方法（函数）
        方法名一定要能做注释，如果必要，加方法注释，如果IDE允许，一定是那种别人在引用你的方法的时候了可以直接看到的注释（这里解释一下，      记得java中可以通过在函数前面加/**xxx*/加注释，这样当方法提示的时候，会自带这种注释提示，xcode,mono都有类型的功能）
        一个方法只做一件事，尽可能这样，如果一个方法做了n多事，拆分。
        一个方法不允许出现大于100行的情况，正常50行以内(这个要求已经很宽泛了)，如果大于100，拆分，没有时间，自己找时间拆分
        方法内，相关的代码写在一起，不要有空行，相关度小的，留一个空行
        良好的缩进，这里不做强制要求，采用两种缩进中的一种，根据个人习惯
        能私有的方法一定要私有，不要让大家看到(OC是通过类别来实现的)
        多用代码组的工具，并加入清晰的注释
        （Xcode中，是通过 #define mark xxx注释 来让方法分组的）
        （Unity3d中的mono工具是 #region xxx注释 #endregion）

   3,注释
        如果命名能做注释，就不要注释
        如果不得不做注释，尽量是那种别人调用的时候可以直接看到的注释
        类的每一个和其他类有关联的成员，都写上注释
        如果一个注释已经过时了，删掉或修改掉

//以上1,2,3 针对团队所有人

   4，关于框架
        每一个类尽量只做一件事或一类事
        少用继承，多用组合
        类内高内聚，类之间低耦合
       UI和数据分开，如果有足够的时间，把处理逻辑也分开写
    5，重构
        唯一不变的就是变化，游戏开发尤其如此，适当的时候，提出重构
        频繁，多次，自己抽时间做重构
    6，关于合作
        对每一个人做的东西，让他有一个系统的概念，不要今天做这一块，明天做那一块
        合作尤其要求代码的可读性，一定要让自己的代码别人可读
        如果你是一个程序员，做好自己的代码，如果你负责很多人，让每一个人写好自己的代码，然后，你写好清晰的接口
        和策划谈需求时尽量搞清楚，开始做的时候去白班上画图，让开发者都清晰的知道设计思路和每个人做什么
        诱导为主，拒绝依赖性的问问题，这个态度一开始就要让问问题的人知道

      很多时候，需求的变动和时间的压力会让一个开始很干净的工程慢慢变得一塌糊涂，没有捷径，除了细节上的注意，就是一遍又一遍的重构。个人认为项目中绝大多数时间是在维护代码，而不是写新代码，既然要维护，能够一眼看清的代码是最好的，而团队合作又会把代码的可读性问题无限制的放大，尤其是遇到一些很聪明常常自作主见和一些偷懒的人的时候。基本的规范是一定要遵守的，而这个习惯也会有助于程序员越走越远。每一次重构都是一次脱胎换骨的涅槃，其中的痛，只有身在其中的人知道，很多时候都是自己在下班时间做的。
        

   补充内容 :
      补充一点，xcode里面开发程序的时候，自己写的代码，warning，第三方的，warning处理到 个位数，或者全部处理掉
      继续补充一点，咆哮同学说，这整篇文章说的都是微操，至于架构，那是大局观的问题，打dota或者魔兽对战或者星际的同学们一定懂的。大局观神马的，我还差蛮多呢