作为 IT 从业人员,你觉得有啥工具大大提高了你的工作效率?

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了作为 IT 从业人员,你觉得有啥工具大大提高了你的工作效率?相关的知识,希望对你有一定的参考价值。

我也谈谈自己的一些提高开发体验经验,就说软件工具部分。
这里的经验基本上都是冲着一个原则去的:“凡是需要重复做的,必须使用自动化工具完成。”



1. 版本控制
一般自己的项目使用git,公司开发规定用svn。反正不管怎么样,版本控制少不了。有个说法,没有版本控制的项目,就等于没有。
版本控制的好处太多了,用过的人都知道。等于历史版本 + 代码备份了。这个提到的很多,就不多说了。
2.单元测试工具
写程序需要验证,如果快速知道新的代码和过去的写的代码不冲突,这个时候单元测试就能起到作用了。
当然单元测试的功能不仅仅是这个:

    验证代码正确性和可靠性

    验证新代码不和原有代码冲突

    验证自己代码不合团队其他人员代码有冲突

    验证合并是否有冲突

    验证快速

    可以作为API使用实例

    跨平台和跨环境测试

这个是现代开发流程的基本模块之一,没有单元测试的项目,不是一个合格完整的项目。
有了单元测试,就再也不用担心在大项目中,自己做的小修改有会有什么大影响了。开发压力大大减少
php的我用的是PHPunit,javascript用过的就多了,Jasmine,Qunit,Mocha等工具(不管哪一个,至少要用到一个)C#一般用nUnit。还有各种mock,faker辅助。

3.功能测试工具
就是交互界面测试,也可以是界面样式测试。代码写的方式大致过程和单元测试差不多,不过单元测试每个单元都是独立的,理论上不应该有任何依赖关系(只要有依赖关系就叫做集成测试);而功能测试,就是最后成品的测试,必须把所有依赖打开,并且在界面上进行测试。

界面功能测试的优点

    速度比人工快

    模拟真人操作

    可以录像后导出测试代码

    可以抓图

缺点:

    依赖多,依赖的环境变化可导致代码失效

    速度相对单元测试慢很多

    测试成功率可能不是100%

功能测试,也是自动测试的一种,至少解放了大量重复性劳动,大大提升界面功能开发的速度。

功能测试工具主要有phantomjs和Selenium。我两个都用,根据不同情况使用不同策略。

4. 依赖管理/程序包管理器

有了依赖管理,从此不用再手动去每个库的官方网站下载和更新库了。配置一下,运行一下命令行,然后就下载好了,定时在运行一下命令行,所有库又更新到最新版本了。开发体验大大提高。

列举一下主要好处:

    自动安装依赖库

    自动更新依赖库

    自动安装/更新依赖库的依赖

    最新库和现有项目有冲突,可以强制降级依赖库

    开发依赖和项目依赖分开,发布版本时候可以自动删除所有开发依赖库

    版本控制可以只收入依赖管理配置,无需收入依赖库的目录,大大节省版本控制大小

    统一团体所有人员依赖库的版本

依赖管理下载速度快,免除开发人员手动的重复劳动。大大提高开发效率

PHP的依赖管理是composer,js的依赖管理是npm和bower,C#的是nuget,

5. 流程管理/构建工具

这个叫法很多还有叫做任务自动管理工具的,不管是什么名字,都是一个意思:自动化流程管理。

简单的说从源代码到产品之间,中间还有一个复杂的过程,一般大致如下:

    代码清洁

    编译

    配置

    测试

一般对开发人员来说,凡是重复的,必须使用工具自动完成。开发人员是不愿意重复做这些流程,所以需要流程管理,把这些步骤全部用代码编排好,然后执行一个命令行,让电脑反复执行去。没有流程管理的项目不是一个好项目

JavaScript有grunt和gulp,PHP有Phing,Java有ANT。我用grunt比较多。

6. Live Reload

Live Reload一般是和流程管理一起使用的,(也有独立使用的版本)。独立出来说也是为了体现程序员一个终极特质:懒。凡是重复的,必须使用工具完成。Live Reload就是这个体现:按F5是个重复的低效率行为,必须交给工具完成

Live Reload的功能说起来很简单:

    检查文件是否变动

    如果变动刷新页面

给开发人员带来的直接好处就是查看页面变动,只要按ctrl+s保持代码就行了,连f5都不用按了。就这好处,足以把Live Reload这个工具当作神器了。配合流程管理工具,只要保存代码(ctrl+s),就马上进行构建,构建完成自动刷新页面。

我用的Live Reload是grunt-contrib-watch。

7.代码质量分析工具

人工检查代码的效率是比较低下的,所以质量分析这一块可以作为开发辅助工具,来提高开发质量

常见的代码质量工具有:

    语法检查,保证代码语法正确,可以跨平台,使用最佳实践

    代码风格检查,保证团队代码风格一致

    代码压缩,减少尺寸

    重复代码检查

    无用代码检查

    模块复杂度分析

    模块连接分析

等等,让然还有其他的质量分析,这些都是可以整合到流程管理上的。

JavaScript和PHP的用的比较多,Jshint,Jscs,uglifyjs,phpcpd,phpcs,phpdcd,PHPLOC等等工具,可以帮助开发人员提高代码质量,控制团队代码风格。

8.持续集成

有人和我说过,持续集成可以让你开发水平提高达到到另外一个层级。当我实践后,终于明白持续集成的魅力所在了。

要会持续集成,你首先必须学会以上6条(live reload除外),以上6条基本就是持续集成的几个基础模块,学会后,你自然而然就已经会了持续集成了。

持续集成的主要流程如下

    检查版本控制库是否更新

    如果更新,就下载最新版本的代码

    构建

    测试

    报告

当你设置好一个持续集成的项目后,以上的步骤应该就是全自动的了。还是那句老话: 凡是重复的步骤,应该用工具来完成。而持续集成就是这个终极工具。

持续集成其实就是流程管理的一个升级版本,或者说一个扩充。它们都是自动流程工具。它们的差别是:

    流程管理主要在本机(开发人员自己的开发环境)上执行,而持续集成则是在一个独立设置的环境下执行。

    流程管理继续的是本机代码,而持续集成构建的是版本控制中保存的代码

    团队中任何一个人push代码到版本控制中,持续集成就开始构建验证新代码的可靠性。

    项目流程配置完成后,流程管理需要执行命令行,持续集成应该全自动

    流程管理是持续集成的一个模块,属于持续集成的构建模块

    持续集成会有更多后续的专业功能,比如说产生报告,错误通知,构建历史,测试历史等开发新型

我们可以设想一下这样的一个情况,在有20-50个人的团队在开发一个PHP项目,每个人每天至少往版本控制中push大约10次新代码,而这个项目你又要保证在3个主流的浏览器中功能一致,样式相同,而这个项目又必须跨平台,可以在mac,window,linux上都可以运行,而且还要保证PHP5.4~5.6都可以运行。这个时候,持续集成系统的优势就会显示其真正的威力了。

总之,在一个专业项目中,持续集成服务所提供的自动构建和专业报告,可以把项目开发的专业水准再次提高到一个新的层次当中。

我用过的持续集成是Jenkins。

文章到此算完结了。其实开发中,还有很多优秀的工具,但无法和这些主要的开发工具相比,就不在这里说了。

参考技术A

IT职业就是传统的IT行业的工作职位,主要是计算机类的男性比较多在从事。这个行业的发展前景永无止境。对于系统运维来说,这是熊熊最熟悉的职业了,但是也是熊熊最深恶痛绝的一个职业之一。


行业发展

至于IT发展方向,我本不想多说,每个人的想法不一样,但是我还是希望唠叨几句,算是个建议吧,首先,大家可以去各大招聘网站浏览,热门的职位,如项目经理、技术总监甚至CTO等,还是以软件开发为主,毕竟,我们要考虑一个公司的组成架构(不考虑人力行政及财务后勤等职能部门),对于一个大型互联网企业来说,拳头部门是他的产品与研发部门,这两个部门支撑着整个网站乃至整个公司的核心,没有产品没有平台谈其他的都没有任何意义。

自动化测试工具

自动化测试的一个很重要的目的就是提高测试效率,并且快速的反馈质量。但是各个领域的自动化还是有一些区别的,比如:web自动化和手机软件自动化。而对于自动化来说,首先还是要去学习自动化的框架(这里跟一些朋友理解的自动化主要就是去写代码还是有一定区别的),好的框架能够让你事半功倍。而对于自动化人员来说,学习自动化框架对于自己后面的自动化开发工作是很有帮助的。

性能测试工具

要做好性能测试,一个最重要的前提就是需要了解被测试产品的系统架构,掌握整个系统的数据流向和交互;这样你才能够分析出系统的压力点,从而制定性能测试计划,否则你再牛逼的性能测试工具都可能达不到测试目的。这写都能够大大提升工作效率。

参考技术B

如果想提高工作效率的话,建议可使用一些办公类的便签软件,以此来规划每日的工作内容,以便提高工作效率。

    敬业签可记录每日工作待办事项,针对记录的工作待办事项可设置时间提醒;

    每一项工作任务的提醒支持单次定时提醒、周期循环提醒、重要事项间隔时间提醒和到期延时提醒;

    可以在规定的时间内提醒自己什么时间该做哪些事情了,大大提高工作效率。

不写代码搞定微服务架构改造,我信了你的邪

作者 | 蔡芳芳

近几年,微服务大行其道,甚至正成为 IT 软件架构的标配,但微服务的改造和落地依然困难重重,令无数中小型软件公司和传统企业陷入挣扎。11 月 17 日,飞算全自动软件工程平台正式发布。这次发布的“自动化开发”平台是对标传统开发工具(如 Eclipse、IntelliJ IDEA)的新一代全自动开发平台,业务人员只要基于项目需求绘制系统流程图,平台就可以自动生成经过实践验证的的微服务打包文件,可直接部署到服务器上,大大降低了微服务部署运维的门槛,并节省了大量时间和人力投入。InfoQ 记者提前专访了飞算云智总裁陈定玮,深入了解该平台的技术细节、诞生的故事以及其对于微服务、软件工程成本的思考。

自 2014 年 Martin Fowler 与 James Lewis 共同提出微服务的概念以来,它就吸引了大批工程师和企业的关注,可以说是当前软件开发领域最火的技术热点之一。

在今年年初的一项云计算应用调研中,O'Reilly 调查了 1283 家公司,有 52%的公司表示他们正在使用微服务进行软件开发,其中超过 28%使用微服务超过 3 年,超过 55%使用微服务的时间为 1-3 年。O'Reilly 还指出,企业对微服务的兴趣可能达到或接近顶峰。

相比传统“大而全”的单体架构,微服务架构在故障隔离、整体可用性、架构持续演进难度、可重用性、可扩展性和交付速度等方面有突出的优势。

传统行业的系统架构大多是单体架构,随着业务规模不断扩大、代码量的膨胀和团队成员增多,传统单体式架构的弊端会逐渐凸显:代码冲突加剧、模块耦合严重,一次上线涉及人员太多代码质量无法保证、协作效率低下,每次开发测试花费时间过长、动不动几周甚至几个月……对于这些企业来说,微服务架构已经成为刚需,但真正要进行改造和部署时又往往无从下手。

1 微服务部署分几步?

有些人可能认为选好框架、把系统内部接口调用换成 RPC 或者 Rest 调用,就算完成微服务改造了,其实这只是微服务的冰山一角。

微服务改造的第一步是对业务进行拆分。服务拆分是否合理直接关系到微服务架构的复杂性、稳定性以及可扩展性,也是目前业内关于微服务议论最多、吵架最多的问题。不过当前业内也并没有统一的做法或规范,各家基本是根据架构师经验、业务形态和用户规模等因素综合考虑拆分粒度。

服务拆分之后需要做微服务的分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,形成稳定的服务中心,使前端应用能更快速地响应多变的市场需求。

微服务的关键,除了跟服务设计本身相关的业务拆分和分层,还涉及微服务底层基础系统的构建工作。系统需要提供一套基础的架构,使得微服务可以独立的部署、运行、升级,同时让所有服务在功能上表现为一个统一的整体。这些系统性功能也需要有一系列服务来提供,它们可以视作微服务系统的“底座”。

一个完整的微服务系统底座最少要包含以下功能:日志和审计、监控和告警、消息总线、注册发现、负载均衡、部署和升级、事件调度、资源管理。另外还有一些非必须的底座功能:认证和鉴权、统一服务构建和打包、统一服务测试、微服务 CI/CD 流水线、服务依赖关系管理、统一问题跟踪调试框架、灰度发布、蓝绿部署等。

这个微服务底座必不可少,但实现起来工作量巨大。虽然业内已有不少可用于微服务架构落地的开源框架,但也并非拿来即用,而是有一定技术门槛,需要开发团队有足够的技术积累和实践经验,否则可能需要走很多弯路。以 Java 领域的微服务架构落地开源框架 SpringCloud 为例,光是组件就有数十个,并非所有开发人员都能很容易地全盘掌握这些组件的原理和使用。

此外,微服务架构本身也存在一些弊端。服务拆分之后,虽然单个服务代码量变小了,更易于修改和维护,但服务的个数变多了,系统总体代码量可能并不会减少,甚至更为复杂,对运维挑战很大。如果需要采用微服务架构的项目不止一个,而是几十个,难道所有项目都要让团队从头写一遍代码?经过实际业务验证的微服务组件能不能复用到其他项目上?如何保障所有服务的代码规范和质量?

上述这些,都是 2016 年底摆在陈定玮团队面前的问题。彼时的陈定玮正陷于 150 人研发团队的管理工作和永远也做不完的 CodeReview 中难以脱身。微服务的兴起是机会也是挑战,他开始思考一个问题:能不能用不需要写代码的方式来实现微服务架构的开发,进一步缓解研发项目管理的压力?

2 飞算全自动软件工程平台的初心:“干掉自己”

在陈定玮看来,软件工程行业虽然发展欣欣向荣,但实际上仍过度依赖“人工”,这也导致行业内普遍存在四大痛点:

  1. 项目成本高:人力成本高、沟通成本高、运维成本高、软硬件投入成本高;

  2. 开发周期长:开发者需要根据业务发展规模预期,配置相应的架构,不同架构的复杂度和开发工作量完全不可类比;

  3. 代码质量低:虽然业内有不少编码规范,但真正能遵守的仍是少数,而微服务架构下每个服务由不同开发人员开发,代码可读性、可维护性、重复度及可测试性都难以保证;

  4. 团队管理难:人才招聘难(符合要求的工程师难招,或者太贵)、人才管理难(大型软件开发公司或者国企、大型单位的 IT 部门人员过多)、技术资产保全难(员工离职后代码维护难)、技术依赖强(技术选型难、技术绑架多、技术趟坑多、技术沉淀难)。

2016 年,陈定玮团队从传统领域转型到互联网,研发团队从四五十人一下暴增到了 150 人,所有管理问题接踵而来。2016 年底,“不堪重负”的陈定玮开始反思软件工程体系管理的问题,并尝试制定解决方案。他希望将软件行业传统的“人工治理”的作业方式变成“法治”,告别代码,用标准化的流程操作和拖拉拽的方式实现开发。

对于软件开发人员来说,这是一个最终可能会“干掉自己”的项目,因此在一开始就引来了技术团队的不理解与抵触。最开始的时候,陈定玮只能单打独斗,同时不断给开发人员做思想工作。他希望工程师们可以从反复写代码、改代码的困境中解放出来,摆脱低创新、纯执行、重复性极高的代码编写工作,去思考、突破更高层次的技术问题。

虽然经历了无数质疑、不理解、争吵,但在董事长“没有预算限制”的信任与支持之下,陈定玮还是咬牙扛了过来。平台最主要的核心技术是用可视化的流程引擎代替代码来描述整个业务逻辑实现,运行时解析流程图执行,其中最大的难点就在于如何将流程图编译成微服务。陈定玮自己做技术调研和优化调整,攻克了这个技术难关。在魔鬼般的工作强度下,总算做出了一些可以“看见”的成果使人信服,虽然付出的代价是在项目初期长达一年的时间里完全没有“生活”可言。

当项目进入到第二个里程碑、平台初具雏形,加入这一项目的开发人员已经从 3 个人变成了 8 个人,说多不多,但都是精兵强将。

这个时候的平台其实还存在不少问题,在陈定玮看来,“没有经过实际生产环境实践验证的微服务架构都是耍流氓”,为了保障实际上线的效果和可用性,他开始“强迫”自己的团队在实际项目中使用这个平台。每来一个项目,就单独剥离一个团队使用这个平台做开发,第二个团队用传统的开发模式去交付,两个团队的工作同步进行。后者产出的 App 先交付给客户,服务升级时再将用平台开发出来的版本替换掉原来的版本。就这样通过一个个实际项目将平台锤炼得越来越好,下一步再给到不懂代码的业务人员试用,并改进界面功能和用户体验。

历经四年时间,飞算全自动软件工程平台总算顺利上线,这个最初看上去遥不可及的想法终于变成一个可以在生产环境大规模使用的产品。

在陈定玮团队中,大部分项目都已经改用这个平台来开发,为陈定玮有效缓解了项目和团队管理的压力。在公司科技项目数量越接越多、规模越接越大的情况下,公司技术团队却由 2016 年的 150 人,减少到了 50 人左右。陈定玮预计,“到今年年底的时候,公司技术团队二三十人就够了。”

3 PK 传统开发工具:效率提升数十倍

飞算全自动软件工程平台涵盖“项目管理”、“自动化开发”、“自动化测试”、“质量管理”和“自动化运维”等五大核心板块,可以通过平台管理从需求、研发、测试、部署、上线到运维的整个软件生命周期。借助该平台,从项目经理到产品经理、部分架构师可以直接完成项目的计划和设计,不需要对研发工程师做任务分解和沟通;只要明确项目需求并设计好架构,就可以通过绘制流程图实现全自动开发;自带服务注册中心、分布式链路追踪、服务发现、服务治理等能力。

不写代码搞定微服务架构改造,我信了你的邪

飞算全自动软件工程平台解决软件工程从项目启动到运维的 151 个问题

目前飞算全自动软件工程平台已经上线阿里云并对外提供 SaaS 服务。“自动化开发”板块率先发布,“自动化测试”和“自动化运维”板块的开发进度也已经完成 50%,会在不久的将来上线。

据陈定玮介绍,这次发布的“自动化开发”板块对标传统开发工具(如 Eclipse、IntelliJ IDEA),创新点在于用流程图取代了传统的代码编写,用户可以可视化地设计业务,只专注于业务逻辑,对使用者的专业领域、技术能力基本没有限制。

该平台提供了一系列标准化组件(包括基础组件、SQL 组件、工具组件等)、行业组件、安全模块等,这些组件和模块的开发代码只有在经过内置的代码质量平台审核通过后才能上线,可以有效规避传统编码方式难以保证代码质量的问题。

不写代码搞定微服务架构改造,我信了你的邪自动化开发平台界面演示

此外,平台自动提供内建的微服务能力,基于用户绘制的流程图,平台就能自动生成经过实践验证的微服务架构,用户下载项目部署包 + 执行服务包,放到服务端部署即可。用户不需要深入研究微服务框架,也不会陷入各类问题难以定位和解决的窘境。平台采用经过团队实际项目历练和验证的微服务最佳实践,在高并发、大业务量场景下的稳定性会优于用户自己使用的微服务框架。陈定玮指出,“虽然没办法跟阿里那么大的业务体量相比,但是足以支撑大部分中大型电商的业务体量。”

内建微服务能力也是飞算全自动软件工程平台与目前市面上已有的无代码、低代码开发平台最大的区别。陈定玮表示,飞算全自动软件工程平台目前在市面上还没有完全对等的竞争产品,市面上已有的产品均更偏向前端开发,而飞算全自动软件工程平台属于后端微服务开发。

不写代码搞定微服务架构改造,我信了你的邪表 1:传统开发产品 VS 飞算全自动软件工程平台

为了让大家能更直观地了解使用飞算全自动软件工程平台开发的效率与效能,在本周的发布会上专门设置了一个非常有趣的 PK 环节:基于同一份项目需求,开发人员手动编写代码和业务人员使用平台开发来比拼看谁开发的更快。

对于这样一个并不复杂的项目需求,一个业务人员使用飞算全自动软件开发平台开发只需要 20 分钟就能搞定,而开发人员用传统编码方式开发需要 1-2 天时间才能完成,开发效率提升数十倍。如果是更复杂的项目,开发效率的提升会更加明显。

4 未来微服务开发的变与不变

微服务虽好,却并非银弹。随着云原生技术的推广和大量微服务案例的落地,社区关于微服务模式质疑的声音越来越多。陈定玮也注意到了这一现象,他表示,如果是企业内部使用的简单系统,可能确实不需要用到微服务,但对于有高并发、高可用、快速开发要求的场景,微服务依然是当前最好的解决方案,暂时没有第二种选择。当前很多有数字化转型需求的传统企业,都希望能吸引大量 C 端客户到自己的平台上,将公域流量转为私域流量,如果没有微服务体系的支撑就很难做到。

飞算全自动软件工程平台主要的目标用户群体也是这些真正有痛点的中小型软件公司和传统企业,这些公司通常有微服务改造的刚需,但受制于团队和技术能力无法实现。飞算全自动软件工程平台就是要帮助这些真正对微服务有需求却不知道怎么玩转的企业或团队,低成本快速上手。对于领域和行业,平台并没有任何限制。陈定玮强调,“只要是 Java 能做的,我们的平台都可以做。除了驱动、游戏、操作系统,基本上目前的应用系统都可以通过我们的平台来实现。”

技术层面,飞算全自动软件工程平台接下来主要有两项改进计划:一是支持标准的前端页面模板或者完全自定义页面、通过拖拽的方式实现前端页面开发,二是完成“自动化测试”和“自动化运维”板块的开发。

市场层面,陈定玮也提出了自己的愿景:三年内帮助 10000 家企业。在平台正式上线之前,已经有十几家公司在试用并基于平台构建项目。他还有一个更大的目标,就是要通过知识经验管理的贡献,彻底改变软件工程行业现有的作业方式,实现软件工程的全流程自动化。

至于目标能否实现,就要接受市场的考验了。陈定玮表示,从传统的编写代码做开发,到设计流程图做开发,对开发方式是一次很大的变革,原来用传统开发方法做过的东西需要全部推倒重来,这是平台推广的一个难点。如何让企业和开发团队接受新方式、掌握流程图设计,更重前期培训,接下来飞算全自动软件工程平台研发团队会专门组建一支培训团队,辅导用户更快上手使用。

陈定玮也提到,飞算全自动软件工程平台主要是帮助大家提高开发和维护效率、降低技术门槛,但是坦率讲,它并不能包办一切,无法帮助大家完成设计方面的工作,比如微服务拆分、数据库表设计等工作,但会提供培训和专业开发人员来协助用户做好这些工作。这其实已经属于互联网软件体系设计思路分享的范畴,也是需要教育的。玩转互联网软件体系的方法与传统软件的设计思维方式并不相同,陈定玮希望传达这样一个理念,也会将这一工作作为未来的重点之一。





点个在看少个 bug 

以上是关于作为 IT 从业人员,你觉得有啥工具大大提高了你的工作效率?的主要内容,如果未能解决你的问题,请参考以下文章

我们要创刊啦!征集你的观点

超好用的Redis管理及监控工具,使用后可大大提高你的工作效率!

程序员,如何提升你的编程能力

docker安装知识文档管理工具TeaKKi

IT从业者们,你的工作压力大吗?

5行代码,带你完成数据可视化