软件开发的围城

2016/04/13 dev

今天看到知乎上一篇有趣的文章《你要避免的软件开发模式》, 的确是非常生动, 不知道你看完后中了几枪呢?

我是全中.

首先是 IDD, 即 IDE 驱动开发, 简直就是我的现状. 虽然我很长一段时间, 坚守节操的使用 Vim 作为我的主力编码工具, 无奈工作环境下, 就是统一用 VS. 工作有年头了, 自然极度熟悉 VS, 快捷键熟练的飞起, 无论是查看代码, 还是理解代码流程, 都觉得无比顺畅. 在这种情况下, 如果非要我改用 shell 下的编辑器, 并非做不到. 但是的确会极度痛苦, 就好比用过了机械键盘, 非要扔一边, 去使用普通键盘一样.

然后是 DDD, 即面向调试器开发. 我一直觉得, 调试器是初学者利器. 一段代码, 把自己看的五荤八素的, 动手调试一番, 几个关键断点一打, 就会快速解决问题, 理解流程. 我曾经在 Linux 下坚持使用 gdb 很长一段时间, 比起 VS, 真的是有很大的差距. 可视化调试器的优势实在太过于明显, 你几乎很轻松的就可以集中注意力去解决关键的问题. 原文里说的很夸张, 什么断点满天飞, 而实际情况下, 断点个数很少超过 5 个. 断在关键地方, 就基本可以找到问题所在了.

PDD, 即面向打印开发. 这个在实际工作中有两种情况会用到:

  1. release 环境的故障, 在 debug 模式下无法复现.
  2. 多线程的代码.

对于第一种, 随着 VS 的不断升级, 远程调试, 可以解决大部分系统环境带来的问题. 另外一些更加诡异的 Bug 就不得不借助 Log 来分析了. 也有一些调整 Release 参数, 以便像 Debug 那样去调试. 但往往也容易掩盖问题.

对于第二种, 则是调试器无法彻底解决的了. 即便是强大如 VS, 对于多线程的调试, 也是比较基本初级的. 多数情况下, 还不如老老实实写好 Log, 来判断问题的原因.

BDD, 则估计是大多数底层开发者的现状. 只要你真正在写软件, 无论是项目, 还是产品, 都会给人用. 一旦有人用, 则会有源源不断的 Bug. 尤其是 C++ 程序员, 一天到晚就是看崩溃原因. 如果你是做 GUI 或 图形图像的, 那么恭喜你中奖了. 你基本会为了一些无比琐碎的问题, 折腾日日夜夜, 不断怀疑人生的价值. 于是就有了原文中对于修补匠的描述. 修补匠好当吗? 老实说, 有多少人会按下葫芦起来瓢, 多少人会拔出萝卜带出泥? 每天的生活就像一个私家侦探, 唯一的乐趣, 就是把握蛛丝马迹, 然后抓出狡猾的凶手. 听起来很有意思对吗? 正如原文所说, 长此以往, 疲于奔命不说, 眼界的确会受到影响.

RDD (老鼠赛跑驱动开发), 就更加躲不开了. 进入公司, 你往往有两种大体方向上的选择:

  1. 认真, 深入研究公司业务, 争取能与业务人员谈笑风生. 然后不断夯实, 熟练这一领域的开发技艺.
  2. 坚守一个”程序员”的操守, 做好开发人员该做的事情, 不过多牵扯业务知识. 留出更多时间, 学习新的语言, 新的开发方法等等.

这两种方案, 我都有亲自实践. 我的第一份工作, 采取的就是第二种方案. 该方案的好处是, 永远让自己不落伍, 换工作的成本相对较低. 但坏处也是很明显的, 首先表现为会因为对业务理解的偏差而经常返工, 其次是工作质量不高, 表现谈不上好, 升职空间相对较低, 另外容易养成流于泛泛的习惯, 变成面向招聘类型的程序员.

目前这份工作, 我采取了第一种方案, 好处是更容易透过表象看本质, 发现本领域内的很多实质性的内涵. 在领域内的知识积累也能促使你更快的成为行业专家. 坏处也是很明显的, 即与领域越绑越紧, 想摆脱越来越难. 找工作会相对更难一些. 思维也容易保守僵化, 往往几年下来, 发现经历平淡, 一成不变.

唉, 五个坑, 一个也没躲过.


平心而论, 作者针对这五种现象的嘲讽, 都十分有道理. 人生不就是这样么, 我们都知道什么是对的, 然而总在不可避免的做着错误的事情. 看评论可以看出 很多人都表示不认同, 我们毕竟生活在残酷的现实社会, 理想化的开发模式与习惯, 虽心向往之, 然往往十动然拒.

团队都用 IDE, 你偏用 Vim, 效率也不比 IDE 高, 这难道不是二愣子行为? 还容易被人误解为装逼.

遇到历史遗留代码, 或较为晦涩的代码, 坚决不调试, 坚持生看. 这行不行? 当然可以, 这绝对比调试更锻炼自己. 但这很费脑子, 你能在 8 小时内让大脑无比清醒多久? 在产品经理当面催促, 同事翘首以盼之际, 你能有多好的心理素质, 慢悠悠的生看代码逻辑? 不用说, 粗略的判断问题所在, 然后打上断点动手调试一把, 比什么都实在. 一步一步, 井然有序, 也易于缓解压力, 更不需要脑袋有太多负担, 何乐而不为?

同样的, 测试那边扔过来一个 release, 在他们机器上死活打不开. 你怎么办? 平时认认真真写的 Log 根本连开头都没进入. 能解决问题不? 还是得临时 print 几句, 看看到底问题出在哪. 假如不幸遇到 Dll 灾难, 或是库编译偏差, 不这么做很有可能让你一天都理不出个头绪.

你在开发一个规模庞大的软件, 用户在某个窗口, 某个画布上看到一只”虫”, 给你发了一条 BUG 记录. 然后他把”虫”拍死, 接着, 软件崩溃退出. 他用一天, 可以发现十几条这样的问题. 你的邮箱忙碌的接收着这些问题记录. 你会怎么办?

  1. 妈呀, 这软件也太烂了, 问题太多, 没法维护了, 告诉领导, 我全部推倒重来. 然后吭哧吭哧几个月过去了, 全部重构的软件, 又被用户挑出各种问题… 如此往复… 没法交差, 卷铺盖走人, 深藏功与名.
  2. 这不是我的问题啊, 发给我干嘛, 都怪同事水平太差, 影响了我的模块. 看, 这是底层设计不好. 呀! 这实现就是坨屎啊. 然后和同事撕逼, 将同事 C 风格的代码, 改成了 C++. 问题还在那… 没法交差, 教育同事几句, 顺便推广一下 C++ 14, 不了了之.
  3. 一个问题接一个问题的跟踪, 破案, 揪出幕后的真凶. 累的老眼昏花, 还往往心有余悸. 长长的 Bug 列表就如一个个谋杀案现场, 区别是侦探可以跟嫌疑人说说话, 聊聊天. 你只能安静的看着满屏幕的代码.好不容易长舒一口气, 今天破案到此为止. 看到知乎这篇文章, 吐血三升而亡.

你有没有中枪呢?

你是一名追求卓越的前端工程师, 早在 Java Web 泛滥成灾的年代, 就听从学长建议, 苦学 YUI. 好不容易颤颤巍巍搭建起自己的页面风格. 走上工作岗位, ExtJS 大行其道, 似乎有无数个企业管理系统等待你去拯救. 于是你紧跟潮流, 学习华丽的 ExtJS. 迅速接了几个项目, 忽悠客户. 这边客户还没买账, 前端界突然风起云涌, Node.js 横空出世, 你毫不犹豫的扑向了新的知识. 做了几个 Hello world 才发现, 这玩意虽然有个 js的后缀, 但跟前端的关系不大. 而此刻又有各类权威发话, “我们不仅仅有眼前的前端, 还有全栈和远方!”. 还在苦苦犹豫是否要恶补后端知识的时候, 几个大巨头又向前端发起了攻击, Angular.js, React.js, 你连忙放下之前宏伟的计划, 还是牢牢抓住前端这个饭碗实在. 开始苦学各种高端大气的前端框架. 无奈这个潮流挡都挡不住, 时尚的 vue.js 怎么玩? …. 疲于奔命的你, 终于站在了潮流的最前端. 手中紧握着劝退前最后一笔工资…

更新自己技能树的同时, 有没有夯实赖以生存的领域知识呢? 有没有沉下心分析一下技术革新背后, 本质的东西呢? 甚至, 有没有真正动手做过几个系统, 不辜负”专家”的 Title 呢?


上述都是无比真实的血泪史. 软件开发也像一个围城.

新手渴望成为老手, 憧憬着书本上描述的那种开发模式. (如原文作者描述的那样, 五个坑, 我一个也不入.) , 冲进城去, 发现老手都是真刀真枪的干, 即血腥又简单, 粗暴的实用. 等到自己慢慢也成了老手, 长枪顺手, 随便就能捅人几个窟窿的时候. 又渴望文明的生活, 做一些更”对”的事情. (如原文作者描述的那样, 五个坑, 我一个也不入) .

你在哪一个城? 城里还是城外呢?

姓名*:

电邮*:

网址(可选):

评论*:

Search

    Table of Contents