从增删改查中突围

　　最近自己在做产品，考到了下面是别人写的文章，深有感触。

　　（转载：http://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513356&idx=1&sn=3520fe896ad6c20e999458dfec1f3f3b&chksm=80d679cfb7a1f0d9421f558ba29077e59d31f89b76333fc75bf066816a262c6e7fb80e721ad6&scene=0#rd）

      初入职场， 很多人是从所谓的“增删改查”开始的起步的， 通常是经理给了一个很小的模块， 小到了只有一张数据库表就能处理， 你只需要用公司自己的框架/开源的框架针对这个表写点 “新增/ 修改/删除/查询” 的操作就可以了,  俗称”增删改查“。

　　这是很自然的事情， 因为作为一个新人， 除非特别的牛， 否则怎么可能交给你做那些核心的东西呢？ 所以不要着急， 先把增删改查做好做精，然后再考虑下一步。
　　先从需求层面想想， 自己是不是把这个需求给弄清楚了？  无论一个需求有多小，都有主干分支，次要分支，异常条件等等， 自己是不是都考虑到了？  对这个需求有什么疑问？
　　界面上都有哪些输入？什么数据是合法的，什么是不合法的？ 不合法的应该给出什么提示？
　　如果是Web系统，还需要考虑安全， 会不会产生XSS，CSRF，SQL 注入等攻击?   如果框架已经帮着实现了， 正好可以研究一下人家是怎么做的。  

　　代码层面， 审视一下自己的代码是不是简洁、易懂？ 变量的命名是不是很容易理解？  代码的自解释性如何,  没有注释能不能看懂？   代码的格式是不是符合公司要求的规范？
　　由于代码被阅读的时间要远远多于代码被写出的时间， 心里要时刻想着：我写的代码在维护时是要被别人看的，可读性一定要好，否则会被别人骂死。 
　　到了开发者测试的时候， 自己一定要做充分的测试， 争取在交付给测试组以后基本上测不出什么重要Bug。 
　　此外，公司是不是要求写自动化的单元测试和功能测试？公司用了哪些框架来做自动化都是应该学习的东西。

　　虽然这是一个增删改查的小模块，但是麻雀虽小、五脏俱全，你把需求、开发、测试真的搞好了， 交付了“清爽”的、基本没有Bug的代码， 就会给大家尤其是领导带来深刻的印象： 这个小伙子不错！有前途！

　　于是更多重要的工作就逐渐地交给你了。
　　把自己的一亩三分地搞好以后还不够， 要想办法看到全局，看到整个系统是怎么运转的， 现在很多面试在问面试者项目经验的时候，经常会先让他讲一讲项目的业务背景， 然后从大的架构讲讲整体的技术， 最后才会进入自己真正负责编码实现的小模块，  很多人都会卡在第一步。　
　　所以光关注自己这一块是不行的， 眼界得开阔， 一有空就要去了解其他模块的业务和技术， 阅读项目的代码，  慢慢的形成一个整体概念。 
　　不要害怕/讨厌看别人的代码， 这是一个无法迈过的阶段， 我们工作中大部分时间都是在读别人的代码（再次强调， 写出可读性代码非常重要）， 然后在其中改那么几行， 很少有系统是让你从头开始敲出来的，如果你碰到了，那就太幸运了。 
　　从本质上来说，这其实是个态度问题， 或者说是上进心的问题， 你完全可以干完自己的活以后优哉游哉，  也可以费劲心力的去了解业务， 把那些“变态”的代码看明白，但是两者之间的差距很快就会体现出来， 那些主动的人就能在团队的讨论中发出自己的声音和见解， 被动人的只能在那里倾听。 
　　说到业务，搞技术的人切不可忽视，尤其是在一些行业软件中(如金融，保险，电力等)， 基本上是业务导向， 毕竟软件只是支撑系统， 人家还是靠业务来赚钱的。 如果你既精通技术， 又精通业务， 就构筑了自己的核心竞争了， 那会非常吃香，公司一定会牢牢的抓住你， 不让你走的。 
　　总而言之， 如果长期陷入到增删改查的包围中，人就会废掉， 我们要做的就是提升眼界、转变态度、立刻行动， 这些是最终决定你能否迅速突围的关键