跳槽来济南团谱将要满一年了，这一年里发生了许许多多的事情，技术学到了很多以前没有碰到的新知识
手写代码，利用代码来编写控件和界面。这种的非常适合使用在一个大项目当中，有利于对常用控件和事件进行重用，代码编写项目有利于多人合作，非常便于管理，不利的地方在于项目周期长，当某个界面大改版的时候比较复杂，需要重写该界面或者修改之前代码的时候会使人晕头转向，即使注释准备的很充分，当换成别人来进行改版或者修改bug的时候很容易使人晕头转向
xib，用来组织ViewController或者loadView的，每一个界面或者特殊控件都会带着一个。xib文件，非常便于对项目的管理，非常容易让人阅读和对项目进行维护，同时，省去了大量的时间和代码，从而得到更快的开发速度，不利的地方在于维护性比较大，对于版本的维护很差，即使是打开一次xib，都需要提交一次，多人合作，很容易出问题，在使用xib时，辅以部分代码来补充和完成功能几乎是不可避免的。关于这点在开发时应该予以高度重视。
StoryBoard，苹果近年来强烈推荐的一个项目编写方式，可以把StoryBoard看做是一组viewController对应的xib，以及它们之间的转换方式的集合。可以非常明确的看到每个viewController的布局样式，也很明确的知道各个viewController之间的转换关系，代码少，开发周期短。但是这种方式对ViewController的重用很差和自定义的view的处理非常麻烦，每个ViewController都需要自己去制作，而且，不利于多人合作，一个StoryBoard如果多人共同开发，这会是一个很麻烦的问题，因为所有的UI都是写在同一个文件中，不过苹果公司也没有禁止只使用一个StoryBoard，一个项目中，可以根据功能来进行选择使用几个StoryBoard，并在相互不干扰的情况下进行开发，这样就不会存在所谓的冲突问题。
我入门IOS的时候先使用的StoryBoard，后来在第一家公司大量使用xib来编写，可能是习惯了xib了，总觉得StoryBoard缺少很多东西，然而被迫使用StoryBoard一年了，现在感觉StoryBoard使用的要比xib更好用一些吧
对于开发人员来说，跟着大方向走应该是一条明智之举，近年来，苹果一直在鼓励使用StoryBoard，虽然说一开始使用起来会很不舒服，跟手写代码和xib写项目比起来，可能会有这样那样的问题，但总的来说，使用StoryBoard更加轻量化代码，使得开发效率最高
其实，使用StoryBoard已经将近一年了，对于我个人来说，灵活使用StoryBoard，xib和代码是一种明智之举吧，功能使用StoryBoard，通用控件使用xib来写，代码做辅助，这样编写项目的效率会很高。
总的来说，如何更加高效的减少开发周期是开发人员不断地去思考的问题，程序员是一批不断变着花样偷懒的员工，如何偷懒更多的时间，是一个值得思考和总结的问题。
