一年工作经验总结

毕业快一年了，还是总结一下这一年的经历，起码给自己证明一下这一年不是混过来的。

应届毕业生的身份也即将变成往届毕业生，职场优势也将荡然无存，接下来就要依靠这一年所学的东西在职场立足。不过事实上应届毕业生的身份也没让我感觉有多大的优势，HR普遍都习惯性的拿面试者跟工作了几年的人比，管你是什么身份。说到底，职场比拼的还是专业水平和业务能力。当然，如果是能靠关系的话我收回之前的话。说句实话，不要让你的潜意识觉得“我有技术到哪里没人要？靠关系进去的能干啥？”。如果你有这样的想法的话，那说明你对职场一点都不了解。技术圈还是崇尚技术，这个估计是一直不会变的。但对公司来说的话，有可变性。当一个公司有稳定的业务以及核心技术成员并进行扩招时，假设要招聘一个人，你拿着你丰富的简历来到这家公司面试，并且技术面试表现很令人满意，估计板上钉钉的要你的。这时和这个公司合作的某一个公司的老板跟这个公司联系说：“我一个亲戚的孩子刚毕业，想到你这边来实习，你来给他安排一下”。你猜结果会怎么样？这就是一个人情了，人情的价值是不可估量的，应用的好能个自己带来无尽的财富的。当然如果是公司要新开一个业务那肯定是要有真本事的人。所以总的说来，技术行业靠技术还是可以混下去的，/*比起淫乐圈真的是要好太多*/。不行，这句话有点不妥，要注释掉，换个说法：比起某圈要好太多了。另外，学术圈貌似也已经沦陷了，用钱都已经可以买学位了。据统计，貌似博士学位的分布多数出现在官宦世家，而不是大学，也不知道是真是假。如果是真的，技术圈可能是唯一的净土了。

先说一说工作经历吧。第一份工作是做ERP业务的。我主要负责ERP下的WMS子系统，也就是仓库管理系统。对一个仓库来说，最重要的功能就是入库、拣选与出库了。当然最重要的就是库存数据。这里非常容易出现并发数据异常的场景，尤其是拣选程序的业务处理缓慢的话。比如有2个订单各需要2个A货物，经过拣选程序的各种计算后某一行的库存满足这2个订单需求，但该货物实际库存只有3个。如果这2个订单进行拣选的时间间隔特别短，在库存分配给前一个订单之前，后面一个订单就已经通过了拣选程序相关的分配库存的校验。这样最终的结果就是这一行库存就被分配了4个A货物，并发就出现了。直到拣选人员实际拣选时才会发现货物不足。要避免这种问题，一个就是要优化拣选程序的执行效率，另一个就是开启事务进行控制。但开启事务就意味着锁的时间会增加，并发会降低，对仓库来说，库存表的读写可以说是最频繁的，可能会直接影响整个仓库业务的执行效率。我有专门阅过sqlServer锁的相关资料，在进行UPDATE时，如果是对有索引的列（如主键，唯一外键，自增序列，主键和唯一外键都会有一个唯一索引）检索则只对行加锁，UPDATE结束，锁释放。若在事务中进行UPDATE，则直到该事务提交才释放锁。当然，更多时候没办法控制仅仅只对有索引的列检索。所以出现表锁的情况也是有可能的，一旦出现表锁，虽然不会出现死锁，但那效率可不敢恭维了。所以在效率和数据准确性之间就要有一个权衡了，如果数据不准确的情况出现的少的话，并且系统完全可以捕获这种错误，不启用事务也无妨了。

这份工作对我来说是一个很重要的经历，让我明白了电商平台的运营机制，也让我真正的掌握了数据库的使用，对业务级别代码有了足够充分的认识，这份工作经验可以说是我的启蒙导师，算是人生经历的一个里程碑吧。其实刚接触到业务代码的时候感觉特别的困难，这也看不懂那也看不懂，就一个几十行的代码花2个小时才能在依靠百度的情况下勉强看明白。至于原因的话，基础我自认为没问题，主要还是对业务的不理解，其次是经过业务洗礼的代码确实是难以理解。过了几个月感觉进步缓慢。但是在某一天就不知不觉地发现自己好像变强了很多，像升级了一样，看代码就是特别的流畅。或许这就是爱情吧，我的精神打动了代码，它爱上了我。但仅仅只有数据库的知识并不能让我止步，我的目标是在实际的业务场景中对整个软件体系有一个充足的认识。而我涉及到的事情只有数据库的维护工作，上层也就是后台代码以及前台代码是接触不到的，所以我也只能掌握数据库的知识。后来，我就自己根据当前的业务需求用做了一个局域网使用的工具（谈不上系统，软件也算不上，顶多算一个辅助，主要完善一些原有系统的缺陷）。因为对网络安全的知识了解甚微，所以不敢使用外网，毕竟是公司的生产数据库，几百万条业务数据不是开玩笑的。所以这个工具使用的局限性很大，虽然磕磕碰碰的做出来了，实际用户体验也还行，但开发这个工具的过程对我要认识后台语言体系的帮助几乎为零，没有真正的业务级代码的洗礼几乎是不可能掌握一门语言的，所以离开也是必然的结果吧。

第二份工作业务比较敏感，业务方面就不谈了。主要工作是维护现有的系统和做二次开发，涉及的点很全面，是B/S架构的系统，一个后台管理的网站。前后端以及数据库基本上全包了，刚开始比较忙，要进行二开，没有那么多时间去研究底层的设计，于是就直接按照现有的工作模式进行的二次开发。所以对底层原理不是很理解。大概用了2个星期左右把需求都解决了，之后就走上了研究底层的不归路。为什么说是不归路。虽然源码都是有的，但相关的文档并没有，所以很多用户定义的函数功能我并不清楚，我只能一层一层的往下面读，然后又碰到了调用dll的场景，于是又找反编译工具，反编译完了再往下读。读着读着，咦！怎么出现指针了？然后发现读到系统库里面去了。于是往上一级查询相关API的作用，知道了作用后再一步一步返回，得到最终的处理结果。过程耗时费力不讨好，里面会出现很多曾经学过的，但真实的应用场景基本不会使用的语法。比如JAVA的JNI，C#的unsafe{}。就问在做JAVA应用级编程的时候谁没事干突然想去写C，谁没事干C#写着写着突然就用指针了。有些地方还参杂着一些远古的技术，简直头痛。不过这样的学习方式也真的让我学到了很多，所以不要觉得研究底层没有什么用。虽然目前的软件领域的趋势就是调用各种封装好的功能应用到自己的业务场景，达到自己所需要的功能。现在都要效率，恨不得需求一提出来就立马要做好，哪有时间去研究什么底层原理。所以好像看似真的没必要去研究那些令人难以理解的底层。但只要功能出了BUG，就很难去排查。因为没有办法去确定问题的根源，没有人能说得清楚。或许你可以根据这个错误去百度，并且很多时候按照百度的方案都是可以解决，但你真的明白了引发这种问题的根本吗？高楼平地起，基础决定你的上限，有本事的人真的可以一个人单挑整个世界。当然，可能说的有点夸张，但也差不多。就像玄幻小说一样，等级分明，除了主角，等级高的就是比等级低的牛逼。但每本小说对主角的描述都有一个共同点，就是有一个扎实的基础。

这次的工作经验也算是勉强明白了后台语言的运行机制，为什么说是勉强明白呢，不自己真正动手去做，光看还是不会用的，但至少有了一个参考。不用走太多的弯路，浪费更多的时间。毕竟是一个商用的软件，虽然里面有些代码可能有点过时，但这也是一个时代的产物。想想以前死皮赖脸的要求技术经理让我自己完整的编写一个存储过程，经过了各种修改，自认为完美完成了经理提出的需求，不过最后还是没有用我的做的功能。虽然有些小失望，但是我知道我要的是什么，我也的确拿到了我要的。

其实现在真正支撑IT世界的是儿时经历过打卡引线的那一部分人，中国真正的高手是经历过DOS的那一代人，我们这一代人刚出道学的就是Java这种面向对象的语言，老一代认为我们是幸福的一代，但实际上我们就是个悲剧。我们渐渐远离老一代C/C++的时光，而越来越多的社会大众选择C#/Java,社会上越来越多的项目也都用C#/Java开发着，但掌控着IT命脉的大公司，微软，IBM,Google等等，它们却数十年闻风不动，依旧用着C/C++开发着它们的东西，的确，我们是简单了、方便了、高效了，但同时我们的定位也完成了，我们不仅在世界上早已有我们自豪的世界工厂称号，我们也成了IT产业的世界工厂，我们成了码农，我们不过是个搞应用层开发的，我们不过干净些，有空调，看着体面些而已。

在未来，软件行业对专业人员的需求只会越来越高，因为要满足用户的需求。至少就目前的软件发展局势来看，用户对软件的要求一定是越来越高的。软件的发展更多的情况是用户推进的。没有哪个用户会说：我就喜欢用谁谁谁出品的软件，我不管这个软件性能怎么样，用户体验怎么样，我就是喜欢。无非可能是一种先入为主的观念，一个软件用久了习惯了，不想去熟悉功能相似的新软件。因为无止尽的如根据用户内裤颜色变换APP主题的需求，才有软件今天的高速发展。

给想入这一行的新人一点建议。如果只是要满足社会用人需求，基础稍微好点，再面向百度编程，一般的业务需求基本都能搞定。这是事实，但企业要不要又是一回事。很多时候现实逼着你不得不去深究那些API的底层原理，实际上应用级编程又不需要这种知识体系（比如C/C++,汇编原理，数据结构）。所以说如果你真的想在软件领域有一些自己的见解或者想实现自己的价值，那些高度封装的语言绝对不要成为自己的终点，它们是为企业服务的应用级编程语言。这些语言可以用简单的一行代码调用API直接实现你要的功能，完全不需要理解它到底是怎么做到的，然后再把这些功能按照需求进行组装，一个系统就出来了。看上去很强大是不是，实际上也确实很强大，傻瓜式的用法深受码农的喜爱。但如果你不能脱离这种方式，注定了你的上限就在这里。随着年龄的增长，脑力一旦跟不上，新知识更加难以掌握，淘汰将是必然的结果。所以，趁年轻，多钻研钻研底层的东西。掌握了这些底层的知识会让你的代码变得更有味道，你在应用这些功能的同时完全能够考虑到在使用的过程中哪些地方不妥，按照这种编码方式一定会在某个时间出现异常。这样错误就完全就可以避免，这就是研究底层带来的好处。悟透了底层原理能你在使用的时候让你想的更多，更远。