一颗与书碰撞的心 ——读《人月神话》有感

       新一周的读书自然有新体验，每每捧起一本书的时候，自己都会有不同的认知与感想，回想自己原先的念头，也不禁会产生“我当时为什么会这么想？”的念头，有时候这个念头让现在读书的我也不禁有一丝佩服，但也时候自己会质疑自己为啥当时会产生这么蠢的念头，一切的一切都是由于自己对于这个世界的认识又有了不同的想法，毕竟自己已经不是过去的自己了，人都是在进步，也许当时看书啥也没看懂的地方在现在来说就是小菜一碟，经历多了自然认识也就变广了，自然在读书的时候便会有更加深厚的认同感与思索。

      “片刻等待，更多美味，更多享受”，这句话很生动，也很容易明白，但真正蕴含的意义对于编程而言又是如何。我发现我读的两本书中都有作者去使用其他领域里的深刻含义的道理在编程中来进行讲道理，在我看来编程之所以可以用上哪些大道理，是因为它太基础了，它仿佛是一个创造世界的粒子甚至是元素，一切一切的基础都来源与最基本的代码，这个工作本来就是在一个新世界里创造一个新事物，甚至可以说是创造一个新世界，这么看来一切的大道理似乎都可以使用在编程里面。

      书中介绍有关项目的滞后原因，这个是我现在可以说是最需要也是最无知的地方，当我真正开始了书里所说的项目后才会发现一切都不是自己所想的那么简单。一开始时的时候自己就是信心满满的开始进行，但却发现自己一次又一次的将自己的任务滞后，本来打算一周完成的任务到了现在才进行了一半，而且还有一大堆问题出现甚至是涉及到了需要更换框架，自己就彻底不在小觑这个任务了。看书才知道自己这个原因可能是一个主要嫌疑人——缺乏合理的时间进度，回想一下确实如此，毕竟一开始接触的时候是一窍不通，需要自己有时间去学习，但是到了真正的的时候却被一堆烦事给缠住了脚，也就是自己本来预计的时间就在满满的减少，而自己的工作却没有因为时间的减少而增加。

       这也就是我接下来想说的，导致缺乏合理的时间进度这种普遍灾难性的原因是什么呢？书中列举了五条，条条深入人心，第一对估算技术缺乏有效的研究；第二错误地将进度与工作量混淆；第三由于对自己额估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作；第四对进度缺少跟踪和监督；第五当意识到进度的偏移时，下意识的反应是增加人力。自己看到这五条的时候顿时发现自己竟然满足了两条，分别是第一条、第二条，这两条都可以在自己的身上看出一丝苗头，首先是第一条，自己对于估算的研究可以说是很缺少的，只是大致了解它是干啥的，对于具体的操作自己却不是特别的熟练，以至于自己不能把自己的工作的时间进度有效的估算出，导致了自己将一些时间不必要的浪费了，尤其就是第二条，自己没有将进度与工作量分开，一开始就觉得自己的工作量越大自己是不是就是进度特别快，现在一看倒是自己进入了一个死胡同里，细细一想确有道理，自认为自己做好了自己的一部分前段工作，但是最后才发祥自己做的这些工作并没有起到一个让大家认可的程度，导致了自己需要换框架的尴尬，也就是说自己的进度恐怕才刚刚开始，也就是说自己原先编的近一千行代码，在进度上也就是在项目的完成度上占比很低，要不是组长说自己编的还有用，自己恐怕都会怀疑人生了。

       要说我乐观，我其实就是挺乐观的，看了这本书，才明白乐观也不是一件太让一个编程人员喜欢的事。具体原因书中所讲很有道理，计算机编程基于十分容易掌握的介质，我们可以通过非常纯粹的思维活动也就是思维概念的形式来开发程序，正是由于介质的易于驾驭，我们便会在实现的过程中期待不会碰到困难，这就是造成乐观主义的一个原因，之所以我们的乐观并不让一些人接受就是在于我们的构是有缺陷的，因此总会有bug，也就是说我们会遇到我们从未想过的困难。这个对于我来说就像是“量身定做”一般，一开始自己接触一些语言，心中便会有“这语言挺好懂的”、“我这样做就能很容易的实现自己的想法”……但是当自己真正上手的时候才会发现自己当时想的会出现一些从未想过的bug，就拿我最近学的汇编语言来说，自己明白它的一些原理，就用自己的一些想法去实现，但是却发现最后要不是程序崩溃就是运行错误，自己原本的乐观也就带给了自己无尽的调试痛苦。

       生活不愧是我们的最好的老师，一次或者两次深刻的教训便会教会我们看数本书都无法让我们记住的东西，自然融会贯通方为读书的一条大道。