您所在的位置:主页 > 行业资讯 >

程序员最理想的公司是什么样的?

时间:2018-01-30 14:41来源:未知 作者:os 点击:

  

  Glassdoor最近发布了2016年最佳工作企业排名/员工选择奖,正如你会想到的,位于顶端的就是科技行业的那几家知名企业(Airbnb,Facebook,LinkedIn,Google),而上榜的其他一些公司则并没有家喻户晓。排名基于员工的匿名评论和评级,最后经过专门的算法得到。调查要求受访者对他们公司的这些标准进行评价:工作机会,薪资福利,工作/生活平衡,高级管理人员,文化和价值观。

  正如已经有人要求数以千计的求职者谈谈他们理想的就业场景,上述的每个标准都引发过无数次的讨论。 Glassdoor并不仅仅局限于科技产业,因此此调查的标准比较通用,适用于任何垂直领域中的公司。

  根据我听到的开发人员如何描述他们自己的理想工作状况,我认为还可以添加下面的标准到Glassdoor的排名名单中(排名不分先后):

  自主权利和工具的可用性

  公司是否允许给你笔记本电脑和经过授权的IDE以及操作系统,以及是否允许你使用开源工具?限制工具和语言的企业可能会妨碍他们的员工学习一些市场化的技能,这会迫使关注于就业的个人只能在下班时间或寻找新的机会来发展这些技能。

  学习文化

  公司是否致力于让员工通过不断的学习来发展自己的事业?学习途径可以简单到在一个不熟悉的堆栈中开发原型,可以是在内部举办边午餐边学习的讨论会议,也可以是正式的培训,甚至可以提供带薪休假或预算以参加会议和用户组。

  项目工作的多样性

  花10年时间去维护静态项目不会被未来的老板认为拥有10年的工作经验。这只会被认为是10次的1年工作经验。项目工作的多样性有利于新的发展:低维护比例往往对应更愉悦的员工。

  正确地做事

  开发人员倾向于那种能提供专业化做事环境的公司。提升公司在Joel测试上的开发分数是员工可能会高度评定工作满意的一个方法。

  挑战

  日常工作是否是一个挑战?即使是补偿优渥的员工,当他们的职责不再有趣的时候,也会想要跳槽。

  尊重和重视项目

  公司是否将技术(以及技术人员)看作他们业务的核心要素,开发人员有没有得到应有的待遇?这通常是在软件产品业务中是显而易见的,但在认为技术是成本中心的企业则不尽然。

  如果我有什么遗漏的地方,欢迎在评论中告诉我。
 

  如何写出一个让人很难发现的 bug?

  程序员的日常三件事:写bug、改bug、背锅。连程序员都自我调侃道,为什么每天都在加班?因为我的眼里常含bug。

  那么如何写出一个让(坑)人(王)很(之)难(王)发现的bug呢?

  - 1 -

  新手开发+新手测试=无敌巨坑

  有一天凌晨,某组的程序员们被电话轰炸醒了。用户纷纷投诉自己的业务数据离奇消失了!

  大伙排查半天,原来是新来的小王埋的坑。他三个月前开发的定时任务出bug了!

  那时刚来的小王刷刷地将代码写完后,手把手教新来的测试实习妹子怎样测试这块代码,估计是妹子还没搞清楚里面的逻辑时便稀里糊涂地将代码上线了。

  万万没想到这bug隐藏这么久,由于错误的逻辑导致错误的数据,错误的数据导致任务死循环执行,当执行的时间过长,到某个点时,系统如汽水开瓶般“砰”地崩了。

  业务不熟导致逻辑理解有问题,是大部分新人都会存在的问题。此时最好安排个有经验的测试“调教”下,降低bug发生率。

  - 2 -

  不考虑系统拓展性,怎么方便怎么写

  史上最出名的“千年虫”bug令全世界恐慌,甚至传出“世界末日”的谣言。

  原因竟让人啼笑皆非:当时的程序员没考虑到软件会被使用至21世纪,为了节省内存省略掉代表年份的前两位数字”19”,或者默认前两位为”19”。

  “千年虫“千年一遇,可日常关于时间的低级bug经常发生,而且通常等到一段时间后的某个特定时间点才暴露出来,让人防不胜防。

  例如正则只匹配了“16”,“17”年,等到18年零点到来问题才暴露。

  关于时间的bug非常多,大到闰年、夏令时、节假日、时区等,小到时间格式,每年都会碰到不小心遗漏的时间bug,所以很多公司对时间的通用测试用例就有许多条。

  除了时间问题,程序员如果只考虑本次需求或者单个系统时,常常将字段设置不正确,后续业务拓展或者和别的系统交互时发现字段不够用,只能修改字段长度了。

  - 3 -

  不考虑上下游系统,招呼不打便随意改接口

  曾遇到A系统上线后,大伙回归A系统正常运行后,正乐滋滋地松一口气之际,本来好端端运行的B系统突然坏了,B组人排查半天发现,原来是A提供的接口改了,B系统不兼容新接口。

  大概程序员走过最长的路便是背锅之路了。

  2005 年 12 月 8 日瑞穗证券的交易员因手误输入错的股价,2 分钟后这人试图通过交易软件撤销这笔卖单。可是连续输入 3 次撤单指令,都被东证的交易系统拒绝了。这次事故造成400 亿日元的损失。

  后来查明是交易系统出 bug了,程序员在 2000 年某次程序修改时不小心埋进去的。

  所以很多公司会严格要求在程序修改后必须经过严格的回归测试,来验证对其他业务流程有没有影响。

  - 4 -

  复制、粘贴,我闭着眼,有bug看不见,debug了没?

  已发布已验证的代码,是安全可靠的,是可以拿来即用的,无需质疑,不用浪费时间去调试,这是程序员的惯性思维。

  被记入史上bug王之一的阿丽亚娜5型自毁事件就是因代码复用而导致的。1996年6月4日,阿丽亚娜5型运载火箭发射点火后,由于bug,在发射39秒后火箭发生偏轨,最终被迫引爆自毁。

  这件事情发生的原因是因为5型火箭是基于4型火箭开发的,发射系统的代码程序员也直接照搬4型的。

  该段代码在4型火箭中被反复验证,但在5型却没有进行验证。实际上4型的飞行条件和5型的飞行条件截然不同,最终导致事故发生,此次事故损失3.7亿美元。

  有测试工程师说,最害怕开发说这次没啥改动,跟线上某功能差不多。这时候反而要细心验证代码的正确性。

  这是因为“安全心理”作祟:程序员直觉已信任上线的代码是正确的,便直接复制过来用,不会再花时间自测,因为这是“对的”,“毋庸置疑”的。

  此时测试人员不可轻易听信开发的话,更要严谨对待,毕竟程序员的三大谎言有:没问题的;只改了两行代码;和线上一样。

  程序员花30分钟写程序,花2小时改bug。bug,子子孙孙无穷尽也。所以在面对测试人员的质疑时,程序员们一定要保持镇定,该甩锅时速速甩掉:这是历史问题,我没动过;刚刚在我这是好的,你环境配错了;你重启试试……

  最后一招是两个字:我改!