一个CEO的日记-软件瑜伽
在本系列前面的文章:
理解是关键
的客户机/服务器系统（即使没有显示的部分）的开发进展缓慢。虽然已初步建议的总体目标，大量的设计没有。相反，外包开发团队被交给没有整体的大图片非常具体的细分项目。在早些时候向他人沟通的大图片困难驱动的这种做法，但它造成的自身的问题。因为即使是最小的代码段创建，它会设计的"特色"，将限制它的实用性，在更大的整体。这是时间，以填补在整个设计的新家伙。沟通设计
任何建筑师所面临的问题之一是沟通设计的人，实际上做的工作。有几个方面的沟通，使建筑师的生活困难。深度与程序员的经验
随着软件的设计可以在高层次的抽象传达一路下滑的伪代码，勉强比实际执行较高的水平。虽然有很多良好的方法和指引，以促进这项工作的目标是优化一个程序员需要完成任务的信息量。在失败的信息太少，结果，太多的信息是矫枉过正。一名建筑师（尤其是一个公司，是推动架构的首席执行官）通常得到支付的"一掷千金"，使优化多少时间花费传递信息的一个项目的成本衡量影响。
然而，在这个成功是非常困难的，因为你必须平衡程序员的技能，您认为他们需要的信息的深度。这是努力不够用自己的员工做，甚至与他们合作多年后，特别是当他们已经成为舒适与现有的架构，工具，技术，和你是具有挑战性的工作，一个全新的，完全不同的架构，新工具和新技术。这是更难的一些工作已经外包给一个国家在世界的另一端。用有限的预算来开发原型的一个小公司，这种平衡是至关重要的。
权衡，当然，是比较有经验的程序员，希望能采取一个更高层次的设计和运行它，也更昂贵。因此，我们有一个三角形，在其中的某处有一个文件要求，编程技巧和编程成本的最佳点。
{S0}框外的思考
编程技巧实际上是一个可望而不可及的质量。显然，技术技能，可以很容易的确定。然而，还有许多难以确定的技能，思考从不同的角度有问题。抽象不容易
传达一个架构的常见问题之一是，程序员，即使是技术熟练，实现架构，是为了解决特定的问题域。往往是缺少一个架构的沟通，使抽象架构的设计模式。一个已纳入实施某种程度的抽象，将更加灵活时，原来的问题域的更改。在抽象的前期投资为自己支付十倍的执行需要，以适应新的或不同的要求。再不过，问题是:架构抽象是多少？架构是抽象的吗？有多少这样的抽象传达给程序员？
这些都是不容易回答的问题，如果更糟的是，为了回答这些问题，程序员需要一个完整的体系结构和详细的了解 - 一个catch - 22。微软的方法可以得到的方式
外包公司的骄傲，他们已获得规定的方式使用微软的工具和技能培训。任何形式的"条条框框"的架构蹭到"微软方式"，往往是灾难性的结果。常见的技术，如数据集，我们遇到了这个问题无数次，远程化，系列化等，不用担心性能，安全性和灵活性的应用项目。这是很难告诉别人，"OK，忘掉所有你学到如何做X"做"这样"，而不是。选择的权利人的权利的任务
外包，这可以推广到任何工作关系，最终都归结为了解你的工作人员，顾问和其他团队成员不够好，你可以正确的任务分配给正确的人。虽然记录的设计是很重要的，我们学到的东西之一是设计文件的需要，只有足够，所以，它适合的任务和人。
说起来容易做起来难
可悲的现实是，这很容易说，做起来难，这是明显的发展进步时，整个设计传达。随即，该项目开始转向场外。如果每一步的详细规格，外包团队作出的假设，需要百废待兴的第二天。语言似乎并不成为一个问题，团队的技能水平优秀。两个大问题时区（他们刚刚离开，我们来到办公室），并已与其他人经历了同样的问题:它的目的是，他们无法把握整个项目的范围。启动项目需要远见和技能
只有一个月到重新启动的项目，它开始看起来像一个不可能完成的任务。在这期间，继续搜索为工具，以帮助与接口负载。许多谷歌搜索（它不管你怎么问...）返回一个有趣的文章就没有链接，但没有一些设计决策的Avalon环境。从本质上讲，MyXaml没有包含读取XML。NET对象的定义和实例化这些对象。当然，这是一个巨大的简单化，但它看起来像它可能是一个有用的工具，可以。一个简短的电子邮件交谈，在此期间，马克被暴露的总体设想。
第二天，预定电话交谈。在这次谈话中，马克成为越来越多的有关总体规划的兴奋。它实际上是密切反映，他已经在他写的应用程序使用的许多技术，适合与MyXaml产品，他设计了它和它的"感觉正确"。在一个点上，他提到，这是方案被认为是设计的方式。用户界面是独立的，业务逻辑是脱离实际的数据库访问。他不是唯一的一个人很兴奋。在这第一个电话，很显然，马克不只是一种工具，我们可以使用的作者，他是我曾遇到的第一人究竟是谁立刻明白了高水平的设计！这是在应用程序的开发是一个转折点。这是，2004年9月29日。
马克提供了一些时间，他对该项目有兴趣，于是我们开始一起寻找装修的一切。原始的阶段，从一个小项目外包团队进行了检查，并设计了一个简单的演示，测试的概念。三天之内，是一个概念演示到位，与一些概念图纸。在纸上的东西，一个明确的格式，马克将作出努力的重大贡献之一。
在一个月之内，应用程序运行与声明的屏幕设计，自动生成的数据库访问，数据的容器和对象。在这样的速度，它看上去就像一切都将在今年年底完成。事实证明，一年的时间是正确的，但今年是错误的。在十月底，我们将一起为新项目"待办清单"。要解决的点的数量是如此广泛的，面对面的访问似乎是适当的的。即便如此...
11月的第二周的会议期间，很开眼界。长天充满了不断的设计，澄清，概念测试，"如果"确定底层平台的发展需要的地方。尽管马克理解高层体系结构，有实施上的困难，再次与处理正确的抽象和合适的班级结构，以支持建筑概念。虽然"演示"平台上运行，它是灵活的引擎，最初的设想。即使与它的局限性，该基地是正确的。问题之一是试图以验证整个系统之前写的基本功能。众多的系统测试（另一个马克的贡献），它是令人兴奋地看到所有的"灯变绿"，但反馈说，"这实际上是我们所需要的"失踪。
虽然继续在服务器上的工作，外包团队被赋予了"增强"一套组件，以支持新平台的一些额外要求的任务。在此期间，目视确认完成MyXaml屏幕定义内置了一些逻辑第一个"哇"的经验
一旦前几个组件，建成新画面（在XML的手工编码）测试的概念。一个屏幕说:"人"的表，和其他使用一个组合框（数据驱动），从那些人的选择。第一个"哦，哇！"的时刻到来了，当一个表单被打开组合框，那么另一种形式（这些都是非模态，记不清了）开幕的"人添加"的能力。当新的人加入，他们发现立即在组合框中可用的数据。不仅这样做一个单一的客户端模式对话框的工作，而是一个单独的机器上启动第二个客户端，确切同样的过程也更新了其他客户端，自动。
下图说明了什么事情要做到这一点的代码，并且，此图掩盖了一些细节将在未来建筑的文章讨论。
{S2}
所有这一切都已经完成的声明编码，抽象和通用数据管理，最重要的任务，没有专门的代码写入客户端或服务器上。数据交易，持久性存储，和高速缓存交易/更新过程的所有常用功能，独立的特定客户端的形式和数据库架构。会有更多这样的时刻，但是这是第一个简单的验证，"这东西真的作品"！灵活的软件？？瑜伽为程序员保持重点
这种类型的发展的一个持续的挑战是保持长远目标的重点。创建可重用的代码是多么困难，大多数程序员都知道。目前的趋势是"代码的时刻"，创建每个新的功能，以满足已提出的具体要求。隐藏显示特定功能的测试环境带来了那些旧习惯。即使当我们使用"服务器端业务规则"，他们的编码方式是非常刚性的，有时是紧密联系在一起的客户端控件。有必要做一些以测试平台的其他部分。主要目标是渗透的核心逻辑，以防止这种做法。保持强劲
即使在设计时非常通用的功能，如"缓存文件同步"的初步做法是添加逻辑命令包中的文件同步数据。作为特殊类型的表在客户端缓存文件本身实施。后来，由于添加非缓存表更新，它变得越来越明显，只是缓存表更新了同样的规定的特殊情况。整个系统可以更健壮，利用两地的确切相同的逻辑。这也使该系统的单元测试更简单。调息
多达任何一个软件项目，重构是怎么回事不断。队看到不断改善的一个领域是"只是把它做"的方式减少。发现随着每个新的要求，有意识地退后一步，认为一个通用的功能，可在其他领域的有用。同时，我们看到在已经实施的逻辑，以确定是否可能与现有的逻辑，使整个系统更加灵活的合并的新功能。保持灵活
最困难的部分是设计一个通用的业务平台，以确保的要求绝大多数都支持和易于使用的。在一定范围内，这也是很重要的，让更多的灵活性，以支持的标准框架之外的独特需求。作为后端平台。NET的使用，这意味着该服务器可以做几乎任何事情。
为了支持真正的跨平台和基于Web的客户无需为每个环境的定制，有必要建立一个客户端功能的基线。任何客户端，支持所有功能，是一个"兼容的客户端"。从MyXaml使用的技术，它也可以添加额外的功能（新的组件，业务逻辑等）给客户端。依赖，扩展客户端功能上的任何应用程序，将是一个"不符合规定的的"应用程序。背后的UltraTier发展目标是确保绝大多数应用可以兼容的框架内实施。家里舒展
与所有的困难，发展是出发和结束已经在望。即使已经看到了系统的怀疑论者留下了深刻的印象，它可以做什么。作为开发人员，我们永远不会满足。更换较新的软件已经在过去我的企业标志之一。已被讨论的UltraTier V2.0的愿景！迄今这些文章大多是非技术。这是它的意图，打好后面的决定，推动UltraTiers设计的背景。将有更多的文章，介绍一些这些方法背后的细节。马克克利夫顿将主要接手这一任务。
