惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog RSS Feed
博客园_首页
N
News | PayPal Newsroom
有赞技术团队
有赞技术团队
The Hacker News
The Hacker News
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
The Cloudflare Blog
S
SegmentFault 最新的问题
Jina AI
Jina AI
人人都是产品经理
人人都是产品经理
P
Privacy & Cybersecurity Law Blog
AI
AI
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Schneier on Security
Schneier on Security
博客园 - 三生石上(FineUI控件)
月光博客
月光博客
量子位
Forbes - Security
Forbes - Security
爱范儿
爱范儿
云风的 BLOG
云风的 BLOG
SecWiki News
SecWiki News
Last Week in AI
Last Week in AI
酷 壳 – CoolShell
酷 壳 – CoolShell
T
Tor Project blog
Recorded Future
Recorded Future
A
About on SuperTechFans
J
Java Code Geeks
The Register - Security
The Register - Security
PCI Perspectives
PCI Perspectives
H
Hacker News: Front Page
V2EX - 技术
V2EX - 技术
S
Secure Thoughts
V
Vulnerabilities – Threatpost
Hacker News: Ask HN
Hacker News: Ask HN
MongoDB | Blog
MongoDB | Blog
N
Netflix TechBlog - Medium
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Scott Helme
Scott Helme
T
The Exploit Database - CXSecurity.com
Y
Y Combinator Blog
AWS News Blog
AWS News Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
IT之家
IT之家
T
The Blog of Author Tim Ferriss
G
Google Developers Blog
C
CERT Recently Published Vulnerability Notes
L
LangChain Blog
F
Full Disclosure
Application and Cybersecurity Blog
Application and Cybersecurity Blog
The GitHub Blog
The GitHub Blog

博客园 - 李学斌

写单元测试,我不认为是件容易的事 服务治理咋这么难?我想得换个治法了。 百度大会见解 李学斌:论复杂系统中的应用间协作V3 maven spring profile 协同 大视角、大方向、大问题、大架构:(结局)解决问题的出发点 大视角、大方向、大问题、大架构:(二)应用的相关问题 大视角、大方向、大问题、大架构:(一)信息时代下的管理 信息时代下,如何看待技术与理论 狼的架构暗示 狼群的架构暗示 基因与架构 由“I”到“T” 我们是在开发产品还是项目? 未来电子商务,未来的超市 创业期的软件开发管理(二) 创业期的软件开发管理(一) 平台架构--用户系统 平台架构——体系结构
产品的臃肿过程
李学斌 · 2012-03-08 · via 博客园 - 李学斌

当面对一个需求时,产品人员会在完成时间与资源投入上与研发人员进行“谈判”,有时要么威胁,要么悬赏。产品人员关注的是系统可以做这事,可以做那事(以后可以做);而研发人员则为了自身利益着想则是想先把这事做了再说,于是两者便很快达成协议。至少在这一刻,研发人员只能聚焦到一个点上,因为单纯做一件事简单,所以重实现轻设计的恶习被养成!我已经遇到好多已经快编完码才迫于形势(质量要求)来参加设计评审的事情了。

随着时间的推移,我们的产品便由这些大都是“临时”或“应急”的项目拼凑而成,于是我们的应用系统便越来越庞大而臃肿。庞大可以理解,但臃肿是我们无法接受的。臃肿发展到一定程度,会严重影响效率,制约着业务进一步发展。我们在不停的增加机器,不停的更换性能更高的服务器。然而这不是通用的解决方案,有时候我们对现有系统已经不能在做什么了,于是“架构升级”便被提到日程上来了。这是个自然规律,我们的业务系统也需要“进化”。然而就像生物界的“进化”一样,有些物种被替代了,而有些则变得更加强大。“替代”的代价是巨大的!这意味着先前的投入被历史所埋葬,遗留价值渺小甚至没有。

我不得不承认目前国内的一流的B2C公司就是以这样的方式支撑着如此巨大的业务,并且有的以每年200~300%的速度在发展。他们的业绩非常的漂亮,但有多少人知道多少研发人员度过了多少个不眠之夜?这些公司技术大都落后于业务半拍或一怕甚至是瓶颈问题!小一点的公司因为业务量的问题,可能没有那么严重,但其技术实力我是不那么乐观的。

这是不是说明我们的技术很被动的呢?技术服从于业务我很认可,但技术永远跟在业务后面跑我不认同!