Joh*_*lph 44 architecture infrastructure
我最近发现自己处理了一个(内部)应用程序,我已经写给我公司喜欢雇用的两个候选人,以协助维护和添加次要功能.
这是我写的第一个"生产"应用程序,它有45k LOC,我花了将近两年的"独奏"开发.我还很年轻(18岁),从头开始编写应用程序,同时签约作为离开公司的前开发人员的替身.我没有经验设计这种大小的应用程序,我试图使用常见的架构和设计模式.
今天我知道我已经做了一些严肃的过度工程,例如使用断开连接的变更跟踪架构而不是所选ORM已经实现的工作单元模式.我可能永远不会去"真正的"三层.
两位候选人都有10年以上的内部应用程序开发背景和相关平台.作为他们年龄的一半,没有经验,我尊重他们的意见.当我向他们解释应用程序架构时,评论是这样的:
现在我问自己:
我是建筑宇航员吗？我怎么知道我在建筑方面走得太远了？过度工程的常见症状有哪些？
Jef*_*nal 120
过度工程的常见症状有哪些？
解决您没有的问题的代码.
dsi*_*cha 25
过度工程化的一个非常强烈的警示标志是当所有事情都经历了如此多的间接时,很难找到实际实现某些具体的域级功能的代码片段.如果您发现大部分功能都做了很少的具体工作而只是调用其他虚拟功能,那么您可能会遇到问题.
Jul*_*iet 18
无聊
无聊是过度设计代码的良好前奏.我承认,当我得到第一份工作时,我觉得这种情况未得到充分利用.我很无聊.当我感到无聊时,我写了代码.不只是任何代码 - CATHEDRALS OF CODE.
没有认真的,我有一个关于我的代码和抽象的精神图片,像金色的突出尖顶的大塔,玻璃玛瑙的飞行扶壁,由拱形圆顶支撑着美丽的几何图案等的美妙拱顶等.
看到这些模式为我自己一起工作真是令人着迷,但回想起来,我对我留下的不敬虔的混乱感到十分羞愧.
如果您正在编写自己的框架和DSL代码,而不是在工作中减少刺激时间,那就停下来吧.阅读Wards Wiki或编写开源书籍的时间更长,或者您可能只想让管理层要求更多工作.
Nat*_*hes 11
至于你是否是一名建筑宇航员的问题:如果你意识到危险会让你领先于很多人.你也不想走牛犊的路,听起来有些人已经成了硬梆梆的老人.
过度工程是优先级问题的结果,导致系统的某些部分受到太多关注.因此,过度工程化最明显的症状是,您可以看到系统其他部分因缺乏关注而受到伤害.
(由于复杂性的增加以及在决定过度设计的哪些方面涉及的容易出错的推测的数量,过度工程化也会使系统暴露于设计不良的风险增加,但正如评论指出的那样,这不会自动跟随.)
Jul*_*iet 11
编写自己的框架
可能性,有人已经完成了它.更重要的是,他们已经做到了比以往任何时候都好1000倍.更重要的是,无论他们做了什么,可能已经是行业标准,因此学习这项技术将使您在其他工作中更具竞争力.
在我工作的最后一家公司,一名程序员在他的大部分任期内独立完成了他的项目.他写了一篇该公司更受欢迎的应用程序,并被广泛认为是团队中最好的 - 但在我看来,他有一种讨厌的习惯,他从头开始编写他需要的一切.
他写了自己的依赖注入框架,他自己的ORM,一个单元测试框架(莫名其妙地,看起来和行为非常类似于NUnit - 他为什么不使用NUnit？),一个用于创建工厂对象的框架(a " 工厂工厂 "我称之为).
请注意,代码实际上非常出色,但有什么意义呢？
写一个更好的核心库
在我现在的公司,程序员似乎总是编写无用的代码来复制已经存在于.NET框架中的功能.
除其他外,他们写道:
要么他们不太了解框架,要么他们认为这个框架非常不合适.
我只能想到很少的例子,重新实现的库比原来的更好(参见Jane Street核心库,C5 Generic Collections for .NET,一个真正的货币类),但可能性很大,你不会写一个更好的标准库.
Ken*_*Liu 10
对于大多数内部业务应用程序,大多数代码应关注实现业务问题,而不是与业务无关的技术问题(如"断开连接的更改跟踪体系结构").当前可用的框架非常成熟,支持最常见的用例.如果您正在发明新技术或(在业务应用程序开发的上下文中)只是为了包装而包装其他现有的框架或库,那么您可能做错了.理想情况下,您构建的每个体系结构都应该可追溯到某些业务需求.把事情简单化.
恕我直言,你得到的关于你的应用程序的大部分评论并不是真正的过度工程,因为过度工程不是关于技术.这是关于建筑.可以在合理的时间内学习和理解新技术.理解过度设计的应用程序通常要困难得多,有时甚至是不可能的.这使得第2,4和5点无效.第一点并不是真正有效,因为你显然因为编写应用程序而得到了报酬,如果它有效,你就没有问题了.
这是我的"快速测试",以找出是否一个应用程序往往是过度设计:
这些只是我用于我的应用程序的快速提示.它们不能保证是"过度工程检测"的全部和最终结果.
在研究过度设计的事物时,可以避免使用YAGNI,DRY和KISS.如果有许多部分似乎已部分完成,并且许多部分代码似乎都有,"如果发生这种情况怎么办？如果发生这种情况怎么办？" 感觉到,这将是另一个观点.忽略OO设计或SOLID原则的良好原则将是另一个需要注意的.如果你认为你已经编写了完美的代码,那将是另一个麻烦的迹象,因为任何人写一些无法以这种或那种方式改进的东西是极其罕见的.
IMO,请注意,有些人可能对您的工作过于批评,因为任何代码库的一部分都可能涉及人们喜欢某种方式,例如方法,测试和变量的命名约定.就是那样子.现在,您可能需要弄清楚的是如何处理人们的冲突或说服/影响等问题,因为有些工具可以提供帮助.
为您的应用提供内在功能的插件
让我们面对现实,可插拔架构只是该死的性感和写作的乐趣.然而,这是你需要问自己的另一个领域,"我真的需要这样做吗？".
如果您不需要对应用程序进行临时添加,请不要指望任何人编写第三方扩展,并且您的应用程序范围相当明确,您不需要可插拔的体系结构.
您不应该编写插件来支持应用程序中的内部功能.假设您正在编写一个Paint程序; 您可能支持以多种格式保存文件的插件,但您不需要可插入的撤消管理器或文件浏览对话框.
你不是宇航员的建筑师.LINQ非常简单,基本且有用..NET 3.5也是如此.
与此同时,你是团队中的新手,即使他们喜欢你所做的事,也会得到一些罗纹.
拿出一粒盐就可以了.接受他们的批评,点头,然后和他们一起喝啤酒.
如果他们要求你改变它,那么你的评论是"jeez ..我知道我做错了,但是它有效并且改变会很麻烦".