MyException - 我的异常网
当前位置:我的异常网» 综合 » 技术决议计划的相对性

技术决议计划的相对性

www.MyException.Cn  网友分享于:2013-09-19  浏览:0次
技术决策的相对性

我想,作为一名程序员或技术人,总会碰到这样的场景 —— 在一些技术评审会上,和其他技术人产生关于技术决策的争论。大家争论的出发点是什么?而解决争论的原则又是什么?

绝对

曾几何时,我以为技术是客观的、有绝对正确与否的标准判断。

曾经,我刚开始学习编程技术时,捧着一本经典的数据库教材,它在述说着经典的关系数据库表设计原则:第一、第二、第三范式。后来,我参加工作,那时的企业应用软件系统几乎都围绕数据库核心构建,严格遵守范式定义的表结构。所以,当时觉得所有不符合范式设计的应用肯定都是错的,直到后来进入大规模的分布式领域,碰到了反范式设计。

在更早的时候,还在学校,一起学习的同学总跟我讨论设计模式。一边写代码,一边研究这个代码到底符不符合某种模式,似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿,似乎带有某种天生的错误。直到后来,我碰到了反模式设计。

刚工作不久,同事和我讨论当用户删除自己的数据时,我们到底应不应该删掉它。我觉得理所应当写个 Delete 的 SQL 语句把它删掉。既然用户都不要他的数据了,我们还把它保留下来做什么呢,不是浪费资源嘛(那时服务器存储资源还算挺贵的)。但今天的互联网,用户主动或非主动提交的任何数据,你都别想再将它真正的删除了。在这个大数据时代,所有关于用户的数据总是可能有用的,先存下来再说。

关于技术决策的判断标准,曾经以为的绝对,今天再看都是相对的。

相对

是的,适合的技术决策总是在相对的条件下做出的。

最近,读到一篇英文文章,标题翻译过来是《简化:把代码移到数据库函数中》。我一看到这个题目就觉得这是一个错误的技术决策思路,为什么呢?因为曾经我花了好长时间做了一个项目,就是把埋在数据库存储过程中的代码迁移到 Java 应用里。而且,现在不依赖数据库的代码逻辑不正大行其道么?

我很好奇作者是在正话反说,还是在哗众取宠?所以,我就把这篇文章仔细读了一遍,读完以后我发现作者说得似乎好有道理,他的说法我大概简述下。

作者说,如今绝大部分的 Web 应用包括两部分:

  • 一个核心数据库,负责存储数据
  • 以及围绕数据库的负责所有业务智能与逻辑的代码,体现为具体编程语言的类或函数

现在几乎所有的 Web 系统都是如此设计的,所以这像是真理,业界最佳实践,事实工业标准,对吧?但作者描述了他自己的经历,是这样的。

他从 1997 年开始做了一个电子商务网站,用了 PostgreSQL 作为数据库,第一版网站用 Perl 写的。1998 年换成了 PHP,2004 年又用 Rails 重写了一遍。但到 2009 又换回了 PHP,2012 年把客户端逻辑拆出去用 JavaScript 重写了,实现了前后端分离。

这么些年下来,代码重构过很多次,但数据库一直是 PostgreSQL。而大量和数据存取有关的逻辑也随着代码语言的变迁而反复重写了很多遍。因而,作者感叹如果把这些与数据存取有关的逻辑放在数据库里,那么相关的代码将不复存在,他也不需要反复重写。

这里有个疑问,作者没事老在换语言折腾啥?作者虽然没有在文中明说,但作为程序员的我还是能设身处地的感受到其中的缘由。作者本身是学音乐出身,目标是建网站卖音乐唱片,自学编程只是手段。作为一个过来人,我相信他早期的代码写得肯定不咋地,又在各种流行 Web 技术趋势的引诱下,充满好奇心地尝试各种当时时髦的技术,不断重构改进自己的代码。在这个过程中发现,有一些和业务关系不太大的数据存取逻辑,被反复重写了很多遍,所以才产生出了这样的思路。

假如把这部分代码移到数据库中,对这个思路的挑战,也是显而易见的:

  • 如何进行调试、回滚?
  • 如何做单元测试?
  • 如何进行水平扩展?

上述理由在正常情况下都成立,但对于作者来说却不是很重要。因为作者思路成立的前提是,第一,他维护的是一个小网站,数据库没有成为瓶颈。第二,这个网站的开发只有作者一个人,而不是一个团队。

是的,围绕这个网站作者创办了一家公司,雇佣了 85 名员工,成为了公司的 CEO 也是唯一的程序员。因此,这就是一个相对限定条件下的技术决策,看上去明显得不对,但在作者的限定条件下,它省了他个人的事,但扩展有明显的极限,网站也不会发展太大。

这就是一个相对技术决策的案例,明显非主流,但它能适应作者面临的现实,这背后会有通用的选择判断标准吗?

原则

既然技术没有客观与绝对的标准,那么技术争论的出发点以及解决争论的原则该是什么?

在近期的一次项目技术评审会上,后端的同学和前端的同学又就一些技术决策产生了争论。而争论的问题无所谓对错与否,因为同样的问题既可以后端解决,也可以前端解决。那么争论什么呢?无非是各自基于局部利益的出发点,让自己这方更省事。

某些问题的解决方案处在技术的临界地带就容易产生这样的争论。而技术的临界区,有时就是一些无法用技术本身的合理性来做判断的区域。那么解决的办法和基于的原则是什么?我得到的答案是,在这个具体案例中就是把前后端整体考虑,以成本和效率为核心来度量,应该由哪方来负责这个临界区。而考虑成本与效率的因素又包括:

  • 团队:人的因素,不同团队的水平、掌握的技术、积累的经验不同
  • 环境:能直接利用的环境支持、公司内部的平台甚至外部的开源软件
  • 约束:管理权力的干涉、预定死的产品发布日期等等

不同的人,同样的技术方案,成本效率不同;不同环境,同样的技术方案,成本效率也不同;不同的约束,同样的技术方案,还不仅仅是成本效率的问题,可行性也是一个问题。

...

适合的技术决策,总是在受限的约束条件下,围绕成本与效率做出的权衡。而对于一些纯粹的技术理想主义者,追求技术的完美与合理性,初心本不错,但也许现实需要更多的行动柔性。


写点文字,画点画儿,记录成长瞬间。
微信公众号「瞬息之间」,既然遇见,不如一起成长。

文章评论

2013年美国开发者薪资调查报告
2013年美国开发者薪资调查报告
做程序猿的老婆应该注意的一些事情
做程序猿的老婆应该注意的一些事情
要嫁就嫁程序猿—钱多话少死的早
要嫁就嫁程序猿—钱多话少死的早
老美怎么看待阿里赴美上市
老美怎么看待阿里赴美上市
程序员必看的十大电影
程序员必看的十大电影
程序员的一天:一寸光阴一寸金
程序员的一天:一寸光阴一寸金
60个开发者不容错过的免费资源库
60个开发者不容错过的免费资源库
如何区分一个程序员是“老手“还是“新手“?
如何区分一个程序员是“老手“还是“新手“?
我是如何打败拖延症的
我是如何打败拖延症的
程序员都该阅读的书
程序员都该阅读的书
程序猿的崛起——Growth Hacker
程序猿的崛起——Growth Hacker
写给自己也写给你 自己到底该何去何从
写给自己也写给你 自己到底该何去何从
一个程序员的时间管理
一个程序员的时间管理
“懒”出效率是程序员的美德
“懒”出效率是程序员的美德
那些性感的让人尖叫的程序员
那些性感的让人尖叫的程序员
科技史上最臭名昭著的13大罪犯
科技史上最臭名昭著的13大罪犯
每天工作4小时的程序员
每天工作4小时的程序员
编程语言是女人
编程语言是女人
10个调试和排错的小建议
10个调试和排错的小建议
 程序员的样子
程序员的样子
Google伦敦新总部 犹如星级庄园
Google伦敦新总部 犹如星级庄园
代码女神横空出世
代码女神横空出世
Java程序员必看电影
Java程序员必看电影
5款最佳正则表达式编辑调试器
5款最佳正则表达式编辑调试器
不懂技术不要对懂技术的人说这很容易实现
不懂技术不要对懂技术的人说这很容易实现
程序员周末都喜欢做什么?
程序员周末都喜欢做什么?
中美印日四国程序员比较
中美印日四国程序员比较
十大编程算法助程序员走上高手之路
十大编程算法助程序员走上高手之路
Web开发者需具备的8个好习惯
Web开发者需具备的8个好习惯
为什么程序员都是夜猫子
为什么程序员都是夜猫子
我的丈夫是个程序员
我的丈夫是个程序员
程序员应该关注的一些事儿
程序员应该关注的一些事儿
什么才是优秀的用户界面设计
什么才是优秀的用户界面设计
10个帮程序员减压放松的网站
10个帮程序员减压放松的网站
亲爱的项目经理,我恨你
亲爱的项目经理,我恨你
Java 与 .NET 的平台发展之争
Java 与 .NET 的平台发展之争
2013年中国软件开发者薪资调查报告
2013年中国软件开发者薪资调查报告
程序员和编码员之间的区别
程序员和编码员之间的区别
那些争议最大的编程观点
那些争议最大的编程观点
看13位CEO、创始人和高管如何提高工作效率
看13位CEO、创始人和高管如何提高工作效率
“肮脏的”IT工作排行榜
“肮脏的”IT工作排行榜
团队中“技术大拿”并非越多越好
团队中“技术大拿”并非越多越好
鲜为人知的编程真相
鲜为人知的编程真相
为啥Android手机总会越用越慢?
为啥Android手机总会越用越慢?
我跳槽是因为他们的显示器更大
我跳槽是因为他们的显示器更大
如何成为一名黑客
如何成为一名黑客
程序员眼里IE浏览器是什么样的
程序员眼里IE浏览器是什么样的
聊聊HTTPS和SSL/TLS协议
聊聊HTTPS和SSL/TLS协议
程序员的鄙视链
程序员的鄙视链
软件开发程序错误异常ExceptionCopyright © 2009-2015 MyException 版权所有