技术是个浑蛋，可是长得真好看
看完题目，请勿喷。最近的生活可能太苦逼了，好想吐槽一下~~~
首先，先来分享一段个人特别喜欢的话：
透视社会依次为三个层面：制度、文化和技术。小到一个人，大到一个国家，一个民族，任何一种命运归根到底都是那种文化属性的产物。强势文化造就强者，弱势文化造就弱者。这是规律，也可以理解为天道，不以人的意志为转移；强势文化就是遵循事物规律的文化，弱势文化就是依赖强者的道德期望破格获取的文化
老话说得好：三百六十五行，行行出状元。说的就是技术层面的事儿。技术是一个非常广的层面，比如挖掘机技术啊~~~~ 编程啊~~~
不错，楼主就是一只小小程序猿。那咱们今天就聊聊关于技术的那些事儿。
年前，我曾拿到一个了牛逼哥们儿求职的简历，当时在下那个佩服、那个感叹啊，拿出来精彩的一部分，给大家一个膜拜的机会：
其实，我想写这篇文章，主要源于最近的工作体会。
公司老总对我们很不错，并且深谙《从0到1》这本书的精要，工作态度走的也是Java的风格——开源。公司的业务，所有开发人员都要参与讨论并提意见。
我们都知道，从0到1是创造，从1到n就是复制了。他多次提到，希望大家积极参与其中，公司是大家的。他的目标就是公司出来的任何一个人都可以开公司，都可以干这干那。
说实话，我很喜欢这样的氛围。
让我感触的是，项目中技术没有啥特别的，就是单纯的SSH项目（Struts2+Spring+myBatis），是的，你没有听错。没有engix、redis缓存、集群。但是由于我业务接触了很多，SSH项目也搞得我们焦头烂额。（别看不起SSH啊，你真玩不转）
不得不问：业务为王的天下，技术到底充当了怎样的角色？
其实总结技术的用处，一句话就足够了：不怕不知道，就怕不知道。大家都在走开源的道路，不怕你不会这个技术，就怕你压根儿就不知道它的存在。适当的时候，你能想到用到那个合适的技术，这就是你懂得它的意义。
别跟我说你精通这个，精通那个，除非你真的很精通。
此外，想让自己写出来的代码，能够应对变化，真的不是一件简单的事情。之前写过一篇关于数据库设计的文章，也是源于业务为王这一句话。
由于数据库设计的不够灵活，导致后面的业务实现比较费劲；前期就设置很多冗余字段，应对了当下的需求，不能很好的应对变化。
首先，业务肯定是不断变化的。修改代码也是在所难免。可以说，当你修改代码的时候，就是看你写得代码好坏的时候了。如果一点点小需求变动，你都需要翻倒重来，那你就只能等待别人摧枯拉朽了。
有时候就像，Action和Service为什么要分开，分开干啥，你把逻辑都写在Service里面，需求一有小变动，就需要Service去。直接放在Action里面不就完了吗？
额，等等，逻辑都堆在一块儿，这不就又是面向过程了吗？
哎，这个面向对象思想啊。不是那么好领悟的。
最近，日子过得比较苦闷，临近上线，老板却在不断的改需求，而且是改过来，改过去的那种。同时，新需求也是不断。我也理解他们，跟OTA谈合作，一家有一家的要求，他们也是不断的去调和。
程序猿的日子就比较苦逼了，加班加点儿不说，改了半天，又改到了最初的设计上，唉。。。
最近一直在加班，对编程这份工作，更是有了一番新的理解。没有自己之前认为的那么重如泰山，也没有一些屌丝认为的那么轻如鸿毛。
最近，我一直在想，怎样才能做好一个产品呢？
尽管技术人员一个个都牛的不行，但是仅仅有技术，是做不出来好产品的。
经常变需求是好事儿吗？需求变更，肯定是劳民伤财的事儿。由于界面内容比较多，而为了较好的用户体验，一次一次的改需求，都是对数据库设计的一次次考验，也是对程序员写的程序的一次次考验。
数据库设计的好，程序设计起来就会容易很多，程序的改动也比较小幅度；
PS：什么样是好？就是明白哪一块儿需求变动大，哪一块儿数据量高，哪一块儿有并发，哪一块儿增删改多一些，哪一块儿查询多一些……这些都必须考虑到。
程序的验证做的全面，容错性高，结构清晰，注释的位置和多少都合适，这样的代码，是很好维护的。
做好一个产品，它依靠的一般不会是专有技术，而是以用户体验为中心的一系列活动都要做好。