呃，没发现 @zxy 就是楼主，莫非是一卡通？谁家的业务？如果真是一卡通的话……

@zxy 哟？同行嘛，数字化校园几乎等于无穷尽擦屁股

想问楼主，既然是金融业务，跑什么数据库，对事务处理有什么样的要求？

@046569

“两者技术与规模都是类似的”

看谁便宜，如果价格也一样，那也没什么好说的了，看哪个牌子念起来上口吧。

问题是，真有这种“两者技术与规模都是类似的”的场景存在么？

@BigZ 冗余和容量扩充是不同的东西

@BigZ 规划是：3年后数据达到500TB，不过经费上第一年只能投入100TB，第二年200TB，第三年200TB。这样的场景，一次性配死500TB不是不可以，但是谁知道第四年是不是还会再加存储呢？每次加存储，如果都要重新把磁盘部分重新配一下，太恐怖了

@BigZ 低端存储，持续购入磁盘的场景，有了LVM这种可以动态调整分区大小的东西，还是很方便的。

@tioover 类库和技巧跟随语言和你使用的技术而变化。

以RoR举例子，一般可能用到的包括：
* 测试框架类库，比如 RSpec，不过RSpec也可以说是一个BDD测试框架
* 生成对象，或者Fake对象的类库，主要用来模拟一些不需要测试，但是又需要用到的第三方代码，比如FactoryGirl
* 看你是要测试 Web 还是 Desktop 亦或者是 Mobile 程序，针对UI也会有库，但这不仅仅限制于UI啦，Web UI里capybara是很不错的啦
* 周边还有很多可以减少测试中重复工作的工具，比如Guard之类的，各种统计测试覆盖率的Cover

TDD/BDD自己也是在摸索阶段，这不是什么了不得的技术，但确实可以解决问题

直接监控豆瓣特定电影的评分更新情况，通过一定的标准，洗掉可疑评分，或者将这部电影标识为评分异常，是不是对用户来说，更靠谱一些？

@stackpop 不是要打开或者import虚拟机，而是直接访问远程已经开机的Fusion虚拟机。我知道开远程workstation和vsphere上打开的虚拟机是没问题的

@manoon 既然是好事，应该持续做的吧

TDD不正是解决这个问题的么，保证你的测试代码覆盖率

建议你将这个网页翻译成英文看

@adamwen 文档也是在真正了解自己要做什么的基础上才能够产生。不然那叫学习笔记。

学生时代确实遇到过好Partner，半个ABC，两个愣头青接到项目，要搞一个环境项目中的RRDTool。接手的时候完全不知道怎么做，看了cacti的代码直接丧失信心。只不过老美钱多人傻，终究不忍放弃。我们两个人一起在Skype上大概圈好了需要学习的技术范围（这时候已经有点经验，技术和资料都知道求精求实用），分好了工。白天时候各自看自己需要管的部分，晚上回去再花差不多时间说给对方听。竟然一周不到的时间，把基本技术搞懂，而副产物是一大堆word，手绘图例的电子档。

之后，我很邪恶的拉了一个学弟，把我们凌乱不堪的“学习笔记”交给他“整理成文档”，这小子也很神奇，用了两天时间居然就搞好了，加上PHP基础比我好，3个人居然用了整整4周的时间，把这玩意给搞定。产品虽不漂亮，但是功能完整，文档也由ABC翻译成了英文，还另外找了美工设计好手册。最后每个人差不多拿了5000刀走人。

只可惜，这么畅快的合作，仅此一次，发生在即将毕业的寒假，至今也再没有重现过了。

@wog 实习当然很重要，尤其对非名校的学生，前提是，如果能去一家好公司的话，无论是对简历还是工作能力，比在学校待着“应该”会好不少。注意，我说的工作能力，而不是编程能力。编程、工作、竞赛，都是很不相同的东西。

楼主提到了学长，想必是应届生。校招的HR苦啊，成堆的简历，真要那种有写过靠谱项目，网上还能查到的，整组的人都会传着看。对着90%简历上项目经验为课程设计的应届生来说，谈设计模式没有意义——可能大部分人知道有设计模式这个东西，同时这部分人没听说过Proxy模式。

算法学校里都会教，现成的面试题一大堆。而对于冒泡排序面100个，50个人压根不会写的校招，再去谈设计模式，不更是给HR找憋屈么。而那些真正会对某个具体问题、具体技术死抠的招聘，一般都是急着找人填缺的小公司。

@isy tags字段的冗余，对减少join次数，提升查询速度来说，在大数据量的时候，意义很大。这样做唯一的问题是，如果有奇葩需求希望修改tagName，需要逐个去修改对应topic tags冗余字段的内容。不过完全可以延迟慢慢去做。

对于生手来说，什么架构啊，谈架构等于玩死自己。

大家都没经验，自然也没有最佳实践可言，硬套 OOP，设计模式，活出不来还会给团队带来挫败感，最终严重拖慢进度。

自己也是这么过来的，记得自己真正意义上的第一个团队项目，是4个人，都是学生，1个美工，3个程序员，没有前端并且在程序刚开始做的时候，只有我略懂 HTML/CSS/JS。

很巧，这个项目也是个CSS，并且，因为某些原因，必须从头写起，不能用现成的代码改。项目期只有1个月，大家一周能聚在一起的时间，只有周末。一周下来，真正开发的时间，摊到每个程序员头上，最多10个小时。

美工很早就把设计图出来了，没人懂切图，于是纠结在切图究竟是美工学好呢，还是程序员学好呢。最终是我拉了一个“高手”，把图切了，按照切的图，我带着另一个程序员，硬着头皮把前端做完了。此时，逻辑代码数量为0。时间已经是第二周中了。

美工看没什么事情，就一个人去1000多公里外，见从来没见过的网友妹子了，据说，要去一周。

数据库的表，在项目开始之前，我就建好了，此时翻出来对着前端功能看，很多不能自圆其说。自己觉得应该讨论一下，于是第二周剩下的时间，就花在表结构上。事实证明，“更加完善”的表结构，引入了很多没有必要的“扩展性”。

第三周中，终于进入代码编写阶段。项目用的ASP.NET，当时版本2.0，所谓的架构不过是一个微软MVP写的一套三层架构的系列文档，纯英文。后来回想，这个文档很有Magic Demo的感觉——告诉你，ASP.NET+ADO.NET是个多么帅的框架，OOP，设计模式在双A框架里，是多么容易融合。

真做起来就完全不一样了，首先是怎么分工，3个程序员，我和A略强，B略弱，任务平均分给3个人自己回去写。到了第三周周末的时候合代码。

问题就来了。

虽然说事前约定好了代码规范，但是花括号到底是跟在签名后面呢还是重起一行没说过，a, b, c这种变量名虽然说了不要用，但是1个函数下来，到处都是ret strA, intB也不行啊。数据库的外键关系改了又改总发现还是不能随心所欲的删改数据，干脆就不要用外键了吧。又总觉得几个表功能差不多，是不是要继承一下？学习了什么叫做单表继承，多表继承。拿回来发现ADO.NET没法这么玩。Google了一圈，发现ADO.NET其实是可以这么玩的，只不过你要实现N个接口，M个抽象类，还得在程序初始化的时候做1，2，3，4，5件事情。三层架构，处在中间的业务逻辑层，似乎完全没用处。

所有的所有，折腾到交工的1个月的最后一天，手写代码虽有近3000行，网站可用性依然是0。

最惨的是，我自己发现，“标准” HTML/CSS/JS，套到ASP.NET上，几乎是没法用的，因为奇葩的ASP.NET，居然会在运行时，动态改变前端元素的ID。如果要用微软推荐的套用设计的方案，又要新学一大堆东西。

在第六周快结束的时候，3个程序员都泄气了，没人觉得再给1个月的时间，这网站可以完工。美工同学见光死回来了1个多月没见人，我们也不好意思去找他。很多前端要改的图，就让程序不是很强的程序员C代劳了。我美其名曰研究架构，没有1秒钟不想把整个程序推翻了重新来一遍。B也迷茫了，虽然陆续完成了用户、权限、发文的功能，但是怎么都觉得不对味道。

然后就没有然后了，一共花了2个月时间的代码，最终烂在我电脑里一直到现在。项目最后用Wordpress交工，当时说坚决不能用现成代码的甲方，什么也没说。

--------------------------------------------------------------------------------------------------------------------------

直到今天，如果让我问自己怎么做程序架构设计，我想只有1个答案，在你完成了解自己要做什么，对要做的东西，至少每个部分实现过2次以上，再去谈架构，谈优化。未知项目，探索性要求高的项目，只谈实现。

@gonbo 仔细看了下，机型很有限，价格似乎和超微比也没什么特别优势。uBuntu 的优化，像 @nodtoung 所说，DELL 还多些，经过uBuntu认证支持的服务器品牌，品种最多的，还是DELL