知乎上一直推荐《代码大全》这本书，以前一直以为是装x者的专利，今天在图书馆无意中看到这本书，醍醐灌顶。
这本书将的的确很好，尤其是对于软件开发的隐喻，其中对于隐喻的论述并不局限于软件开发本身，让我认识到隐喻是一种高明的表达技巧，是一种帮我们发现问题的工具，是帮助我们探索未知的路径。隐喻不是算法，更像是探索，在摸索中找到未知的路。
关于人格的论述
这本书果然全面，提到了一个合格的优秀的软件开发人员所应该具有的种种素质，像诚实啊、高级的懒惰啊、拒绝不合理的要求啊等等，也指出了像坚持这种品质其实不一定总是好事，告诉我们如何合理的预估工期，如何合理的选择而工作等等。书中提到的这些品质不仅仅对于软件开发，对于我们日常学习和工作生活也有很大的指导意义。比如，我们要诚实，知之为知之，不知为不知，是知也。再就是提到了一个女员工总是写怪异的复杂的但是不容易维护的代码，虽然为直属上司不喜欢，但是boss喜欢，因为她总能很快的搞定错误，以为她很高明，实际上这些错误是因为他不注重设计造成的。
关于规划的重要性
书中一再论述了规划，搞清楚需求的重要性，提到了如何尽量避免重构，在软件建构过程中，通过哪些策略可以避免错误，不同行业的软件都有什么特点和要求。
并且举了很多IBM，美国国防部的例子来佐证自己的观点。提到了美国国防部项目初期进行设计还需求调研的时候，官员要求必须立即开始写代码，是如何应对的。如何应对不理解设计和需求调研重要性的人。
大部分时间用来思考
强调了，软件建构更多的时候是和人打交道，明确软件的输入输出需求和功能，可以避免很多错误，及时的和相关人员沟通进度，避免出现方向性偏差，一定不要谎报进度。实际上，对于一个软件，和相关人员进行沟通的过程中可以帮助你想清楚很多问题，我们不仅仅是和计算机打交道的怪人。程序的目的是为了更好的解决问题。
关于好的程序
好的程序可以定义好的流程，减少人犯错的机会。提高追溯机制和保障，提供容错机制和错误检测机制。这就是之前有大神说的软件并不是仅仅实现了功能，还要实现非主要的但是十分必要的功能。错误的设计如果很晚才回发现，可能在最后的时候给你沉重的打击，比如我的报名系统，因为糟糕的设计最后捅了篓子。这是很郁闷的事情。
报名系统
报名系统，简单的说，其实就是增删改查，一个有经验的程序员可以能都不用一上午就搞定了，可是这涉及到到了报名，报名确认 ，打印准考证，信息确认表，笔试成绩查询，综合成绩查询，通知书查询功能。中间各种进度的数据呈现，状态的确认呢，时间戳的记录等等。
我是一名程序设计人员，我设计的软件应该所有人都可以适用的，而不仅仅是我自己可以使用，设计的软件应该尽可能的傻瓜化，比如我应该让软件实现截止日期的设定，环节是否开启的设定，分数线的设定，不设置相应的分数线就不能导入成绩等等，这样就避免了认为的错误。同时将工作交给别人来做。最基本的数据导入excel的功能，而我实际上是在后台直接操作数据库和数据表的，很容易导致错误。
所以软件做出来是给人用的，就像白居易的诗，老婆婆和小孩子都看得懂，一定要简单易用，不容易处错误人们才会喜欢。
所以，一开始，我的定位是完成报名这个任务，写出来的程序基本上是自己用，如果我目标是结局报名这项学校大的工作中的一系列问题，并且可以推广给所有的人使用，无论是教务人员还是信息技术教师，那么自主招生报名信息化这个问题就解决了。这说到底其实是个思路的问题。功能模块要划分清楚，不要破坏程序已有的结果。
测试功能。
人为原因
以上是程序设计的原因。还有个gf指出的重要的问题，领导明明已经着重提醒我分数线已经改了；而且对于录取来说最重要的就是分数线，显然自己太急躁，对于这么重要的问题，没有静下心来思考那个是最重要的，哪个应该优先完成。很多时候别人告诉我什么事情，我总是坚持自己想法，过于自我，导致出错。
做事啊，尤其是是重要的事情一定要跟多人确认，自己先看三遍，没有问题了再跟领导汇报，领导觉得没有问题了，再上报，在没有确认问题之前一定不要着急上线，否则就会导致乱七八糟的问题。一定要自己再三审查，然后找领导或者同事帮忙检查确认。
