2010年11月8日星期一

小公司的架构选择

    很多大公司都是从小公司起步的,往大做的时候,往往会受到很多制约因素。架构选择不对造成的问题很多,所以很多小公司都在架构选择上精打细算。其实架构问题,在公司规模小的时候,更大程度上是一个行政问题而不是一个技术问题。
    小公司的特点是人少,往往就那么几个人。这种情况下,与其说是你选架构,不如说你看看有什么可用的架构。通常来说,你要考虑的问题是。
    1.你有没有可以信任的核心工程师?
    2.能不能找到足够的人手做大部分的事情?
    3.能不能在你要求的时间范围内把事情做掉?
    4.这个架构有没有成功的例子,能不能支持大规模的访问?
    当这些问题都没问题的时候,你才应该考虑,这个架构性能够高么?容易扩展么?
    如果你没有可信的人作为核心工程师,项目管理和控制根本无法进行。就算要评估一下手下这些人是不是真的需要这些时间来做事,得到的结果都是不可靠和不可信的。如果找不到足够的人手做事,那除非你的核心团队能够一个人或者几个人把网站整个做出来,例如豆瓣的阿北,否则项目做做就没人,就玩不下去了。如果架构很好,但是无法在要求的时间内做出事情来,等于没用。满足了上述几点,你还得兼顾考虑一下,这个架构如果没有成功案例,是否存在隐性的风险。如果不支持大规模访问,将来的扩展问题。
    好吧,作为一家小公司,我相信你考虑完以上几点后,能凑出一个框架来已经很不错了。往往是你的核心团队没有一个核心工程师,大家会几种不同的架构,而且没人能保证评估结果。
    这时候,不要废话,先找个核心工程师,然后用最土的,被无数人验证过的技术来把你想做的事情做掉。
    除非你的核心团队有且仅有一个核心工程师,并且这个工程师的技术能力很强,管理者和投资人也支持他冒风险。否则大部分使用激进架构选择都会带来不良的结果,毕竟大部分公司都不是以开发框架和研发技术为最终目地的公司。

没有评论: