随笔分类 - 软工经典书籍
摘要：一、·经济学分类 经济学分为2大类；微观经济学，宏观经济学。 · 微观：从个人，企业的观点展开研究 · 宏观：探讨经济学整体 二、微观经济学篇： -序： 你不必具备斯坦福大学终身教授的资格，就可以在大部分的日常经济讨论中坚持看法，具备“言之有物”的能力：因为对公共政策作出建议的经济学，大多数只用到大
阅读全文
摘要：作者通过本书提供了塑造魔鬼式思考方式的具体步骤，一共分为六步： 1，没有解决不了的问题，只有你未知的方法，承认自己不知道，才能找到解决问题的方法 2，通过客观思维和大数据，重新定义你遇见的问题，从不同角度重新理解和认识问题、定义问题，是魔鬼式思考的入口 3，解决不了问题的根源，是面对问题需要承担它给
阅读全文
摘要：1、交换价值与使用价值 作者举了一个例子，水对我们的生存来说很重要，说明水的使用价值很高，但水很便宜，一瓶矿泉水才几块钱，这几块钱就是水的交换价值。 而钻石的使用价值很低，大部分人也只是用来装饰，不能吃也不能喝。虽然钻石没什么大用处，但是大家愿意花大价钱买它，这就表示钻石的交换价值很高。我们谈到价格
阅读全文
摘要：首先什么是架构，作者引了一个人类集体生活的例子，形象生动，容易理解，由这个例子，把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。通过例子，作者解
阅读全文
摘要：这本书有文字，有代码。并且解释的很清楚。值得一提的是作者十分诙谐幽默，读这本书完全是因为书中的内容吸引了自己。所以想把自己读过之后的感悟分享给大家。 第一章讲了综述，即什么是软件，什么是软件工程，对于这部分作者不仅提到了基本的定义，还就提出这些定义的理由进行了解释。我们大家都知道， 程序=算法+数据
阅读全文
摘要：开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分
阅读全文
摘要：整理了一些IDEA开发常用的快捷键： 快捷键组合实现效果 psvm + Tab键 / main + Tab键 public static void main(String[] args) sout + Tab键 System.out.println() Ctrl + X 删除当前行 Ctrl +D
阅读全文
摘要：第一次从网上找到《人月神话》这本书，若不是老师极力推荐，我还傻乎乎的以为这是本神话小说呢！由于对软件工程了解的不多，对这本书的解读不深刻。不过，从很多方面可以了解到这是一本畅销的、具有深远意义的书。因为这本书所带给自己的，并不亚于一门专业课所带给你的知识。这本书是拖了好久才看的。 这本书讲述了几十年
阅读全文
摘要：《梦断代码》中涉及到的组件化开发，将功能分成若干个模块，再将这些模块组件化，将他们拼装在一起，这样无疑方便了使用，但是， 这些组件只能是一步一步的积累起来的，所以组件库并不多，而且由于不同组件之间需要通信,组件多了通信就容易变得复杂,又不得不引入flux这种架构模式来管理状态和处理不同组件间的通信,
阅读全文
摘要：当我继续读下去的时候，深深的感触到程序员的不容易，经理的不容易，通过作者对自己工作和身边一些人的描述，我是真实的感受到了作为一个程序员的辛苦之处，尤其是作者当时作为一个经理人的辛苦。每次当他有想设计的的方案时，都要仔细的掂量，因为这就是他的决策，他必须要为自己的团队负责。我记得有人说过这样的一件事情
阅读全文
摘要：也许因为我是小白，所以对于规划，管理这些知之甚少，读这本书的第一印象就是不太理解，慢慢的就陷进去了。 那么，作者在书中项目的失败究竟是因为什么，是决策？是能力？还是其他？作为一个资深的经理人，我相信作者在书中提到的一些项目经理人都是有很强的能力的，他们能够很好的去完成自己的任务，也能够做出很好的规划
阅读全文
摘要：感受：读完本书第一部分后，首先感觉到的就是这本书有些深奥，好像不是现在就能看的，读完一遍云里雾里的，还是没能到那个层次吧，慢慢积累经验吧。 一、仅仅就是软件架构的概念现在理解起来都有些困难，概念的分类就是两个门派吧，一个“组成派”，一个“决策派”， “组成派”关注的是架构实践中的客体——软件，以软件
阅读全文
摘要：防御式编程该怎么认识呢，在其他程序员犯下错误时保护你自己，一个子程序不因传入错误数据而被破坏，也就是说程序都会出现问题，需要时时修改。 断言对于一些大型程序来说，是很有用的，这样能够更快排查出程序哪里出现的错误，断言可以在程序中说明各种假定，澄清各种不希望出现的情形，当然，断言是在程序开发、维护阶段
阅读全文
摘要：什么是变量名呢，简单地描述，还是对变量的描述，清楚的对变量的描述，用完整的变量名降低冲突。 为变量赋予主要含义的，一般放在最前面，这样显得突出，将Totol,Sum,Average,这些限定词放在最后面，这样一致的话，即可以提高代码可读性，又可以很好的去做维护工作，但是这里有一个限定词是约定俗成的，
阅读全文
摘要：注重实效的团队，不要留破窗户，在一个团队里面，不要做那个不在乎质量的人。 尝试去自动化实现一些事，这是能够确保一致性和准确性的很好的一种方式，留给团队每个成员一些独立的空间，支持他们让他们自己做，而不是一直给他们具体化的要求，这样就会限制他们的思维以及想象能力。 测试是很重要的事，不能懈怠，尽量做到
阅读全文
摘要：第七章的内容为我们给出了项目开始之前的一些建议。 挖掘需求，需要我们与用户一同工作，从用户的角度思考需求。怎么样更直观清晰，将UML图画出来，当然，这就是写给自己看的，你觉得用户会用心去看你的用例图吗，应该不会，口头简单的描述，在用户眼里，远比用例图好用。 需求不是一个具体的事务，可以说需求是抽象的
阅读全文
摘要：在本书中第六章，正应该是我们当下正在刻苦编程的人应该看的，编码就仅仅只是简单点的编码吗，不是，我个人感觉我们现在很多编程的人都只是机械式的编程，可编程真的需要这样吗，程序应当是“活”的，不应该是让程序刚好运行就行，知其然知其所以然，将前应后果弄清楚后，首先是印象深刻，其次更是对我们思维能力的一种锻炼
阅读全文
摘要：对于元程序的设计，就像是让我们的系统变得高度可配置，屏幕颜色，提示文本，这些理应作为配置项，而不是写成代码放到项目之中。 创建高度灵活的可适用的程序，将抽象放到代码，细节放进元数据。 Enterprise Java Beans是一个用于简化分布式、基于事务的环境中的编程框架。它处理了不同机器、在不同
阅读全文
摘要：按合约设计，注重实效的程序员会针对自己的错误行为进行防卫性编码，这就是DBC，但是这个就是了解一下，因为支持DBC的语言很少 断言式编程，断言检查的是不应该发生的事，而不是说去处理错误，使用断言就是为让代码遵守一种强条件，确保不可能发生的事，不会发生。 对于我们对不同的事务分配了不同的资源，怎么样去
阅读全文
