首先明确一点，合适的人是指纯技术团队的建设。一支战斗力再强的技术团队，面对一个朝三暮四，分分钟推翻自己原有想法的产品经理/项目经理，再好的戏也唱不出来。花几个月加班加点做项目，还没发布，直接推翻重做，这时候你就得去楼下ATM机看看卡内余额了：余额够了，收拾收拾好找下一家了
合适的规范
大家都理解软件开发需要合适的规范：代码规范，程序规范，流程规范等等，以此来减少意外的出现：最少惊讶原则。但在实际执行中却会碰到各种情况，其中最大的问题是：怎么鉴别哪些规范是需要强制执行，那些规范是推荐执行。规范的强制执行带来的是代码的可读性提升和二义性减少，而坏处也是显而易见的：对于大部分有想法的程序员而言这种规定太死板，容易引起抵触心理，产生不安定因素。这种情况常见于各种标准的外包公司。 而如果大部分的规范设定为推荐执行，在没有良好的引导下，规范容易被忽视。 网上有很多关于ObjC的代码规范，比如苹果自家的规范和《Google Objective-C Style Guide》等。这些规范一般只有两种分级:推荐和不推荐。而我更推荐把代码规范分成五个等级：强制要求，强烈推荐(但不强制)，良好，可接受和不可接受。以下仅举部分例子加以说明。
类名开头大写，方法和变量名以驼峰法命名。强烈要求，这没有什么好说的，苹果系统类库和绝大多数的第三方开源库都是如此。但在部分苹果的sample中也看到过用m做前缀表示类成员变量的写法，这些都是属于遗产代码的问题，仍旧是可接受范围，但是自己代码内部使用类似匈牙利的命名法就是不可接受。 类名使用至少三个字符做前缀，内部方法使用两个下划线做前缀。强烈推荐。上面的做法可以最大程度避免和系统类库发生重名的情况：因为苹果宣称保留所有两位字符前缀的使用权，同时其内部方法命名以一个下划线做前缀。 无论使用K&R Style还是Allman Style都是可接受的范围，但是强烈推荐在一个文件内保持一种形式。 在保证代码可读性的基础上保持代码的简短和统一性：小类，小方法，统一的函数返回。小类，小方法可以保证他人阅读时更方便地关注类逻辑，而不是具体细节，而统一的函数返回可以减少意外错误和降低错误排查的难度。而保证代码的简短和不罗嗦也是很重要一点，经常会看到如下代码： > (count > 1) { return YES; } { return NO; } 真心无法直视。
郑州知网计算机软件有限公司拥有雄厚的技术研发实力，致力于为客户提供完美的原生APP开发解决方案。把握市场动向，深耕APP领域。您的电商大业，由知网软件守护
豫公网安备 41010402002388号 网站地图 http://www.ur10.com/