《程序员修炼之道:从小工到专家》1
在真正接触《程序员修炼之道:从小工到专家》这本书之前,我还以为它胡是一本厚重无趣、晦涩难懂的一本书(就像普遍印象中的乏味的教科书那样),以至于我对它相当抵触,相关的读后感都压在月底解决。但是当我真正开始看这本书的时候我才发现我队它的理解是多么错误。
“我的代码被猫吃了”,很有趣的一个比喻。猫会吃代码吗?不会。那为什么会这么说?因为程序除了问题,而“我”在推卸责任。
其实从小到大,我们接受到的教育都是“诚实善良、勇于担当”,但是能从小到大都坚持下来的实在是太少。我们有时候是不想承认错误的,因为承认错误往往意味着承担责任。但是人非圣贤,大抵没有人会不犯错吧?同样的道理,我们也无法保证我们的代码就一定的没有问题的。尤其的处在团队中的时候,我们不需要称道其所有的错误,但是却不可以逃避自己的责任。
做不到的事情试着尽己所能,把思路从“我不会”转变为“这样做也许有可能挽回局势”。
宇宙万物均遵循熵增定律,软件开发或许不受其他影响,却也无法逃脱熵增的魔爪。试想一下,在轮流抄写文章的时候,如果前面的小组成员都抄写的非常乱,你会怎么样?如果文章都抄写得非常整齐呢?我猜,在前面非常乱的情况下,我们会萌生一种“随便抄抄就行了”的感觉;而如果他们写得非常整齐,就算个人能力达不到我们也会尽己所能书写最好。
同样的道理在软件开发方面一样适用。保证规范的书写格式、命名格式不仅可以让自己看起来更加专业,还有助于抵抗软件开发界的熵增定律。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通