普通程序员走向“专业”的灯塔
2012-11-11
看完此书第一个感觉就是：大叔也是跌跌撞撞一路走来，什么时候才能成为大叔这种级别的高手呢！
两周前拿到这本书，在地铁、程序编译间隙把书看完了。“编译间隙”，正如作者在“练习”一章的注里讲的“这是悲剧”，事实上我们可以等待很少的时间或者不需要等待，只要足够仔细，我知道等待程序编译不好，但是却没能去修改。我们的程序每次更新代码都必须重新编译链接，否则就会出现莫名其妙的错误，而我们使用的机器又很老旧。没有人知道怎么修改工程，公司没给我们配备够用的机器，我也没掏钱去买机器。知易行难。
第一章的简述，基本把后面的内容都总结了一遍，看看目录，再看看第一章就能有不少收获了。
书写得很通俗，关于非技术层面的职业素养，很多地方能产生共鸣，看到这些地方是对自己的一次次鼓励。这里边很多知识点其它书籍也有涉及。
关于拒绝。很多非技术性书籍都提到这点，之前也在博客上看到些深刻分析的好文章（如：http://blog.liancheng.info/denial-of-service/#.UJ8vJW9ENIF）。现在又从作者这里看到一次完整的剖析，以我的经验来看，作者也许有点过于理想化了。如果遇上的是一个没有团队精神的leader，或者leader能力不济，那么说“不”可能导致受排挤。如果自身能力不足，不能做好评估，那么不会有说“不”的底气，更多的是“试试看”。更多的时候是如书中所说的，业务人员（更多的时候是leader）向客户（更多的时候是leader的leader）承诺某某天要完成某某产品，然后压着底层技术人员拼命的加班，这是很无奈又很普遍的事情，这是国情所致吧。一周工作40小时，自己学习20小时，这是很理想的境界，能做到的恐怕不多，特别是那些写代码的程序员。作者以他的经历，告诉了我什么是对的，什么是不对的，但我也仅能做到知道而已。一天能纯粹干活8小时吗？一周能上班5天吗？能每天学习3小时吗？专业人士能做到，现在我还不专业。
关于承诺。拒绝跟承诺是相对应的，拒绝就是为了坚守承诺，不懂拒绝的人慢慢的就会沦为不守承诺的人，当然也有可能他从来就不曾把信守承诺当回事，这些年的计算机大热，让不少非专业人士也混进来了。跟拒绝一样，专业人士能做到。我现在做不到，尝试过这么做，但实际上行不通。他们会要求你2天干完3天的活，假如你不敢说“是”，那么这工作就没你份了，他们会寻找说“是”的人干活，结果说“是”的人3天或者更长的时间才干完，这不重要，因为他们已经习惯了延期。有些书籍里批评了这种先应承下来，然后再延期完成的做法，但很不幸这是生存之道。作者的文字，立了标杆，我一直都是在向专业人士靠近，Yeah！什么时候才能勇敢的说“是”和“不”呢？在一个信守承诺的环境下，足够专业的时间评估，有足够的团队精神的团体。
关于编程。最让我感到诧异的是，居然要避免进入流态区，我之前可是感觉良好，有时候写到凌晨，感觉干了很多活。当然也冒出了很多错误，但我以为这是熬夜写代码导致的错误。熬夜写代码是很不好的事情，但是像我这样的小码农避免需要更大的勇气。看到关于“冲刺”、“加班加点”部分的时候，会感慨那些程序员真幸福。我们还处在作者一周干70、80小时的那个时代。
关于测试驱动开发。看起来真是个好方法，我也能体会到，但没在项目中实践过。现在看到烂代码，都不敢动了，没有“防坠网”，重构是很危险的事情，就我了解的情况，没防坠网的重构都失败了，当然，他们不会认为这就是失败，他们会认为重构后出现的退化是正常的情况。最近遇到了没文档的代码，需要自己调试验证某些功能的输入输出参数，很自然的写了测试代码，而这些测试代码又很自然的可以当作使用说明文档，如果最初写代码的人有重视测试，那么这些完全可以当作文档留下来，后来者也就不用花时间了，节约公司成本。
关于练习。回想我短暂的程序员日子，练习做的太少，每次都是需要才去学，用完就丢，缺少积累。程序员应该像运动员一样，日复一日的练习，才能成为专家。
关于完成。这是一个可以大力吐槽的话题。非专业的程序员会让QA代替自测，非专业的程序员会把截止日期当作功能完成，听起来很惊讶，但这是真的，背后可能有各种各样的原因，可能是程序员太嫩，可能是排期太不合理，但理由不重要，专业的程序员首先必须是负责任的。我的目标正如作者所说，测试人员应该一个bug也找不出来。这要做到很有难度，你需要清楚的知道这是在做什么，遇到不聪明的业务人员，要不断的咨询，他们到底要什么，有时候还得跟测试人员解释，这就是他们想要的，它不是bug。零bug程序是一个标杆。
关于时间管理。番茄工作法是个不错的方法，在不少书籍上看到这建议。拒绝不必要的会议，之前也在一些地方看到过。最怕的是遇到寻求存在感的leader，在会议上帮你浪费时间，而不是帮你节省时间。
关于工作预估。这是个很难的工作，首先必须清楚的知道你的能力，工作的难度，如果一头雾水，那一切方法都没用。预估时间时，千万不要以为周六日、晚上可以加班完成，很少有人能做到7*12一如既往高效率的工作，如果你算上了，那是准备让别人说你不守承诺。
关于压力。在压力下坚守规律，专业人士的方向。在工期压力下，能写漂亮代码吗？能不熬夜吗？能不加班吗？不能，那么工期为什么会有压力？有时候，问题本身就不该存在。
关于程序员的培养。程序员职业也应该像其它成熟工种一样平凡，但现实不是这样子的，即便是作者所在的国度也不是。我们这儿很多人才刚会写代码，还属于很普通的熟练工，就开始不写代码做管理工作了，然后刚毕业的小朋友都不用培训就直接上岗大干，所以我们的情况是——从来就没有大师，是我们不把编程当作职业，而只是临时工种。从学徒走到现在（大概可以算作初初级熟练工），有些自生自灭的痛苦，作者的理想世界真的不错，很多时候我太急躁了。
这本不厚的书，给了普通程序员走向“专业”的灯塔。知易行难，“专业”的路上总有各种各样的拦路虎，也许我会再走作者标明了的错路，我也并不孤单，但心里知道这是错误的，不要走远。每看到这种书，低沉的士气会再次振奋。
看完此书第一个感觉就是：大叔也是跌跌撞撞一路走来，什么时候才能成为大叔这种级别的高手呢！
两周前拿到这本书，在地铁、程序编译间隙把书看完了。“编译间隙”，正如作者在“练习”一章的注里讲的“这是悲剧”，事实上我们可以等待很少的时间或者不需要等待，只要足够仔细，我知道等待程序编译不好，但是却没能去修改。我们的程序每次更新代码都必须重新编译链接，否则就会出现莫名其妙的错误，而我们使用的机器又很老旧。没有人知道怎么修改工程，公司没给我们配备够用的机器，我也没掏钱去买机器。知易行难。
第一章的简述，基本把后面的内容都总结了一遍，看看目录，再看看第一章就能有不少收获了。
书写得很通俗，关于非技术层面的职业素养，很多地方能产生共鸣，看到这些地方是对自己的一次次鼓励。这里边很多知识点其它书籍也有涉及。
关于拒绝。很多非技术性书籍都提到这点，之前也在博客上看到些深刻分析的好文章（如：http://blog.liancheng.info/denial-of-service/#.UJ8vJW9ENIF）。现在又从作者这里看到一次完整的剖析，以我的经验来看，作者也许有点过于理想化了。如果遇上的是一个没有团队精神的leader，或者leader能力不济，那么说“不”可能导致受排挤。如果自身能力不足，不能做好评估，那么不会有说“不”的底气，更多的是“试试看”。更多的时候是如书中所说的，业务人员（更多的时候是leader）向客户（更多的时候是leader的leader）承诺某某天要完成某某产品，然后压着底层技术人员拼命的加班，这是很无奈又很普遍的事情，这是国情所致吧。一周工作40小时，自己学习20小时，这是很理想的境界，能做到的恐怕不多，特别是那些写代码的程序员。作者以他的经历，告诉了我什么是对的，什么是不对的，但我也仅能做到知道而已。一天能纯粹干活8小时吗？一周能上班5天吗？能每天学习3小时吗？专业人士能做到，现在我还不专业。
关于承诺。拒绝跟承诺是相对应的，拒绝就是为了坚守承诺，不懂拒绝的人慢慢的就会沦为不守承诺的人，当然也有可能他从来就不曾把信守承诺当回事，这些年的计算机大热，让不少非专业人士也混进来了。跟拒绝一样，专业人士能做到。我现在做不到，尝试过这么做，但实际上行不通。他们会要求你2天干完3天的活，假如你不敢说“是”，那么这工作就没你份了，他们会寻找说“是”的人干活，结果说“是”的人3天或者更长的时间才干完，这不重要，因为他们已经习惯了延期。有些书籍里批评了这种先应承下来，然后再延期完成的做法，但很不幸这是生存之道。作者的文字，立了标杆，我一直都是在向专业人士靠近，Yeah！什么时候才能勇敢的说“是”和“不”呢？在一个信守承诺的环境下，足够专业的时间评估，有足够的团队精神的团体。
关于编程。最让我感到诧异的是，居然要避免进入流态区，我之前可是感觉良好，有时候写到凌晨，感觉干了很多活。当然也冒出了很多错误，但我以为这是熬夜写代码导致的错误。熬夜写代码是很不好的事情，但是像我这样的小码农避免需要更大的勇气。看到关于“冲刺”、“加班加点”部分的时候，会感慨那些程序员真幸福。我们还处在作者一周干70、80小时的那个时代。
关于测试驱动开发。看起来真是个好方法，我也能体会到，但没在项目中实践过。现在看到烂代码，都不敢动了，没有“防坠网”，重构是很危险的事情，就我了解的情况，没防坠网的重构都失败了，当然，他们不会认为这就是失败，他们会认为重构后出现的退化是正常的情况。最近遇到了没文档的代码，需要自己调试验证某些功能的输入输出参数，很自然的写了测试代码，而这些测试代码又很自然的可以当作使用说明文档，如果最初写代码的人有重视测试，那么这些完全可以当作文档留下来，后来者也就不用花时间了，节约公司成本。
关于练习。回想我短暂的程序员日子，练习做的太少，每次都是需要才去学，用完就丢，缺少积累。程序员应该像运动员一样，日复一日的练习，才能成为专家。
关于完成。这是一个可以大力吐槽的话题。非专业的程序员会让QA代替自测，非专业的程序员会把截止日期当作功能完成，听起来很惊讶，但这是真的，背后可能有各种各样的原因，可能是程序员太嫩，可能是排期太不合理，但理由不重要，专业的程序员首先必须是负责任的。我的目标正如作者所说，测试人员应该一个bug也找不出来。这要做到很有难度，你需要清楚的知道这是在做什么，遇到不聪明的业务人员，要不断的咨询，他们到底要什么，有时候还得跟测试人员解释，这就是他们想要的，它不是bug。零bug程序是一个标杆。
关于时间管理。番茄工作法是个不错的方法，在不少书籍上看到这建议。拒绝不必要的会议，之前也在一些地方看到过。最怕的是遇到寻求存在感的leader，在会议上帮你浪费时间，而不是帮你节省时间。
关于工作预估。这是个很难的工作，首先必须清楚的知道你的能力，工作的难度，如果一头雾水，那一切方法都没用。预估时间时，千万不要以为周六日、晚上可以加班完成，很少有人能做到7*12一如既往高效率的工作，如果你算上了，那是准备让别人说你不守承诺。
关于压力。在压力下坚守规律，专业人士的方向。在工期压力下，能写漂亮代码吗？能不熬夜吗？能不加班吗？不能，那么工期为什么会有压力？有时候，问题本身就不该存在。
关于程序员的培养。程序员职业也应该像其它成熟工种一样平凡，但现实不是这样子的，即便是作者所在的国度也不是。我们这儿很多人才刚会写代码，还属于很普通的熟练工，就开始不写代码做管理工作了，然后刚毕业的小朋友都不用培训就直接上岗大干，所以我们的情况是——从来就没有大师，是我们不把编程当作职业，而只是临时工种。从学徒走到现在（大概可以算作初初级熟练工），有些自生自灭的痛苦，作者的理想世界真的不错，很多时候我太急躁了。
这本不厚的书，给了普通程序员走向“专业”的灯塔。知易行难，“专业”的路上总有各种各样的拦路虎，也许我会再走作者标明了的错路，我也并不孤单，但心里知道这是错误的，不要走远。每看到这种书，低沉的士气会再次振奋。
有关键情节透露
