微信小程序制作
当前位置:网站首页 > 软件开发制作 > 软件开发如何规避时间碎片化的坑? 返回列表

软件开发如何规避时间碎片化的坑?

作者:admin 时间:2020-08-10 浏览量:623
时间的碎片化是软件开发过程的危害之一。本文分析了时间碎片化的原因和结果,并试图给出修正此管理缺陷的方式方法。为什么讨论时间的碎片化 ?
产生有效成果的智力活动,总是需要连续的时间来保证。许多忘我思考的典故都证明了这一点。 软件开发是一种智力活动,因此也遵循这一道理。 打断某人的工作,不论是智力工作还是体力工作,对工作的效率和产出总会产生负面影响。 只不过与体力劳动不同, 智力劳动受到这方面的负面影响要大得多。 对一名建筑工人,如果他连续工作的60分钟被打断成3个不连续的20分钟, 其产出与连续工作60分钟相比,是基本一致的。而对一名软件开发人员,3个不连续的20分钟内的工作成果,恐怕只能相当连续的40分钟的成果。有20分钟的时间被丢失了。 为什么会这样? 谁偷走了他的时间?下文试图给出解释。
时间如何破碎 ?
仔细观察我们每天的工作时间花费就不难发现,存在天然的时间断点把我们本来连续的工作时间碎片化。午休、倒咖啡、去洗手间等等。除此之外,一些偶发的事件也能打断我们的思绪,比如一个电话,一个邮件提醒,或一个 MSN 消息。 我们不是古庙里的僧侣, 因此尘世中的干扰总是存在。 但这些不是本文讨论的内容。 我想讨论的, 是在软件开发管理中不合理的做法导致的时间碎片化。我认为以下做法是不合理的。
一人多任务过分强调面对面沟过多的全体会议
一人多任务有些管理者喜欢让开发人员同时在几个任务上展开工作,而不是顺序地完成它们。 这样做可能基于以下理解:
任务越早展开,越能尽早暴露问题,从而便于及时解决,降低管理上的风险。开发任务紧,多任务安排可以增大开发人员的负荷,防止他们偷懒。多个任务具有相同的优先级,而且彼此之间没有依赖关系,因而应该同时展开。
任务启动的早,并不能消除问题,只是把问题提前了。从这个角度讲,问题的总量并不会减少。既然这样,过早地暴露出问题有什么好处呢? 在项目的可用资源(人力、时间)一定的情况下, 我看不到这样做的好处。 如果项目资源可以增加, 一人多任务的情况就不会出现,也就没必要讨论了。
通过多任务来提高开发人员的工作强度并防止他们偷懒的做法,我认为是幼稚的。管理者应努力和开发人员建立起信任关系,并通过其他方式激发他们的干劲。 当他们像负重的骆驼一样被对待时,作为会说话的智能生物,开发人员知道如何把超额的重物放在原地,而令管理者觉得他们在负重前行一样。
一人多任务的安排的问题在于,人不是多核系统。 他只能采用交替工作的方式来“同时”展开多项任务。当他在不同任务间切换时,特定任务上的工作时间就不再连续了。就像单核CPU执行多任务一样,这是让开发人员的大脑应用 TDM 技术。不幸,人脑不是高效的 TDM 设备。
无论如何,一人多任务的安排都应该努力避免。 如果仅仅因为优先级相同,那这些任务可以随机地顺序安排。
过分强调面对面沟通
面对面沟通是敏捷开发实践中强调的一个重点。许多管理者据此在整个组织内鼓励面对面的交流。我不认为这是一个好的做法。敏捷开发队伍是由 自组织 (self-organized)的小团队构成。敏捷开发中面对面沟通是指自组织团队内部的沟通。这种内部的沟通,被证明是高效的。 但是,把这种方式推广到自组织团队的边界之外,则是糟糕的做法。外部的沟通以受控的、相对正式的方式进行,是对自组织的团队的保护,使之免受干扰。自组织团队就像封装良好的软件组件。它应该是内聚的,外部只能通过定义良好的接口与之交互。
很多时候,面对面交流,仅仅是提高了交流发起者的效率而已。(甚至这一点也值得怀疑,因为经过仔细斟酌写下的文字,通常要比现场发挥的言语表达的更清楚)。当你礼貌地找某人谈话时,你已经礼貌地打碎了他的时间。你在损害他的效率。
说到这里,请读者不要误解。我不是在鼓励开发人员成为像患有自闭症一样的程序怪人。我只是想强调,过多的当面交流会导致时间的碎片化,从而影响整个团队的效率。 有其他沟通方式(比如邮件),能把对他人的干扰降低。
过多的全体会议
喜欢召开全体会议的团队领导者,在召开全体会议前请思考,会议内容是否是每个人都必须知道的? 是否是必须口头传达给每个人的 ? 如果是一场讨论会,是否这些人都需要参与到讨论中来? 由于全体会议打断了每个参与者的时间,时间碎片化效果扩展到了全体,因而影响更大。
时间碎片化的后果,时间碎片化有两个主要后果,即有效工作时间的减少和发生缺陷的可能性增大。有效工作时间的减少
软件开发工作是剧烈的脑力活动。象引擎一样,人的大脑在进入高速运转前,需要一个预热和启动过程。让我姑且称这里消耗的时间为“思维引导时间”( Mind Bootstrap Time , MBT )。这一时间的长短,取决于你面对问题的复杂性(和昨晚的睡眠质量?)。 比如, 某人的谈话如果被打断后,他可能会问“我刚才讲到哪里了?”。要继续之前的谈话,他就需要重新思考交谈的内容并从被打断处开始。这里花费的时间,就是 MBT 。 对一段谈话来讲, MBT 可能只需几秒钟。对软件开发活动,则可能需要好几分钟。
现在已经不再是一个文本编辑器解决所有问题的软件开发时代了。比如对一个典型的 JEE 开发项目,我们应该很容易理解一个程序员早上写下第一行代码前所做的以下操作:
打开 Eclipse IDE 。在 Eclipse 欢迎界面下的滚动条努力向前的时候,
启动开发用数据库服务(比如 HSQLDB )。在数据库服务启动日志还在 DOS 窗口翻滚的时候, 他
打开数据库 GUI 客户端。接着,
启动 tomcat 。
在 Eclipse中打开昨天工作中的Java源文件,开始编写今天的第一行代码。
我把这一过程所花费的时间,称作“环境准备时间”,即Environment Preparation Time(EPT) 。 如果连续的开发时间被打断,开发人员可能需要重复这一过程。 EPT 会因开发环境的不同而长短不同,但这部分时间总是存在的。
让我把 MBT 和 EPT 称作断点时间。 断点时间不是有效的工作时间,因为它们不能带来直接的产出。 这里想强调的是, 有效工作时间是必需的消耗,而断点时间总是可以通过减少时间碎片来减少或避免的。如果时间连续性已经被打断, 断点时间还能被消除吗? 我认为答案是否定的。
碎片化的时间, 就像被田埂分割的土地。分割的越多,实际可种植面积就越少,不论田埂修的多狭窄。
发生缺陷的可能性增大
打碎的玻璃杯子被重新粘合后可恢复完整并继续使用。但粘合的痕迹让它不再美观。更重要的是,重新粘合可能引入缺陷:接缝处未对齐的话会产生缝隙;粘合材料和杯子本身材质的不同会使整个杯子的应力不均,从而使它比以前更容易炸裂。
通过重新进入状态并找到上次离开时的工作点,开发人员可以接续之前被打断的工作。但就象重新粘合的杯子一样,这里不仅有直接的有效工作时间损失,更有可能引入后续问题。 “我刚才写到哪一行了?”,重新回到代码前的程序员可能会这样问自己。通过回想,他找到了离开时正在完成的switch结构并继续编写下一个case子句。不幸的是,前一个case子句遗漏了本该有的break。一个bug就这样产生了。修复此bug的时间可能是撰写这部分代码的数倍[1]。
这个引入bug的例子很容易应用到其他开发工作上,比如需求分析、系统设计、测试等。简单讲,时间的碎片化使得开发过程中发生缺陷的可能性增大。人脑虽然比电脑复杂的多,但在断点管理方面,可比后者差很多。
时间碎片化是开发工作直接的危害之一。虽然很多时间断点无法避免,但管理方式的改进能减轻这方面的危害。减少对开发人员的干扰,提高他们工作时间的连续性,是高效管理的必要手段之一。理解了这一点,把团队拉到偏远的酒店或关到一个单独的房间进行所谓的“封闭式”开发,就显得不是那么必要了。
联系方式:18066528545   029-89298792

阅读过此文章的读者,还阅读过下面的文章

  • 小程序与原生APP那个好?下面我们就来一起了解一下小程序与原生APP那个好。以下是所整理的小程序与原生App的内容,希望对你有所帮助。

    小程序的优点:

    基于微信平台开发,享受微信自带的流量,这个优点最大
    无需安装,只要打开微信就能用,不占手机内存,体验好
    开发周期段,一般最多一个月就可以上线完成
    开发所需的资金少,所需资金是开发原生APP的一半不到
    小程序名称是唯一的,在微信的搜索里权重很高
    容易上手,只要之前有HTML+CSS+JS基础知识,写小程序基本没有大问题
    基本不需要考虑兼容性问题,只要微信可以正常运行的机器,就可以运行小程序
    发布,审核高效,基本上午发布审核,下午就审核通过,升级简单,支持灰度发布
    开发文档完善,社区活跃
    支持插件式开发,一些基本功能可以开发成插件,供多个小程序使用
    小程序的缺点:
    局限性很强(比如页面大小不能超过1M,不能打开超过5个层级的页面,样式单一,小程序的部分组件已经是成型的- 了,样式不能修改,比如幻灯片,导航)只能依赖于微信依托与微信,无法开发后台管理功能
    不利于推广,推广面窄,不能分享朋友圈,只能分享给朋友,附近小程序推广,其中附加小程序也收到微信限制
    后台调试麻烦,因为API接口必须https请求,且公网地址,也就是说后台代码必须发布到远程服务器上;当然我们可以修改host进行dns映射把远程服务器转到本地,或者开启tomcat远程调试;不管怎么说终归调试比较麻烦
    前台测试有诸多坑,最头疼莫过于模拟器与真机显示不一致
    js引用只能使用绝对路径,不能操作DOM
    原生App优点:
    原生的相应速度快
    对于有无网络操作时,譬如离线操作基本选用原生开发
    需要调用系统硬件的功能(摄像头,拨号,短信蓝牙…)
    在无网络或者弱网情况下体验好
    原生App缺点:
    开发周期长,开发成本高,需要下载
  • 小程序和Vue写法的区别?下面我们就来一起了解一下小程序和Vue写法的区别。以下是我所整理的小程序和Vue写法的区别,希望对你有所帮助。

    遍历的时候:

    • 小程序wx:for=“list”,
    • 而Vue是v-for=“item in list”

    调用data模型(赋值)的时候:

    • 小程序:this.data.item // 调用,

    • 小程序:this.setDate({item:1})//赋值

    • Vue:this.item //调用,

    • Vue:this.item=1 //赋值

  • 小程序调用后台接口遇到那些问题?下面我们就来一起了解一下小程序调用后台接口遇到那些问题。以下是所整理的小程序调用后台接口遇到的问题,希望对你有所帮助。

    数据的大小限制,超过范围会直接导致整个小程序崩溃,除非重启小程序

    小程序不可以直接渲染文章内容这类型的html文本,显示需要借助插件
    注:插件渲染会导致页面加载变慢,建议在后台对文章内容的html进行过滤,后台直接处理批量替换p标签div标签为view标签,然后其他的标签让插件来做
  • 分析微信小程序的优劣势?下面我们就来一起简单的了解一下微信小程序的优劣势。下面是所整理的微信小程序的优劣势,希望对你有所帮助。

    优势:

    容易上手,基础组件库比较全,基本不需要考虑兼容问题
    开发文档比较完善,开发社区比较活跃,支持插件式开发
    良好的用户体验,无需下载,通过搜索和扫一扫就可以打开,打开速度快,安卓上可以添加到桌面,与原生APP差不多
    开发成本比APP要低
    为用户提供良好的保障(小程序发布,严格是审查流程)

    劣势:
    限制较多,页面大小不能超过1M,不能打开超过5个层级的页面
    样式单一,部分组件已经是成型的,样式不可修改,例如:幻灯片,导航
    推广面窄,不能分享朋友圈,只能通过分享给朋友,附加小程序推广
    依托与微信,无法开发后台管理功能
    后台调试麻烦,因为api接口必须https请求且公网地址
    真机测试,个别安卓和苹果表现迥异,例如安卓的定位功能加载很慢

  • 简单描述下微信小程序的 相关文件类型。下面我们就来一起了解一下微信小程序的 相关文件类型。以下是所整理的微信小程序的 相关文件类型,希望对你有所帮助。

    wxml 模板文件,是框架设计的一套标签预言,结合基础组件,事件系统,可以构建出页面的结构

    wxss 样式文件,是一套样式语言,用于描述WXML的组件样式
    js脚本逻辑文件。逻辑处理网络请求
    json配置文件,小程序设置,如页面注册,页面标题及tabBar
    app.json 整个小程序的全局配置,包括:
    pages:\[所有页面路径]
    网络设置(网络超时事件)
    页面表现(页面注册)
    window:(背景色,导航样式,默认标题)
    底部tab等
    app.js 监听并处理小程序的生命周期函数,声明全局变量等
    app.wxss 全局配置的样式文件

  • 请谈谈原生开发小程序,wepy,mpvue的对比?下面我们就来一起了解一下原生开发小程序,wepy,mpvue的对比。个人认为,如果是新项目,且没有旧的 h5 项目迁移,则考虑用小程序原生开发,好处是相比于第三方框架,坑少。

    而如果有 老的 h5 项目是 vue 开发 或者 也有 h5 项目也需要小程序开发,则比较适合 wepy 或者 mpvue 来做迁移或者开发,近期看wepy几乎不更新了,所以推荐美团的mpvue。
    而如果如果团队前端强大,自己做一套框架也没问题。

029-86195145 180 6652 8545 西安嘉瑞德网络科技公司
工作时间:周一到周六 8:30-18:30
邮箱:2528823962@qq.com
QQ:2528823962
地址:陕西省西安市未央元朔路明丰伯马都A座10820室
  • 微信小程序制作微信二维码
    扫码咨询
Copyright © 2015 西安嘉瑞德网络科技有限公司 陕ICP备17015187号-1