软工之路:初学者

今年只写了一篇博客, 为免那一篇太过孤单, 凑一篇新的.本文以玄学为主, 实践为辅; 只可忽悠, 不可戳破. 系统的软工方法及实践请参考现代软件工程.

准备

实践软工,至少需要以下基础:

• 书籍类

  • 设计模式.

  应付面试和应付上面搭个蹩脚笨重仅内部使用的框架, 可参考Head First系列的那本深入浅出设计模式.这本书可以让你快速了解设计模式的实现,并不假思索的写出标准的 context 和 Inheritance diagram.
  认真学习设计模式可以参考Gof的那本设计模式.这本书的精华并不在于那些 context 和 Inheritance diagram, 在于你可能读几天才能明白一丁点的解释文字.
  我对 context 和 Inheritance diagram 不太关注. 这样的东西之于设计模式, 就如同辟邪剑法的招式之于辟邪剑法. 辟邪剑法的招式, 让林家如何委曲求全也不免灭门之祸; 心法却可以让一观主两掌门两教主抢来抢去.

  • 重构类

  主要大概就是 martin fowler 那本重构.大学的时候买过一本,看过一遍,属于值得一看的好书.

  • 杂烩类

  被无数码农装作看过的代码大全 真的值得一看.
  因为某些缘故(没妹子送我这本书), 大学的时候只看了一部分. 到了研一的时候, 才借着小组免费图书的机会给看完了. 现在想想, 如果还有机会的话, 我应该会再看一遍的.

• 代码

  • 量

  至少有 10K 级别以上的非hello world / CRUD 之类的代码. 有 100K 左右会更好.
  不需要全部都是 release 代码, 这样要求太高了, 毕竟一个中级的 SE 一年能有 10K 的release代码就算很高产了.

  • 质

  至少会使用两种以上的语言做过实际东西. 只会一种语言, 这个语言的丑陋和缺陷会让你坐井观天.
  两种以上的语言做过实际东西. 不包括 c 和 Java. 因为很少有人(至少我不知道有谁, 呵呵)精通 c / 精通 Java 而不会其他语言. 如果你是用过 c / Java做过实际东西, 但是只会 c / Java, 你应该就是水货程序员没跑了. 如果年纪大了, 转行做XX经理可能是你的唯一出路. 总之就是程序员这条路不适合你, 当然你可以比程序员很有钱, 这不矛盾.

• 数据结构和算法

  • 数据结构

  我见过很多不懂数据结构的在那里写工程代码. 结果自然是呵呵的. 就像不知道砖是啥样的, 就要盖个高楼大厦, 结果往往是塌死了自己(活该)和队友(真倒霉), 就算没塌死, 也都伤的不轻.
  - 算法
  > 算法本来应该是工程的另一极. 不过目前太多人什么算法基础都没有, 就工程去了.唉, 初中辍学就去工地搬砖的能有多大出息(对于大部分普通人来说)？至少要上个高中或者大学啊.
  没错, 算法就是工程中的高中或者大学.
  > 最初可能看起来没啥用, 都一样是搬砖的. 但是很快你就知道工头制定的搬砖规则, 哪些是真正的为了工程安全, 哪些是工头不了解, 不知道有捷径. 知道这些, 你的砖才会搬的越快越好.
  > 算法要求不高, 按部就班学习大学的课程, 虽不能秒题但是能解题就行了. 目前情况是, 这个要求太高了.

实践

以正合,以奇胜.软工的一切规则都是奇,尽量忘掉那些华而不实的东西.老老实实写bug free code.写完之后若需修改, 再开始用那些奇门八阵来美化代码.

• coding

  • 写

  有啥说的, 不写谁给吃饭钱.杜甫有诗"朱门清闲愁,路有coding狗", 李绅有诗"四季无闲日,码农犹饿死."
  以上就是码农真实写照.

  • 改

  很多初级码农都会卡在这个坎.因为实在是——老子不想改啊.
  但是产品的主观需求 / 测试的客观BUG 是不会因为因为码农的主观不想改而改变的. 尽量满足他们无理的需求吧. 毕竟, 只有黑暗可以通向黎明呢.虽然也有大部分死亡在了这黑暗中.
  程序员之路,注定是一条黑暗之路呢——泥泞于黑暗, 不见真心, 产品/测试, 受死吧.(语出忍者)

  • 重构

  这是一个很难跨过的坎.因为我不想天天重构, 更不想天天重构不属于自己的代码.
  不过前几天有一些20年码龄的码农教育我, 重构就像吃饭刷牙洗澡睡觉一样, 应该是每天都要做的事情. 我想了想, 也就认命了.

• comments

  • 要不要?

  呵呵, 代码就是让人读的, 只不过恰好可以让机器编译运行罢了.
  自注释的代码往往都是教科书式, 实际中一点实际价值都没有. 你要真相信了自注释代码, 你为何不相信彩票呢？那个来钱更快.
  假如是我，仅仅是
  我的悲剧——
  我也许已经宽恕
  我的泪水和愤怒
  也许可以平息
  但是，为了孩子们的父亲
  为了父亲们的孩子
  为了各地纪念碑下
  那无声的责问不再使人颤栗
  为了一度露宿街头的画面
  不再使我们的眼睛无处躲避
  为了百年后天真的孩子
  不用对我们留下的历史猜谜
  为了祖国的这份空白
  为了民族的这段崎岖
  为了天空的纯洁

  和道路的正直  
  我要求真理！  
  

  • 怎么写？

  英语不好用汉语写.
  汉语不好请投胎或者告诉我是哪个HR招你进来的, 我去砍它.初级产品汉语好不好就无所谓了,反正他们什么都不好.
  魔法数请注释; 随便起名的函数请注释; 涉及算法的代码段请注释; 但不要随便阿猫阿狗都注释了, 那样就陷入了Java的随便分层随便解耦的地狱了(却不知解耦的 前提是内聚).我们需要的是注释, 而不是可能掩藏着注释的——大——数——据.
  上周日的时候, sublime text出问题了. 记事本也可以写代码, 也可以写注释, 还可以写伪代码.实际上上周日加班, 我就是写了写注释和伪代码, 代码是周一才写的. 如果你注释和伪代码不能在代码之前写好, 可能你都不知道如何写这段代码.所以, 还是先想一想吧.
  有通用简写就用通用简写, 毕竟英语不好写错了, 别人看着多难受; 我真的是受害者.

• document

  • 不是都有注释了么?

  我可懒得在垃圾代码的垃圾堆里面翻那么一丁点注释当文档.
  API速查文档对于搭积木来说十分重要, 新手分分钟上手干活. 如果公司请过来一个新人, 要3个月才上手, 算上离职交接的一个月, 就是损失了4人月. 如果一个月就上手, 只是损失2人月. 这点工资可能很多公司不在乎——反正就当报效祖国嘛; 这点时间价值, 呵呵, 不会有哪个公司不明白有多重要.
  2人月我能自己写个简单手游包括前后端出来了好不好！

  • 怎么写?

  最理想的情况当然是更新代码的时候就更新注释, 然后用doxgen之类的工具生成API 文档.
  稍微不乐观的情况呢?自己手动写, 累死一个开发是一个, 赶走一个开发是一个.反正公司, 本来就是要流动的.

  • 怎么保存？

  不要用doc, 请使用可在线浏览的合适的纯文本语言(供diff).
  如果你实在想用doc, 请想想自己能不能花10K 月薪招个啥都不会的, 就在SVN那里管理doc 文档, 保证只有一份 可靠doc 存在. 如果不能, 就不要学华为了.

吐槽

注释和文档, 是很多运气好一些的小公司变身中型公司的时候, 很容易忽略的地方. 因为当他们变身中型公司的时候, 想的更多是跑马圈地, 而不是扎实根基. 历史也一次又一次的证明了, 这样的小公司死的也会很快. 毕竟, 有运气能成为公孙述袁绍袁术陈友谅等人的太多, 但是除了运气还有实力的刘秀曹操朱元璋就太少了.