代码最佳实践：为您的未来自我编写代码

2015年11月，我踏上了一个激动人心的新旅程，构建一个iOS应用，将iPhone上的图像和视频投射到连接Chromecast的电视上。 在Swift中，作为一个单独的开发人员，作为一个辅助项目，所有这些都在其中。

在这篇文章中，我将分享一些考虑因素和实践，这些因素和实践已帮助我在3.5个月内将代码扩展到4000行以上，同时又将技术负担降至最低，并最大程度地提高了可维护性。 快速预览：

就上下文而言，第一个版本的功能已完成约50％，因此我希望代码库最终会翻倍。 与我以前的所有应用程序和客户端项目相比，我估计在编写更多模块化代码而更少编写模块化代码的同时，我可以更快地增加价值- 至少两倍 。

事不宜迟，这就是我的工作方式：

口头禅：为维护性和未来自我而设计

• 力争绝不重复代码
• 始终将源文件保持在200行以下
• 代码本地化获胜。 凝聚
• 不要分散属于同一类的多个类代码。
• 使用类内部的扩展对确实属于一起的功能进行分组。 这使得在需要时更容易将事情排除在外。
• 适当地命名事物
• 最小化可变状态
• 仔细考虑对象图中的所有权 ， 尤其是对于异步调用
• 使用ViewModels驱动UI更新
• 在添加新功能后始终进行重构
• 添加新功能后，请务必进行广泛的测试-在添加新代码之前先修复AKA错误
• 默认将所有内容设为私有
• 在Interface Builder中完成所有UI和布局。 代码不是您的表示层所属的位置！
• 错误处理对于应用程序设计至关重要
• 使错误对开发人员和用户友好
• 程序员错误应立即消除
• 奖励 ：将开发容器用于我计划开源的自包含代码，例如这样。

到目前为止我还没有做

• ReactiveSwift ：我很想尝试一下，并在应用程序中利用Observables的功能 ，但是还没有机会。
• TDD / BDD /单元测试-尽管我已经对依赖注入进行了仔细的考虑，并且上面的约束迫使我保持​​班级小。
• 集成测试。 由于我总是在添加新功能之前修复错误，因此这并不是一个强烈的要求。 但是，我为接收器应用程序构建了一个伪造/存根 ，以便在没有可用的Chromecast设备时可以测试大多数应用程序。 另外，我可以在运行时在假/真实接收器之间切换。

其他注意事项

对于这样的附带项目，我发现尝试每天取得一些进步是有益的，并且如果不进行任何工作 ，通常连续三天不能超过。 这使我始终专注于产品，并且我可以计划新的工作或考虑如何持续解决问题。

在单独构建此文件时，我可以使用一个Google文档来跟踪进度，错误，待办事项，里程碑和日常任务。 在现阶段，我发现这比拥有专用于每种情况的专用工具要简单，这在大多数组织中都是如此。

最后，我选择将其作为辅助项目进行构建，同时将大部分时间用于客户服务。 好处：

• 交付所需的压力较小，压力较小 —我可以花些时间正确处理细节。
• 我可以在此应用程序上进行尝试，并为我的客户项目带来一些有价值的想法。
• 我可以为我自己和我的用户 （而不是经理或投资者） 构建它 。

尽管我对到目前为止的结果感到非常满意，但我计划在几个月后编写一份后续报告，看看以上所有内容是否仍对我和项目有用。

注意 ：此故事是 此博客文章 的修订版本 ， 于2016年2月12日发布。

想在大电视上观看您的照片和视频吗？ 那么 Cast Player 是适合您的应用程序。 注册 邮件列表 以接收产品更新。 您还 可以 使用TestFlight 获得Beta版访问 权限。

有关更多此类故事，请 订阅我的邮件列表 。

如果您喜欢，请单击下面的so，以便其他人在中此看到此内容。