建立一个Sitecore网站是相当容易的-有时甚至可能太容易了。当新的Sitecore开发人员遵循为期三天的Sitecore开发人员培训模块后，他们将在从头开始构建他们的第一个Sitecore解决方案方面走得很远。开发速度对经验丰富的开发人员和团队更适用。根据我作为开发人员和技术架构师的经验，云服务平台，我和我的团队在很短的时间内就完成了解决方案的大部分功能，这让许多产品所有者和客户大吃一惊。但是作为一个开发人员和技术架构师，你应该意识到，当你迈出第一步时，你手中握有巨大的力量。从长远来看，你甚至可以宣称你有能力为项目立项或破案™ 拥有巨大的市场潜力，物联网和互联网的区别，但没有一个客户在第一时间就将整个平台部署到了极致。因此，只要解决方案的架构和构建考虑到可扩展性和灵活性，就有理由进行长期的实现过程。另一方面，如果最初的解决方案和架构无法应对挑战，它就有能力阻止其发展，扼杀营销利用平台的力量。灵活性、可扩展性和简单性因此，大数据行业分析，无论您是开发人员还是技术架构师，在将站点架构和解决方案组合在一起时，从长远来看，您的主要关注点之一应该是可维护性和灵活性。随着时间的推移，保持对过程的持续警觉将使你比继续以最明显和最快的方式从a到B的效率更高。长期生产力是我们需要惯例、实践和架构原则的原因。但采用哪种原则、惯例和惯例在很大程度上取决于商业案例以及你的内部组织，因为很多因素，例如技能和成熟度，在这个过程中起着至关重要的作用。因此，定义惯例或找到正确的原则和实践是不可能发生的，其中一个诀窍就是要时刻警惕自己在做什么，什么是返利，怎么做，最重要的是，为什么要这样做。但请记住，无论听起来多么无聊和烦人：惯例、模式和实践都是为了优化企业的投资回报。扪心自问：为什么？在整个开发过程中，当您考虑技术决策时，甚至对于您正在编写的每一行代码，您都应该不断地质疑自己、体系结构和过程。例如，你可以边走边问自己这些问题："这东西属于这里吗？"为什么要把这行代码放在这个方法里，这个方法放在这个类里，这个模板放在那个文件夹里，等等。？是否有一个你没有遵循的基本惯例，或者你是因为正确的方法可能花费太长时间而临时做出决定？干净的体系结构和惯例通常会因为草率而迅速的决定或小的缺陷而开始崩溃。毕竟，如果你的团队成员走的是简单的路线，为什么你不能？正确的架构失败的另一个原因是，用正确的方式去做太难或太慢，而且由于似乎是直接的生产力原因，我们开始以错误的方式做事。因此，你的问题应该是：有没有一个我们可以改变的过程，或者一个我们可以引入的工具来加速事情的发展并使之变得更简单？毕竟，仅仅因为惯例和惯例是为了优化业务而制定的，但这并不意味着它们不应该很容易遵循或很有趣，对吧？"我们为什么要这样做？"需要理解惯例才能遵守。举个例子ASP.NETMVC公司。这些约定很容易理解和遵循，因为它们是建立在简单的命名原则之上的，并且如果您遵循这些原则，它们还具有优化开发的工具。但有时我们发现自己无缘无故地遵循惯例。也许是因为他们是被权威人士教给我们的，在训练中，等等。？或者也许我们太专注于手头的工作，以至于停下来问自己为什么要有这些约定。例如，Sitecore的许多常见做法，例如：将"公用/文件夹"模板用于远程类似文件夹的所有内容。从一个通用的基本模板派生所有模板。将webforms渲染放在磁盘上的layouts文件夹中。在网站根目录外工作。……可以而且应该根据您的解决方案和您所在的组织重新考虑。这些实践对你和公司有什么影响？还有更好的方法吗？换言之：如果你不能回答"为什么"，那就问问你的团队，如果你仍然没有答案，那就考虑改变我们能做得更好吗？"毫无疑问，确保您和您的团队成员以正确的方式构建解决方案的最佳和最有效的方法是所有人都同意这确实是正确的方法。如果一个过程或架构决策没有明显的原因，大数据发展前景，或者您绝对确定您知道原因，但您不同意并认为您可以改进它，那么您有义务提出为什么应该更改以及如何使其更好。但要时刻记住：不要从技术或个人角度来争论，而要始终站在商业的角度。从长远来看，这会使解决方案更好吗？这种改变会节省时间或资源吗？听着，准备好输掉争论。尽管您是一个聪明的开发人员或架构师，并且您知道自己在做什么，但您可能不知道决策背后的所有业务推理。最重要的是：不要以自己的方式做事。从长远来看，一套统一的实践总是比一套分散的、不断增长的实践更好。总而言之，采纳和调整有利于最佳实践，从更大的角度看，你选择遵循哪种精确的惯例和实践并不重要。重要的是你要想清楚为什么你有这些惯例，每个人都知道和理解为什么，而且很容易遵循它们。您选择采用的任何实践都只能是一种推荐的实践，只有当您将它们与您的业务需求保持一致并将其作为您自己的需求时，它们才真正成为最佳实践。要进一步阅读和例行公事，请访问人居项目网站或我们在github上的工作。