不要因为技术而技术，技术选型的初衷是需求

"人是活的，程序是死的"这句话我时常提起，可能很多人不是很理解我为什么会这样说，下面我就简单来谈谈我对这句话的理解。
　　
　　1.不要因为技术而技术，技术选型的初衷是需求。
　　
　　现在很多人在做项目的时候，开口就提项目用的NoSql、大数据处理、分布式系统等等技术。技术真的这么重要吗？
　　
　　技术在软件开发过程中的地位是不言而喻的，但是一个项目选择合适的技术去实现是很有必要，也是一个很好的学习机会。
　　
　　比如做一个简单的人事管理系统，简单的说就是对数据的添加、删除、修改。
　　
　　但是随着NoSql的普及和运用，很多人在设计的时候可能会想用缓存可以减轻数据库压力，增加数据的读取速度等等优点。
　　
　　从设计图可以看出基本的设计，设计之初就想到NoSql的好处，但是很多问题都没有考虑到，比如：数据的同步策略、简单数据用NoSql效率真的比直接用数据库高，高好多等等问题？
　　
　　所以说技术和需求是相辅相成的，单一的需求或者技术就是咩有意义的，那么在需求变更过程中选择恰当的技术解决问题很重要、很重要？
　　
　　2.做功能之前请不要先说效率，请先完成功能在进行优化效率。
　　
　　编码的运行效率直接影响到系统的运行速度是非常重要的，但是当你遇到一个问题的时候，一起讨论问题的时候。你是否最先想到的如果去解决问题，而不是看别人意见的缺点（这样效率高不高、影响性能高不高、安全性等问题）？
　　
　　我这里不是说考虑这些不好，而是当你在想到一个比较的成熟的处理办法之后，你在去想这些问题。可能会有人提出质疑，这样做是不是太片面了、不利扩展性等等问题？是这边必须承认有这样的问题，但是一个功能都没有做出来，想这些问题有用？
　　
　　比如在遇到webapi请求后，根据actionID去判断执行对应的fun时候1.用if去完成可能就会有人说这样写，万一ActionID太多不利于扩展性，不够灵活。
　　
　　2.好吧我换成复制代码（ActionID）
　　
　　：复制代码可能还是会有上述的问题。
　　
　　3.好吧我再换一种吧可能会有说这样用影响性能啥的。
　　
　　其实最后我只想说一句，这些方法你都用过，尝试过？晓得会影响扩展、安全、性能？如果真有，你有更好的解决办法？如果有更好，如果没有那么还是建议你先一步一步的先去解决当前的问题，那么在考虑下一步的其他问题吧？
　　
　　3.太过死板，不懂灵活。
　　
　　当遇到一个问题的时候，一味的去新的方法或者新的东西上面去想办法，不能仔细的回看自己原来做过的东西是否可以修改/重用？
　　
　　比如一个如下的简单div组装的TREE树形结构图复制代码四川省成都市绵阳市德阳市复制代码当知道一个市级的ID去查询省级的ID很多人觉得按照规范应该是根据市级DIV然后去查询父级的DIV然后在查询ID，这个方法可行的，但是如果树N多层数，不是需要查询父级的父级...
　　
　　其实认真观察之后会发现每个市级的ID 和父级ID 是有关系的，可以直接操作ID变化，组装父类ID，但是如果父类和子类没有关系...
　　
　　一个div标签其实不但可以ID，还可以用其他属性表示其关系或者对应的ID，然后根据其他属性查询，但是可能在规范性会有点小问题...
　　
　　在初始化的时候 ID 可以是 SJ+ID这样组合，然后切割ID就可以查询组装...
　　
　　如果上述都不行，可以不用DIV组装用JqTree等等这个例子其实就是想表达一个其实解决一个问题的办法多种多样，一种不行换一种，条条大路通罗马。