号外!号外!走过,路过,不要错过!日本 IT 业的狗血八卦继续独家放送啦!! 2015 年 9 月 3 日,随着东京最高法院驳回瑞穗证券的上诉,维持二审的原判结果,一个长达 10 年的诉讼终于画下了句号.这个判例将对 IT 行业产生深远的影响:如果程序的 bug 导致了巨大的经济损失,应该由谁来承担?用户?运营商?还是系统开发商? Bug:计算机程序里的错误 今天故事的主角是,瑞穗(みずほ)证券,东京证券交易所(下文简称东证),和富士通. 各位富士通的同学,雷子真的不是富士通黑啊.你们公司行业内

道生一,一生二,二生万象.OO的思想就是抽象,万象归宗,化繁为简.99%的程序员使用OO,或者所谓的类库的目的就是好用,不必了解内部实现就可以直接达到所期望的结果.这时一种生产力的进步,一种流水线式半零件式的生产流程.程序员只是最后再流水线上拼接起来上个螺丝的工人而已(严格说来是码农).C++就是抽象万象的利器.用Windows举例子,从无到有这个关键的一步(所谓的底层),通产是C或者汇编.Windows源码大多是C/ASM编写,实现了硬件的抽象统一了抽象接口(中介有众厂商的驱动提供),然后从一

这是个持续多年的话题了,很多大公司,尤其是牛逼的独立分包公司(开发公司)都会有代码审核和严格QA程序,一般的公司就很难说咯,在法律上目前还没有完全支持处罚程序员bug经济损失的判例(国内如此),国外也是分为故意损害和无意损害两类,但是举证故意损害举证很困难.就我的经验来说(我只在小公司和小小公司待过,大公司和超级公司只是从资料和论文以及产品里看过),一般会有限制级要求和程序性要求,其他的就是使命感和责任心的管理,加强程序员的自我管理是很重要的学问:这里说的是OKR,不是KPI:技术型公司不适用制

来自猫扑:程序bug导致了天大的损失,要枪毙程序猿吗? 0 引言 年会上Review 源代码算什么? 法庭上 Review code 才带劲..... 2015年9月3日,随着东京最高法院驳回瑞穗证券的上诉,维持二审的原判结果,一个长达10年的诉讼终于画下了句号.这个判例将对IT行业产生深远的影响:如果程序的bug导致了巨大的经济损失,应该由谁来承担?用户?运营商?还是系统开发商? bug:计算机程序里的错误 今天故事的主角是,瑞穗(みずほ)证券,东京证券交易所(下文简称东证),和富士通. 1

序 所有的文章都会有序言,我的当然也不例外. 因为职业和工作的关系,很少有时间陪伴家人,感谢妻子10年以来的容忍和支持,感谢女儿给我生活带来的乐趣. 希望孩子长大了之后能热爱编程(可以不用以它谋生). 关于编程 世界上有两类程序员. 一类是为了谋生. 一类是因为热爱. 关于这一点,我在之前的直播中有具体的阐述,有兴趣的可以去看看:https://www.bilibili.com/video/av31334354 关于.NET 开发我很佩服 @陈晴阳 的执着.上班写Java下班写.NET.(手动点

程序员的日常三件事:写Bug.改Bug.背锅.连程序员都自我调侃道,为什么每天都在加班?因为我的眼里常含Bug. 但是真的有这么多Bug要改吗?就不能一次改完吗? 程序员听这问题后要拍键盘了,还!真!不!能! 用户使用场景的不确定性 在日常生活中,即便每个物品都有使用说明书,可一千个用户就有一千种使用方式.例如用诺基亚手机砸核桃,用iPad当切菜板,所以说程序是确定的,但用户的使用场景是不确定性的. 各种不按套路出牌的操作会给系统带来挑战,例如网上有个段子说: 一个人走进一家酒吧,要了一杯啤酒一

程序员:统治世界or修复bug? 时至今日,我们依然生活在一个市场和技术受到高度崇拜的世界里,但是历史演化的规律提醒着我们:当一个东西开始成为社会崇拜的对象时,其中暗藏的不利因素将悄然的进行着.有人认为数字技术和互联网能够消除物理世界的不公平,但是我们今天看到,这种想法就像是认为完全自由的市场可以带给人们完全自由的发展一样,显得不切实际. 还记得自己初学编程的初衷吗?每一个热爱技术的人都有一个梦想:在未来的某一天,我要用我编写的软件统治这个世界. 现在,随着IT技术.互联网技术.人工智能的迅速发

在最近的一周,我维护的业务系统出现了很多坏毛病,一周七天crash掉了4次,每次都需要都是因为一点很小的问题,触发了蝴蝶效应,导致整个系统全盘崩溃,于是产生除了叙述本篇的想法,当然这并不是为了掩盖我在Coding上的一些细节处理和职责疏忽,只是为了从根本的细节上去分析这些问题. (一.)为什么会产生BUG首先我们需要尝试理解一下什么Bug? 关于bug的解释 bug 是指任何计算机程序或硬件系统中的错误,故障或缺陷.错误会产生意外结果或导致系统意外运行简单来说:bug就是程序出了问题,产生了意外

开发应用程序是一项压力很大的工作,人无完人,工作中遇到bug是很正常的事,有些程序员会生气,沮丧,郁闷,甚至泄气,也有一些程序员则会比较淡定.如何进行修复bug的过程,是值得我们好好推敲的. 我想分享一些有关程序员在努力修复bug时常说的话和冒出的想法.当氛围变得紧张的时候,这些话就会显得轻松幽默.最终,bug也会修复成功,你将会继续下一个任务. 我相信许多web开发人员和软件工程师在编程中都会遇到困难,而事后回想起来,还会觉得很好笑. 1.我不知道该删掉还是重写 回归曾经写的源代码,总有一种想

开发应用程序是一个非常有压力的工作.没有人是完美的,因此在这个行业中,代码中出现bug是相当普遍的现象.面对bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着.因此,如何处理修复bug的过程也值得我们细细琢磨. 我想分享一些程序员修复他们的源代码时所经历的想法.这是事情变得紧张时所触发的轻松幽默.通常说来,应用程序终将可以工作,然后你也可以进入到下一个伟大的任务. 我相信很多web开发人员和软件工程师经历过这些艰辛,然后在事后一笑而过. 1.“我不知道

开发应用程序是一个非常有压力的工作.没有人是完美的,因此在这个行业中,代码中出现bug是相当普遍的现象.面对bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着.因此,如何处理修复bug的过程也值得我们细细琢磨.我想分享一些程序员修复他们的源代码时所经历的想法.这是事情变得紧张时所触发的轻松幽默.通常说来,应用程序终将可以工作,然后你也可以进入到下一个伟大的任务.我相信很多web开发人员和软件工程师经历过这些艰辛,然后在事后一笑而过. 1.“我不知道是要

案例 一个管理后台的bug,把操作记录中的操作员姓名,写成了该操作员的id.原因是修改了一个返回操作人姓名的函数,返回了操作人的id.但是还有其他地方也用这个函数,导致其他地方把姓名字段填写成了操作员的id.该bug污染了一条修改记录,操作员手动删除就好了.回滚代码后恢复.本质是修改了函数的返回值,却没有查看所有调用的地方.这个函数的名字叫getinfo,但是在代码的其他模块中也有同名函数,返回的都是id,让修改的人以为都是一个函数,引起了混淆.所以函数名也要修改,做到通过名字能够清晰看出函数功

程序员在普通人的印象里是一份严(ku)谨(bi)的职业,也是一个被搞怪吐槽乐此不疲的职业,程序员们面对复杂的代码敲打电脑时连眉头都不会皱一下,但是有一个词却是他们痛苦的根源,它就是Bug. 有不少的新手程序员,刚开始都是从修BUG开始做起的. 修bug有助于熟悉项目,了解大概哪些类参与了执行线路,相互调用关系又是如何,结构设计上有什么特点. 以前猿姐就听过这样一个故事 有三个程序员需要穿过一片田地,到达对岸的房子. 初级程序员看了一眼笑着说道:不远,只需要十分钟就行. 资深级程序员想了一下说道:

Java程序员薪水有高有低,有的人一个月可能拿30K.50K,有的人可能只有2K.3K.同样有五年工作经验的Java程序员,可能一个人每月拿20K,一个拿5K.是什么因素导致了这种差异?本文整理导致Java程序员薪水低的9大行为,避开这些大坑,你就离高薪不远了. 1.习惯即刻回报 技术刚刚掌握,能一边百度一边干活了就觉得该拿到多少多少钱了.找工作先想着多少多少钱,入职了没干几个月就想着要加多少多少钱,干了没几个月,薪水要是没涨,就放弃了,准备通过跳槽加薪,不跳槽的话,往往也会因为没加薪而牢骚满腹

最近公司组织项目组成员开发一个Android项目的Demo,之前没有人有Andoid方面的开发经验,都是开发C#的. 虽说项目要求并不是很高,但是对于没有这方面经验的人来说,第一步是最困难的. 项目历时一个多月,4个人开发,最终行成一个可用的Demo,整体效果还非常不错.这其中借鉴了网上的“仿网易客户端的Demo”还有就是学习<疯狂Android>,收获颇多,这里利用几篇文章做一个项目经验总结,还有就是更多的从C# 程序员的观点来理解Android的一些异同之处. 文章目录: CSharp程序

0.别对警告视而不见 相信不少的程序员会使用IDEA,使用它敲代码,有时候会出现警告,那么这时你对警告就不能视而不见了. 我们的目标是,写干净的代码,做风一样的男子! 1.编程习惯 种瓜得瓜种豆得豆,好的编程习惯可以大大降低BUG数量.譬如有if必须写else,即使else是个空语句 .     2.写代码的时间问题 对于程序员而言,千万别熬夜写代码.一些程序员在晚上11点,仍然在敲代码. 虽然你自己觉得头脑其实很清醒,但是第二天自测,或者QA测试的时候你有可能就会发现问题很多. 我们一般不提倡

在测试过程中,难免遇到开发人员因为一些原因不想修改个别bug的情况.遇到这种问题时,该如何去推进开发修改bug呢? 一.现状分析 1.开发人员为啥不愿意修复BUG? (1)开发与测试对bug的定义理解不一致产生的问题,bug路径较深,无法重现, 修改bug改动较大,影响范围广,无法理解,在生产环境不可能发生的时间,环境问题,不影响程序的实际用户使用: (2)工作流程方面原因,没时间,问题太小(优先级低),上线时间紧急,非自己名下的BUG(相关人员以离职后的BUG): (3)个人能力原因,找不到解

程序员一生与bug奋战,可谓是杀敌无数,见怪不怪了!在某知识社交平台中,一个"有哪些让程序员目瞪口呆的bug"的话题引来了6700多万的阅读,可见程序员们对一个话题的敏感度有多高. 1.麻省理工"只能发500英里的邮件" 该bug发生于麻省理工,当时其系统管理员接到统计系主任的求助电话,主任在电话中说:"咱们的邮件系统无法发送距离500英里以外的地方,准确地说好像是520英里." 此时的系统管理员内心是"毫无波澜"的,嗯! 然

程序员的踩过的坑也是可以分类的,很常见又很难解决的一类是偶然的现象,表现起来比较怪异. 而把一个问题Bug的偶现变成必现,是开发人员的一种能力.我认为也应该是测试人员的一种能力,但是各个公司要求不一样吧.我在华为做过测试,虽然时间过去很久了,但是当时学到的方法影响至今.总之还是那句话,对你要求高的才让你成长更快,所以不要辜负对你严格的人! 最近有几个Bug和小伙伴成功的从偶然的现象变成必然的现象,所以还是记录下这种有成就感的心情吧.早在华为测试的时候就可以帮开发定位问题了,后面到现在公司也时不时

  最近和一位从事多年架构工作的技术哥们见面,聊到了近期面试程序员的一些经历,谈到了"如何判断程序员水平高低"这个话题,颇有些感触,觉得有价值,因此花了些时间整理.分享给大家. 正文 程序员的水平高低,不是靠语言或外在表现就能看出来的,不是看他会多少技术.参加过多少项目.写了多少博客,而是看他在实际业务场景中解决问题的能力,尤其是面对一些特别复杂的问题,或在高强度.高压工作状态下解决问题的能力与态度. 技术可以通过学习掌握,但是解决问题.定位问题的能力却不是一蹴而就.大家可能会说,&q