随想之三，技术选型是怎么确定的
随想之三，技术选型是如何确定的？
这篇随想想了两日，还是不怎么该如何说，技术选型作为架构师的工作内容，如何强调都不过分。但是，技术选型的过程是怎样的，结论是如何得出的，总是好像雾里看花，却又是清晰分明。为什么有这种感觉？个人的感觉出于以下几个原因：
其一，熟悉。我脑海里第一个想法就是它。听过一个观点，COBOL(一种较为古老的语言)为什么被C替代，那是因为毕业生们都不熟悉COBOL，而熟悉C。熟悉既是技术选型的优势，也是劣势；这里的问题，就是手里拿着锤子的时候，看什么都像钉子。如果心里能够警惕这个问题，那么熟悉对于技术选型则是最有力的支撑。
其二，规范。选择它总没错的，既有面子，也有里子。OK，我就是这么干的。那么规范那么多，该如何选择呢。请参考上一条。
其三，已有实现的延续。那面享受现成的同时，也要小心地雷。
其四，选择常用的技术；也称之为成熟的技术。这个说法是有点问题的。例如，Spring + Hibernate，Linux+Apache+Php+Mysql等。
以上排序不分先后，仅是在我的意识里面出现的次序；也许最影响技术选型的恰恰是常用技术或者框架。对技术选型得到的技术组合的反思，能够最真实的反馈选择过程的心理。这里非常隆重的强调，技术选型一定是选择了一组技术的组合。如果技术选型得到的单一技术，那么请忽略技术选型，继续项目开发吧。
那么应该从什么角度比较各项技术的优劣，从而选择合适的技术组合。我想到了以下几个方面：系统解耦而分成的子系统接口、部署方案、性能扩容方案、可用性部署方案、项目组的技术储备等。当然还有更细致的项目，计算各技术方案在每一项上的得分，得分较高的就是优先选择的技术；可以先选择得到较高的几个技术，然后研究其在未得分项目上的补充方案；最后确定合适的技术组合。
这篇随想想了两日，还是不怎么该如何说，技术选型作为架构师的工作内容，如何强调都不过分。但是，技术选型的过程是怎样的，结论是如何得出的，总是好像雾里看花，却又是清晰分明。为什么有这种感觉？个人的感觉出于以下几个原因：
其一，熟悉。我脑海里第一个想法就是它。听过一个观点，COBOL(一种较为古老的语言)为什么被C替代，那是因为毕业生们都不熟悉COBOL，而熟悉C。熟悉既是技术选型的优势，也是劣势；这里的问题，就是手里拿着锤子的时候，看什么都像钉子。如果心里能够警惕这个问题，那么熟悉对于技术选型则是最有力的支撑。
其二，规范。选择它总没错的，既有面子，也有里子。OK，我就是这么干的。那么规范那么多，该如何选择呢。请参考上一条。
其三，已有实现的延续。那面享受现成的同时，也要小心地雷。
其四，选择常用的技术；也称之为成熟的技术。这个说法是有点问题的。例如，Spring + Hibernate，Linux+Apache+Php+Mysql等。
以上排序不分先后，仅是在我的意识里面出现的次序；也许最影响技术选型的恰恰是常用技术或者框架。对技术选型得到的技术组合的反思，能够最真实的反馈选择过程的心理。这里非常隆重的强调，技术选型一定是选择了一组技术的组合。如果技术选型得到的单一技术，那么请忽略技术选型，继续项目开发吧。
那么应该从什么角度比较各项技术的优劣，从而选择合适的技术组合。我想到了以下几个方面：系统解耦而分成的子系统接口、部署方案、性能扩容方案、可用性部署方案、项目组的技术储备等。当然还有更细致的项目，计算各技术方案在每一项上的得分，得分较高的就是优先选择的技术；可以先选择得到较高的几个技术，然后研究其在未得分项目上的补充方案；最后确定合适的技术组合。