程序员必须学会接受的7个残酷真相_数据

残酷的开发真相No. 1: 编程就是if-then-else语句的运用

编程语言设计者讨论、抽象化思考等等作为,其实都只是在旧的if-then-else语句上重新包装一下而已。

这也几乎就是硬件所有的功能了。是的,通过操作码我们可以顺利地移动数据输入和输出作运算和存储,其余的则在比较的基础上进行分支或者不分支。

而致力于人工智能的同志们更是为这些if-then-else语句包裹上了一件件神秘的外衣,通过这些语句,机器会按照我们的吩咐自动从一些数字矩阵中执行计算,查找搜索直到发现目标。

残酷的开发真相No. 2: 互联网其实就是存储在表中的数据

在过去20年间,“互联网”这个词造就了神话般的财富、搭建了五湖四海的友谊、生产出更为便宜的产品、促成了更为快捷的沟通等等等等,除了治疗癌症,它几乎就是无所不能。但是,说到底,互联网的本质就是一堆存储在表中的数据罢了。

Match.com?就是列满头发颜色、宗教信仰和兴趣爱好的表格而已。ebay?就是一张记录一笔笔合同的交易表。博客?就是一张每一行每一列写下你天马行空胡言乱语的数据表。无论我们怎么给它起名字,它的本质还是数据表格。

这一点也可以从编程语言中看出来。例如Ruby on Rails——当前操作web最为流行的编程语言之一,其实就是在数据库中搞一个小天地:指定一个全局变量,Rails就会自动创建一个列,因为它的作用就是在数据库中建立表格。

残酷的开发真相No. 3: 用户有自己的想法

偶尔用户会变得理智和通情达理,但是大多数情况下,他们都是古怪且难以琢磨的——甚至是非常苛刻的。程序员根本想不到这些用户在看到产品时会出来哪些天马行空的想法。因为用户不是程序员,不会照着程序员的想法走。

程序员必须学会接受的7个残酷真相_数据_02

残酷的开发真相No. 4: 你写的大部分代码将永远不会被使用

这一点就不再多说了,说多了都是泪啊!

残酷的开发真相No. 5: 需求变更是必然的

有一位经理告诉我他的秘诀就微笑着和他的团队说他们很棒,他很欣赏他们做的一切,然后在临出门之间,他会说,“对了,还有一件事……”。就是这件事往往会颠覆整个项目,让每个人都重新回到设计app的起点。

需求变更是项目结构的直接后果。管理人员会在事情开展之前做好所有的规划工作,制定目标。但是一旦事情交给开发人员,那管理人员就轻松了,然后开始无所事事了,成天胡思乱想吹毛求疵。这个按钮放的地方对吗?登录页面是不是应该改一改?反正一点点细微的想法就让开发人员去做修改。

这在项目过程中频繁发生,而且由来已久。要知道,就算是Ada Lovelace的分析机——被誉为第一段计算机程序,也有着需求变更的问题,源于将近一年的笔记讨论中。

残酷的开发真相No. 6: 没有人理解你,特别是你的老板

我们可以将程序员分成两种:第一种的老板是不会编程的,也不知道为了使代码能成功编译需要付出多大的努力;还有一种的老板以前也是程序员但是现在已经忘记了代码编译过程的艰辛。

第一种老板显然永远也不会理解你以及你的工作。不过这也是可以理解的,毕竟所学不同,术业有专攻。

而第二种老板,我们也可以理解。举个例子吧,即使是最好的程序员,如果一两个月不用API也会忘记这方面的内容。再则他们以前学的主流编程语言很有可能和现在的大不相同。

还有一点,如果你的老板自己知道如何解决问题的话,他往往会选择自己熬夜解决它而不是费时费力地雇用其他程序员来解决。所以我们得感谢这些“不懂写代码”的老板。

残酷的开发真相No. 7: 关于隐私,痛苦的纠结

我们都希望我们的服务可以保护我们的用户和他们的信息。但是同时,我们也希望网页简单且易于操作。点击深度——达到目标所需要的点击次数——尽可能的少。

然而保护用户的隐私就意味着,在用户点入页面之前得询问用户一些问题,以确定用户已经知道这样做可能带来的后果。隐私也意味着责任。如果用户不希望服务器知道发生了什么事情,那么用户就得自我承担责任,因为这样做会导致服务器不能够读取用户的资料。责任就意味着麻烦,从这个层面上说,隐私也是个麻烦。

隐私也意味着矛盾的逻辑思维。一边希望能一个人呆着,另一边希望知道大量的信息;一边渴望安安静静毫无纷争,另一边则希望什么邀请函、购物优惠券、工作面试机会等等有多少来多少。