如何评价构架好与坏

简介: 导读:原文作者Ryan写了一篇《Your Architecture Sucks and I Don’t Care》,他认为当你发现自己在重构代码时,请停一停,问问自己你的用户是否会因此受益?因为最终,这才是最重要的。

导读:原文作者Ryan写了一篇《Your Architecture Sucks and I Don’t Care》,他认为当你发现自己在重构代码时,请停一停,问问自己你的用户是否会因此受益?因为最终,这才是最重要的。现将译文《你的架构很烂,但我并不在意》转载,以下是文章内容:

嗨,你的应用的架构很完美吗?对呀,这就是为什么你还没有发布你的应用的原因,你仍然在彻夜不眠的担忧着各个功能模块之间的责任分离(你没时间去关心应用的流量和访问率)。

可是,除了我之外,谁还会对你说你的架构很烂?为什么我要关心你的架构?因为我只是你的用户,我不关心你的程序长的什么样、如何被调用的、用什么语言写成的。我关心的是它能用最简单的、最迅速的方式解决我的问题。

你的用户并不关心架构的问题,他们只关心你的应用是否好用。

我以前就是一个不理解这个道理的受害者。在Friendly Dingo之前的一个公司时,我痴迷于架构。我希望我的代码对于任何人来看都是最简洁的,我希望每个文件、dll、类都满足你们曾经听说过的任何编码标准。而且我做到了,很完美。但是我的产品却延后了发布,因为我要花更多的时间整理程序架构(顺便提一下,没有人知道我在做这个事情),然后我才处理客户的增加功能的请求。这最终的结果是一个中等产品评价和不好的销售情况。但是朋友们,我的程序是完美的。

到如今,在开发的第一周,我先架构选型,然后就搭建这个架构。当产品的首次发布日期快要到时,我已经很有信心,不再关心架构,尽管在某些方面还不尽如人意,因为我知道:程序的功能才是我做的所有工作中用户真正想要和关心的。架构能够满足应用的需要即可。

所以,下次当你发现自己在重构代码时,请停一停,问问自己你的用户是否会因此受益?因为最终,这才是最重要的。

译文链接:http://www.aqee.net/2011/01/19/your-architecture-sucks-and-i-dont-care/

原文链接:http://friendlydingo.com/blog/2011/your-architecture-sucks-and-i-dont-care

目录
相关文章
|
30天前
|
存储 数据可视化 数据库
团队文档管理有困难?总有一款工具合适你
本文介绍了团队文档管理的重要性及其在提升工作效率、保障协同作业和知识传承中的关键作用。随后,详细评述了六款广受好评的团队文档管理工具:板栗看板、Notion、Confluence、Quip、Google Workspace 和 Microsoft 365,分别从功能类型、发展历程、价格费用、产品特色、优缺点、适用场景及应用案例等方面进行了对比分析,旨在帮助读者根据自身需求选择最合适的工具。
团队文档管理有困难?总有一款工具合适你
|
6月前
|
编解码 安全 定位技术
典型崩溃问题集锦
典型崩溃问题集锦
50 0
|
设计模式 测试技术
重构·改善既有代码的设计.02之代码的“坏味道”
之前在《重构·改善既有代码的设计.01》中初步了解了重构的基本前提,基础原则等入门知识。今天我们继续第二更......
207 1
重构·改善既有代码的设计.02之代码的“坏味道”
|
Unix Java Linux
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/846d5052-1e21-4f9c-8f52-aaa37cacc407.png) # 前言 一群高智商青年在餐厅吃饭,餐桌上一个瓶盖标识为盐的瓶子里装得是胡椒粉,而标识为胡椒粉的瓶子里装得却是盐,他们想出了一个充满才气的方案来完成对调--仅需要一张餐巾纸、一根吸管和两个
48653 10
系统的混乱并业务本身之复杂,我们并不擅长处理『简单』
|
Unix Java Linux
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
软件工程最大的成本在于维护,为了未来可扩展、为了未来更灵活,我们往往会增加很多很多奇奇怪怪可有可无的代码,增加这些代码可能只需要几分钟,但移除这些代码花费的精力与承担的风险,却数倍于此。我们不断 YY 着所谓的未来,却让现在越来越糟。系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』。
1176 1
系统的混乱并非业务本身之复杂,我们并不擅长处理『简单』
「管理」处理复杂性-一个粗略的指南,领导模式和理论
「管理」处理复杂性-一个粗略的指南,领导模式和理论
|
程序员 测试技术
等重构完这系统,我就提离职!
Part.1 为什么程序员一言不合就重构代码? 当你看到前任写成一团毛球的代码块;新增几行代码需先捋半天逻辑的超级大函数;好不容易在迷宫里找到方向,小心翼翼地添加上新代码,却将别的调用系统给弄垮时;还有运行缓慢的老系统…… 此时程序员只有两个选择:要么忍,要么重构。
1566 0
12.系统可靠性分析与设计
脑图如下所示:
1363 0
|
UED
[译] 设计准则:如何说服用户去使用新的功能
本文讲的是[译] 设计准则:如何说服用户去使用新的功能,去年,在我们发布了即时消息之后,我们又添加了一个功能,用户可以创建丰富的个人信息,这样用户就可以知道,在另一端和他们交流的是一个真实的人。
1183 0
|
Web App开发
《伟大的小细节:互联网产品设计中的微创新思维》——2.3 预期操作权衡
本节书摘来自华章计算机《伟大的小细节:互联网产品设计中的微创新思维》一书中的第2章,第2.3节,作者:文哲著, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1233 0
下一篇
无影云桌面