srcmini本文概述
自加入网络以来, 我已经在srcmini担任工程师大约一年, 从事相同的WebRTC框架项目：Ondello, 该服务通过WebRTC连接医生和患者。将Google+视频群聊用于医疗保健。
(WebRTC是一项允许通过网络浏览器进行实时通信的技术。最好的例子再次是Google+环聊：没有任何外部小程序, 你就可以进行实时视频聊天。这里写的很好。)
当我第一次加入Ondello时, 我被聘为高级Ruby on Rails开发人员, 任务是从头开始构建服务。如今, 我们是一个由多个开发人员组成的团队, 他们在相当大型, 复杂的系统上工作。
在这篇文章中, 我想分享Ondello背后的故事。具体来说, 我想谈谈：
- 尖端技术(例如WebRTC)如何特别困难……
- 一个简单的WebRTC Rails应用程序如何变得不那么简单, 并且…
- 聘用的Ruby开发人员如何最终几乎没有编写Ruby代码。
尖端技术及其带来的问题
如前所述, Ondello完全是关于WebRTC平台的。但目前只有Chrome, Firefox和Opera无需使用插件即可支持WebRTC调用。我们的目标是支持所有浏览器(Safari和Internet Explorer是上面列表中明显的遗漏), 因此, 我们必须使用相对较年轻的插件。
当我开始使用插件时, 事情进展顺利, 因为他们有很好的文档以及官方的WebRTC教程和指南。但是随着我们产品的扩展和需求的复杂性的增加, 情况变得更糟了。这并不像解决Rails问题那样简单。
缺乏WebRTC支持社区
由于WebRTC是一种较新的技术, 并且特别是该插件是相当新的(仍然需要邀请才能支付相当高的使用费), 因此它们并没有吸引大量的开发人员, 更不用说WebRTC Rails开发人员为人们编写指南和教程了。像我这样的。这些因素严重损害了周围的开发人员社区, 而实际上这是根本不存在的。
我从未认为这是一个主要问题, 直到我错过为止。对于大多数应用程序平台和技术而言, 一般情况很容易处理, 但要在特定的期限内以特定的方式使事情运行, 这需要对技术有深入的了解或与其他开发人员接触。
想象一下在没有StackOverflow的世界中进行编程-生产力受到多大的影响？
当然, 我们可以访问该插件的开发人员, 他们的帮助如我所料。这缓解了一些问题, 但与简单地使用Google搜索” WebRTC插件foo由于bar而无法正常工作”不同。
谁有毛病？
那里的每个软件都有错误。
但是对于这些新的WebRTC技术, 很难知道谁是父亲, 谁是孩子。换句话说：当我们发现一个失败的测试用例或明显的错误时, 尚不清楚我们是否有错误, 或者我们是否正在利用代码库中的错误。
在Google上可以轻松地搜索到的大多数技术, 变成了一条庞大的电子邮件链, 随后进行了代码审查, 并在某些情况下与WebRTC开发人员举行了会议。
在Google上对于大多数技术而言, 可以轻松搜索的内容变成了一条庞大的电子邮件链, 随后进行了代码审查, 在某些情况下还与开发人员举行了会议。
就此而言, 由于该插件的开发团队和我们自己的团队, 我的错误率大约为50-50。
WebRTC平台的频繁更新
此WebRTC插件的相对初期状态的另一个结果是更新速率。较年轻的软件更新频率更高, 而这些更新通常会中断。有了该插件, 我们将无法继续使用旧版本(作为电信技术, 所有用户都必须使用同一版本进行相互通信), 因此每个版本都需要重构。
这些更新是痛苦的。通常, 我们会有稳定的代码, 必须完全重写这些代码才能与最新更改同步。在某些情况下, 测试会在没有解释的情况下失败-如果没有社区, 那么你将在哪里寻求帮助？
在某些情况下, 测试会在没有解释的情况下失败-如果没有社区, 你将在哪里寻求帮助？
WebRTC移动支持问题
随着我们产品的增长, 我们的大多数客户开始询问有关移动支持的信息。
如果WebRTC JavaScript库很困难, 那么Android库就那么困难了。我花了两天时间来编译示例应用程序, 花了五个多小时才了解它是如何工作的-整个过程赋予了”痛苦的”一词新的含义。
经过10个小时的编译失败, 我精神崩溃, 哭了一下。将自己放在一起, 再过两个小时, 我就能使工作正常。 Pff-奥巴马说你应该制作自己的视频游戏。
WebRTC iOS库更加容易, 并且开发团队显然已经花了更多时间。我们能够在短短几个小时内将其投入使用。
WebRTC符合JavaScript
除了WebRTC插件之外, 我们的JavaScript代码库还教会了我很多关于复杂性的知识。由于大多数WebRTC框架都是基于JavaScript进行配置的(例如, Plivo的VoIP网络框架), 所以这是我在Ondello工作的头三个月中唯一使用的语言。
随着我们代码库的增长, 它自然变得越来越难管理。我们具有深层嵌套的回调, 不良的模块化等等, 这是初创公司在WebRTC JavaScript应用程序中的首次尝试, 而且你可能会觉得有点杂乱。
最终, 我们过渡到了CoffeeScript。这样可以减少代码库的大小并显着提高其可读性, 但不足以解决我们真正的复杂性问题。
PubSub
然后, 我们找到了PubSub, 这是一个很棒的JavaScript发布/订阅库, 我对此不太推荐。这个小家伙帮助我们解耦了JavaScript逻辑的很大一部分；我们的重构过程因其发现而实现了最佳转变。
为什么PubSub如此有用？ WebRTC本质上与媒体和连接有关, 因此充满了事件。使用PubSub, 我们可以轻松地高度抽象地监视某些事件。这是一个很棒的解决方案, 也是解决未解决问题的一个很好的例子：当你拥有编写良好, 文档齐全的开源(甚至专有)解决方案时, 可以简化你的代码库并加快开发速度, 请使用它们。
具体来说：如果没有PubSub, 则每次用户的相机关闭时, 我们都必须更新三个表示相机状态的复选框：
camera_went_off = function() {
$(''#checkbox1').removeAttr('checked');
$(''#checkbox2').removeAttr('checked');
$(''#checkbox3').removeAttr('checked');
}
使用PubSub, 我可以触发” camera_went_off”事件, 并让所有三个复选框都监听它。此外, 如果有人单击了这些复选框之一, 它也可能发布此事件, 以通知其他复选框进行自我更新。
使用AngularJS创建单页WebRTC应用程序
如前所述, 我们正在使用WebRTC插件来支持更广泛的浏览器。但是, 每当用户加载新页面时, 都必须加载此插件。这会对性能, 流动性等产生可怕的影响。
唯一的答案是在用户进入网站后立即加载插件, 并确保用户没有重新加载或进入其他网页。这听起来不可能。但实际上, 可以使用单页应用程序(SPA)来完成。
此时, AngularJS开始发挥作用。
使用Angular, 我们过渡到了SPA。用户进入站点时, 他们会加载一次插件, 并且只能加载一次。性能提升是瞬间的。
Angular允许我们构建一个SPA, 这反过来又使我们可以加载一次插件(当用户进入系统时), 并且只能加载一次。然后, 由于插件已经加载, 因此用户进行的任何调用都几乎是瞬时的。这项工作花了很多功夫, 但得到了回报-性能提升是瞬间的。
Angular还通过强制执行MVC结构改善了我们的JavaScript代码。尽管大多数JavaScript必须重新编写以与Angular模式啮合, 但这是值得的。
WebRTC符合CSS
我们在CSS中遇到了类似的复杂性问题：模块化不太正确, 样式重叠等。要说我们的代码库与许多其他系统相比是庞大的, 这是不公平的。在初创公司工作的小团队：1)时间至关重要, 2)组织至关重要。
使用CSS降低复杂性的关键是使用Sass和Compass。
第一次使用Sass时, 我对此并不满意。但是今天, 我无法想象没有它的生活。简而言之, Sass是一种CSS扩展语言, 可让你以Sass语法编写样式表并将其编译为CSS。
Sass具有许多出色的功能：变量, 控制指令, 一般的SassScript等。但是真正让我吃惊的是, 萨斯的嵌套规则对Ondello产生了巨大的影响。
这些是最好的例子。没有Sass, 我可能会有一些CSS代码, 如下所示：
.container_div {
float: left;
height: 10px;
width: 20px;
}
.container_div a {
margin-left: 15px;
}
但是, 使用Sass, 可以简化为：
.container_div
float: left
height: 10px
width: 20px
a
margin-left: 15px
在这个简单的示例中, 我仅保存了几行。但是想象一下, 如果我有一些可以用Sass表示的行业级CSS代码：
.admin-section-menu
width: 270px
float: left
margin-right: 8px
padding-top: 30px
ul
padding-right: 10px
li
width: 230px
a
float: left
text-align: right
letter-spacing: 1px
font-size: 20px
color: #666
width: 220px
margin-bottom: 20px
&.active
a
width: 230px
color: #52672d
&:after
content: '\25b8'
display: inline
position: relative
left: 10px
Compass是一个CSS创作框架, 建立在Sass之上, 确实帮助了我们进行界面设计。我们使用Compass来帮助制作精灵。如果你有兴趣的话, 这里有个很棒的教程。
借助Compass, 我们可以加快复杂按钮的创建速度。就像将按钮的图像状态放在一个文件夹中一样简单, 这时Compass会生成一个包含它们的精灵。
在此示例中, Compass读取Administration_buttons文件夹中的所有文件, 并将它们放入单个sprite文件中。
@import "administration_buttons/*.png"
@include all-administration_buttons-sprites
.add-user-button
width : 37px
height : 37px
cursor : pointer
float: right
@include administration_buttons-sprite(add_user)
&:hover
@include administration_buttons-sprite(add_user_rollover)
通过@include Administration_buttons-sprite(add_user)命令, 我将文件add_user.png添加为add-user-button类的背景图像。
使用Compass, 我要做的就是将一些图像放在一个文件夹中。
没有指南针, 我将不得不：
- 将所有图像放在一个文件中。
- 获取每个图像的所有坐标, 并将它们放在课程上。
对于像我这样并不特别精通Photoshop的开发人员来说, 这可以节省大量时间。而且, 在此阶段, 时间至关重要。
WebRTC与Rails相遇
经过几个月的JavaScript和CSS, 我们终于进入了Ruby on Rails后端。
Rails模式非常适合使项目保持简单, 因为MVC结构存在明显的分歧。如果你的系统开始增长, 仅使用Rails模式可能就不够了。相反, 你需要考虑解决问题的新的高级方法, 即新的抽象方法。
我们都研究了代码模式, 意识形态, 教程, 指南等。我们都知道将逻辑分解为类, 将类分解为函数, 等等。但是我们很少教解决方案。我从未读过有关它的书, 也从未看过有关它的课程。
与Rails合作一段时间后, 我开始发现问题不是代码, 问题是解决客户问题的解决方案。
返回到Ondello的WebRTC：作为一个具体示例, 我们在Rails之上构建了一个非常简单的邮件系统。一段时间以来, 这对我们来说效果很好。但是最终, 我们需要为每个客户提供一种特殊的电子邮件。随着时间的流逝, 电子邮件之间的变化越来越大, 最终, 每个客户都需要完全不同的电子邮件。
如果你的系统开始增长, 仅使用Rails模式可能就不够了。相反, 你需要考虑解决问题的新的高级方法, 即新的抽象方法。
我开始发现随着代码库的增长, 这种功能将对我的整个WebRTC框架和邮件系统产生巨大影响。那就是当我们决定为邮件系统创建一个单独的项目时, 负责处理所有类型的消息。主项目只是发送(通过REST)一些参数和一个客户端标识符。然后, 邮件系统将负责组装和发送电子邮件。
在开发Ondello时, 这种将项目分为不同项目的方法很有用。它使主要项目保持简单, 并且没有不必要的责任。
这种解决问题的方法就是我所说的解决方案。我发现这对于开发复杂的应用程序至关重要。
总结
无论你是Ruby, Java还是PHP开发人员, 在进行Web开发时, 都有如此众多的框架和技术, 可以使用或应该使用许多不同的工具来使系统正常工作, 在我的眼中, 很难将任何人视为” Ruby”程序员或” Java”程序员。
对于大型系统, 你需要设计精心设计的解决方案来满足客户的需求, 并且这些解决方案并不总是与你喜欢的技术甚至舒适的技术相匹配。我在Ondello的开发过程中遇到的共同主题是, 无论我的喜好如何, 我都必须在任何给定的时刻使用最适合的技术来灵活, 敏捷。
在开发Ondello时, 我记得最重要的是, 我们必须是工程师, 使用尽可能最好的工具解决问题, 并以有效, 可扩展和实用的方式完成工作。
评论前必须登录！
注册