本文目录

1. 运维这个岗位怎么样是不是很无聊
2. 为什么许多企业不喜欢用Access数据库
3. 运维和开发哪个前景更好
4. 面向对象编程的弊端是什么

运维这个岗位怎么样是不是很无聊

41

收藏分享转发到头条复制链接微信微信扫码分享新浪微博QQ空间举报电工网

2020年04月10日

运维：值班人员很无聊，巡检人员很辛苦[呲牙]

为什么许多企业不喜欢用Access数据库

因为Access不上不下，而且对于微软来说不赚钱。

前言：很多人不明白，Access首先是一个办公软件，其次才是一个数据库，它面向的用户是普通办公人员，它面向的场景是办公室或部门级。性能和多并发等等现代数据库看重的东西，对于Access来说恰恰是不重要的，它最重要的用途是给了普通用户一个易用的“关系型数据模型”处理软件，所以更不要拿Excel这种靠Vlookup来凑数的电子表格软件来对比。

对于普通用户来说Access本来应该是一个不错的桌面级数据库应用，它天生是文件形式，容易迁移，很容易做后端共享，还有一个我认为相当简单易用的前端制作方法（窗体、报表）。如果作为部门级数据库本应是相当不错的，我早先也做了一些简单的应用给办公室的同事使用，用于避免每个人都拥有自己版本的Excel文件，提高信息共享。然并卵，大家热情不高，一个原因是，普通办公室的人并没有关系型数据库的概念，意识不到数据库带来的便利（要不是强制，我估计很多人连ERP都不想碰）。另一个原因是，入门台阶比较高，一旦使用发生问题，一般人根本束手无策，远没有Excel的便利。

虽然Access相较于其它专业数据库，已经是傻瓜级别，无需借助其它工具就可以做一个不错的前端，甚至无需编程。然而无需编程不代表不需要懂编程，要想用明白它，几个必要的知识需要有基本的了解，如数据库概念、范式、SQL语句、VBA语法，这几条概念对于程序员来讲是基础概念，但对于excel函数都用不明白的普通用户来讲，基本属于不可逾越的大山的级别。这些障碍不是说Access再优化下、再添加几个辅助功能就能化解的，是天生的。所以Access可以说从一开始，就是面向高级用户（有人称为poweruser）的，虽然它放到了Office包里。

但是面向高级用户也有问题，高级用户不等于专业用户，这些人属于会琢磨，但也会惹事，对于一个企业来讲，需要放进数据库的数据是宝贵的，是经不起风险的，高级用户自身的能力以及精力方向最多可以保证Access给自己用不出问题，但保证不了给其他人用不出问题，所以对一个稳定经验的企业来讲，关于数据库的操作还是要交给一个专业的人如IT部门，或者购买商业级别的ERP、CRM等系统，这些有保障的投入，对企业来讲反而是最省钱的。

对于专业用户，比如专门开发系统的工程师，Access功能相对弱鸡，且不稳定，他们不会用。

对于软件开发商比如微软来讲，卖软件不挣钱，卖服务才挣钱，Access反而是在阻碍企业用户购买其专业数据库。微软很乐意企业找它来定制一个ERP系统，定制一套ERP比得上卖多少套Access啊！所以相较于不断给Excel添加功能，微软一直在削弱Access的能力（比如微软取消了用户权限管理功能，比如微软不肯给SQL编辑器提供自动补全功能），Access陷入爹不疼娘不爱的境地。

总上，对普通用户、专业用户来讲Access要么太高要么太低，只是对于有能力折腾的高级用户、有认识到Excel缺陷的用户来讲，Access是太香了。

运维和开发哪个前景更好

你好，关于运维和开发哪个前景更好，基本上所有做计算机行业的都会选择开发。

简述以下对比情况

（图解:开发工程师）

开发和运维虽然入门需要差不多的计算机专业基础知识。

但开发后面更多的是去创新，去解决Bug，一个好的全栈开发工程师需要掌握前端、后端、数据库一系列的专业知识，他是可以靠一己之力养起一个团队的人。

而运维只需要做好简单的系统修复问题，更多的是按照客户的要求进行修改简单地不能简单的数据处理，或者给开发做一些信息反馈，让他们帮忙处理逻辑性的系统bug，是一项繁琐的工作，我会简称他为“计算机行业的服务生”。

所以，开发比运维成长更快，更有前途。

（图解:运维工程师）

开发基本上是三年一大跳，二年一跨越。能力强的开发前三年是一个积累，第三年的跳槽或内部岗位调迁成为中级开发工程师，薪资基本上以万为单位。再经历二年的发展，可能会成为一名高级开发工程师或架构师，以后的路将顺风顺水，有能力独当一面，开一个属于自己的公司。

运维一般做的都是繁琐的事情，以维护客户为主，技术层面上不需要懂太多。好点的运维工程师是做服务器运维的，但全方位发展的开发也懂服务器方面的，甚至比运维更懂，因为他们得学会如何去优化系统性能，服务器也是其中一项。

所以，开发比运维更容易升职加薪。

开发是全方位发展的，而且都是带很强的技术性的。跳槽到同行业的其他公司熟悉系统后也能马上上手，为公司带来效益。好的开发公司都是抢着来挖人的。

运维的话局限性就比较大，每个公司开发的软件及业务流程或多或少上有差异。可能跳槽后得花大把的精力去维护客户，给人擦屁股，而且涨薪一般不明显，因为这项工作一般都可以被应届生代替。我前端时间就接触了一个在杭州的运维工程师，在一家单位6年工龄才8000，注意是杭州哦。他现在也不知道该怎么走了，也不敢走。所以运维一般在一家公司待久了，也就不舍得走了，跳和不跳都难受。

所以，开发比运维找工作更简单。

总之一句话，开发和运维，我劝你做开发。因为我也是一个苦逼的运维，如果上天肯再给我一次选择的机会。我现在敢拍着胸脯跟领导说，爷，我不干了。（纯属气话，说说哈，别让领导看见），但说真的，运维的话真的是繁琐，客户能把你气死，就差你帮他直接做完得了，唉，说多了都是泪。听哥的做开发去哈。

面向对象编程的弊端是什么

面向对象编程是一种处理复杂问题的设计工具，本身没有什么好坏之分，只有用的好坏之分。但面向对象的问题在于长期以来的技术环境、编程语言、一些工具的推广、培训和教育都大大的过分乐观的强调了面向对象编程本身可以带来的好处。以至于很多学习编程的人都深深的相信“只要用了面向对象编程（以及基于其基础之上的的一系列设计模式、规范、工具、框架），就能得到非常容易维护、可以复用、明晰可理解的代码“。

但，这并不是真的。

如果你经历过很多，就会发现“只要如何如何，就一定能如何如何”这个提法一旦出现，基本上就不靠谱，不管是编程还是别的什么事情。

在大量的场景中，可以偏执的认为“万物皆对象”（或者万物皆别的什么），但是哲学上的单纯并不一定能让现实中的工程变得更“好”。如果说非得有个“万物皆XX”，那么这个XX八成就是根据众多需求综合到一起的“折衷”。

简单从工程讲的话，如果程序（或者说工作）是一次性的，那么怎么写得快，能work就怎么来。这个相对好理解。但是，如果程序是要长期维护的，那么如何管理其复杂性是核心的问题。而管理复杂性的要点在于

即便是抽象，也有很多种做法。可以定义一组接口，这个接口是一组函数、一组服务的RPC还是一个class的publicmethod都可以根据实际情况商讨。面向对象只是这里面其中一种做法而已。一个想要把程序编好的人，需要注重的是理解问题，然后尝试做出几种不同的抽象，评估各自优缺点后得到一个当时可行解的能力。而现有的大环境、教育体系，没有那么多真实的、复杂的案例，只能用一些简单的samplecode来教授。并且在说明问题本身时，简化问题本身，而突出代码设计的“模式”。这就好像是在用视频教人游泳一样。学习者自己需要认识到这些培训只是个参考，玩真的还是要到项目里去体会。

即便是用面向对象做抽象也会有问题。很多时候，面向对象编程并不是一种好的“抽象”。如果抽象做得好，透过抽象出来的“接口”就可以轻易的使用这个系统。这时“大量的复杂性”被隐藏到接口后的实现里。这就像是你看电视从来都不需要拆开壳子看里面液晶屏幕和视频信号的转换，只需要知道【电源】、【调台】、【调音量】就能用。一个抽象做得好，往往要“deep”，隐藏足够的复杂度。而面向对象的文化/教育往往会鼓励程序员做很多无意义的，无性价比的抽象。看看有些代码里完全不知所云的adaptor，factory，builder等就是这种做法的产物。

此外，在大量使用继承作为设计方法时，也没有起到任何实质的隔离作用。如果你尝试扩展一个继承体系，往往需要了解整个继承体系才能写对代码——这时，复杂性并没有被隐藏起来。你也许只是代码写的少了而已。对于这种复杂度没有降低，编写代码只是写的少，但是要看懂还是得结合整个体系才能做到的方式，不是抽象，是“压缩”。压缩只能少写代码，却会让系统更难以理解了。

再说说类型本身。一些面向对象编码对类型的定义要求的比较严格。其本质假设是“如果一个Object的类型是XXXX”，则其行为模式必然是“YYYY”。但现实当中，一个Object的行为模式不光与他的类型有关，还与这个Object“如何被使用”有关。比方说，一个User的Object，如果是用户自己看自己，就可以登陆、登出，修改昵称；如果是其他普通用户看，就只能看看看昵称和头像；如果是管理员来操作，可以reset密码、注销或者踢出登陆。这时就得界定一个Scope，来说明现在的User到底是哪个scope的User。DDD的一些理念就源自于此——找到某个上下文的某个实体概念，不能有歧义。但是即便不用DDD，也必须用各种变通的手段，把“如何用”的信息与类型信息结合到一起来实现逻辑。很郁闷的是，这个“如何用”完全没有章法，可能是“iOSApp登陆“，也可能是“第一次下单时”，或者是“系统处于降级状态”时。你永远也猜不到下一次可能会有个什么条件是要纳入到上下文的。大家都知道大量用if不好，容易让代码变成麻花，无法维护。但面向对象编程本身没解决这个问题。很多文章提出面向对象某个模式可以少写if，让代码容易维护。但是这其实是建立在那个问题的上下文已经明确的基础之上。上下文易变的问题没有解决，换一个上下文，招数便不灵了，到时还得处理一坨“模式代码”，非常恶心。

最后，面向对象会倾向于将不同的代码抽象为不同相互作用的Object，但是有一些现实因素会让这么面向对象得到非常不理想的效果：

总结下，我希望所有的程序员都要理解自己的工作的最终目的是干什么的，并且活用自己所能用到的一切工具来达成自己的目标。不要在各种编程范式里迷了路。如果是初学编程的人，我衷心的希望你的编程课程讲授的是解决一些实际的问题，多了解业务，多尝试对业务的变动作出合理和准确的预。不要过早的接触高层的思想和哲学层面的问题——一个小孩看《红楼梦》又能真的看懂多少呢。

好了，文章到这里就结束啦，如果本次分享的为什么许多企业不喜欢用Access数据库和为什么不建议做数据库运维问题对您有所帮助，还望关注下本站哦！