对于一个软件开发工程师来说，技术是很重要的一项衡量指标；但是“技术”这个词的含义，自己之前一直存在着很大误解或是片面认识
通常意义上我们所说的技术，一般指技能，这点对于开发工程师来说，也就是：‘掌握语言的语法，某种定义方法和类库调用的方式，引用机制的了解等等；熟练的做到这些，很多时候你就可以认为自己是一个称职的工程师了；但是，对于一个优秀的工程师来说，技术的定义却远不止如此，甚至，以上的这些，都还不是最重要的
刚到一家新的公司，今天下午组长让我处理整合一个图片社区模块，涉及的业务包括用户资料修改，账户提现充值以及图集上传加载排序，原有的代码中有很多BUG以及不合理的地方，需要修复整改，具体如下
1. 账户提现时 金额需要验证，提现金额大于余额时不得提交
2. 社区用户的图集列表按照点赞数从高到低顺序排列，推荐列表中显示前3条
任务1拿到手时我的做法： 点击提现按钮时修改提现页面的后台提交方法，根据用户名获取用户账户余额，和输入框传入的余额做对比，如果超出，返回错误提示
组长的做法：前台增加验证脚本，加载时提现按钮为不可用灰色状态，通过输入框控件判断输入的值和已经载入的值余额之差，只有差值是正整数的时候，才打开提现按钮，在打开按钮的同时，触发后台提交方法中的GUIDKEY验证码，将其赋值，使方法体能够执行下一步（防止从前台页面绕过验证）。
任务2我一拿到，顿时间不知道该怎么入手，后来想了想，在后台写了一个方法：获取所有社区用户列表，遍历每个人的图集，将这些图集按照点赞数 从高到底排列，装入一个集合当中，取出前三条加载到推荐列表
组长的做法：组长拿到手，只看了一眼数据库，就说，这个表结构不行，必须重新建三张表，要把图片社区和摄影师上传图集分离开来，为的是防止同时具有摄影师和社区用户角色的使用者，在上传图片时，在图像表中传入一条摄影师用户名为空的图片记录。因为在这个系统里，不管是摄影师还是社区用户，上传图片用的BASE类是同一个，也就是不管从哪个入口上传图片，它们生成的图片编码是同一个。两种不同性质的图片，在一张表里，只用type类型子段控制，在上传者只有一种用户角色的时候，是没问题的，但是，假若上传者同时具备了两种或是多种身份，因为提交入口处的用户名信息和用户角色绑定，只做一次验证写入一次，所以，在一个用户同时具有两种身份的情况下，有一条数据必然是缺失用户名的
有些东西的差别看上去是技术的差别，从更深层次的角度来说，却是底层思维方式的差异：从纯技术角度来说，我的做法简便易思考，组长的做法略微复杂且不一下子容易想到；组长的做法可以有效的防止数据库的二次调用（尤其涉及账户金额这种安全性要求高的属性字段），我的做法具有一定的被攻击风险（无限提交）和安全性风险（金额这个值，查了两次数据库） 这只是表面上的原因
从底层思维模式深挖，可以看到：1.组长的开发是面向用户对象，以用户需求和习惯为导向的开发思维：用户拿到这个东西之后，有可能会怎么用，有可能会做什么操作，这些操作可能会出现怎样的问题？ 这些问题应该怎样避免和预防？ 用户在使用过程中，还有可能产生怎样的状况和新的需求，应该对此采用怎样的应对策略…… 而我的开发，是面向开发本身，以自身编程模式习惯为导向的开发思维： 这个问题 按我的经验和理解， 我觉得 应该怎么处理… 2.组长面对一个问题，是站在整个项目的层面上来考虑这个问题： 这个写法改下去之后，其他哪里相关联的地方还有用到？ 它会对整个项目产生哪些，产生多大影响？ 它在将来做拓展和维护时有多大的难度？？ 而我面对一个问题，一般就是想：如何解决当下的问题，如何让功能正常运转 ？？ 这两种思维方式的差异 导致了同一件事情，完成的效果 大不相同
思维模式的优与劣，比代码本身更重要也更值得每个开发人员重视
