资源描述
读书笔记 第二周
认知的挑战:几乎所有的人都认为,软件开发是年轻人的职业。程序员们一边挥着汗水,辛苦地熬夜写代码,一边又对自己30岁以后的职业发展方向充满惶恐。实际上,我国最缺的是有10年以上经验的软件工程师。金山软件公司总裁雷军说过:“在印度,包括在美国,我见到的项目经理都是三四十岁的人,他们‘越老越值钱’,有些人甚至拥有超过20年的行业经验。”
环境与程序员的工作与发展:看到过这样一句话:环境会对程序员起到如何的影响,这在很大程度上取决于程序员自己。对于最好的程序员,他们几乎可以在任何环境下做出好成绩;而对于最差劲的程序员,不管一个环境被吹得如何天花乱坠,也帮不了他们的忙。 但是,尽管如此,我们的确应该努力为程序员提供良好的交流环境和氛围,以免他们死坐在电脑前面钻牛角尖,而忽略了思考和交流的重要性。而书中也有关于这个问题的见解,软件行业的发展承载着国人太多期待与情怀,人们把他看成中华民族腾飞的重大机遇,然而今天我们发现,我们的经济领先印度,但软件却落后。我认为,人们要给程序设计者空间,包容与接纳的土壤才是适合发展的,诚然,面对飞速发展的经济与思维,人们需要年轻,有活力的新鲜思维去接受,去开拓,去创造更大的经济利益,但也要认识到,有些长期投资也是值得的。慢与沉淀并不意味落后,经验的积累与思维体系建构的不断优化也有其巨大的价值与重要的现实意义。
编程的乐趣:来自于创建事物的纯粹快乐,来自于开发对他人有用的东西,来自于整体过程体现出的一股强大魅力。我认为,编程的乐趣也来自于和一个实体世界下很陌生的概念的交流,就像人们见到人工智能的发展那样。它不仅会帮你解决问题,也会告诉你,它怎么考虑这个问题,很多时候,它的思维在解决现实问题时有重大的意义。所以我觉得和这种新思维的交汇与碰撞也是一种快乐,是我学习程序设计的重要动力之一。
什么是编程:编程就是一个许多人痛苦挣扎的焦油坑,一种乐趣和苦恼共存的创造性活动。
人月:一种在估计和进度安排中使用的谬误的思考方式,成本随开发产品的人数和时间不同有很大变化,但进度却不是如此。用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。因为程序工作尤其现实特点,需要任务之间的沟通,项目之间的交流,从本质上讲是一项系统的工作,即在复杂关系下的一种时间,所以在考量时间进度时,不能简单地把人当成一个单位,进行时间化计算,而是要考虑交流的方便性,即有时候增加人手并不一定能带来时间进度的缩短,就像一位编程大师所说,一个人的效率是最高的。(不过当然不能任何项目都一个人完成,虽然效率高,但任务量确实太大,合理化的考虑这些因素的影响才能最终实现最合理的安排。 思考:其实这个概念和具体编程实践也有一定借鉴意义,我们强调模块化设计,一个个函数组成了一个小项目,一个个项目组成了产品,好像一切都那么自然,就像这是一个合格程序员必须做的,必须遵循的。但我们能否有些突破与改进,也许满足一定程度的结构化与审美要求,能在产品性能和审美体验上达到标准,二者的进退权衡可能会收获意想不到的成果。而这,应该需要大量的实践总结与反思。
进度的安排: 1/3计划,1/6编码,1/4构建测试,1/4系统测试。
增加人手所带来的:向软件项目中增派人手从三个方面增加了项目必要的总体工作量:任务的重新分配本身和所造成的工作中断。培训新人员,额外的相互沟通。
如何解决人月问题所涉及的矛盾:外科医生,副手,管理员,编辑,两个文秘,程序职员,工具维护人员,测试人员,语言专家。参照外科手术队伍对于编程团队进行专业化角色分工。
在操作实际问题时,这样的想法有巨大的借鉴意义。从身边取材,用思考去解决实际问题,应该是程序工作者必备的技能。
系统设计:系统设计遵循:阶段开发原则,易用性原则,业务完整性原则,业务规范化原则,可扩展性原则。而概念完整性是系统设计中最重要的考虑因素。为了获得概念完整性,设计必须由一个人或者具有共识的小型团队来完成。形象的说,就是贵族专制统治与民主政治。同样的,体系结构同实现必须仔细地区分开来。
工作与时间:整个创造性活动包括三个独立的阶段,体系结构、设计实现、物理实现。实际情况中往往可以同时开始和并发进行。
交互准则:尽早交流和持续沟通能使结构师有较好的成本意识,以及使开发人员获得对设计的信心,并且不会混淆各自的责任分工。
结构师要做到的:牢记是开发人员承担创造性的实现责任;结构师只能提出建议,不能支配;要有想法以应对各种情况,也要准备接受其他的方法。
贯彻执行:即使是大型的设计团队,设计结果也必须由一个或两个人来完成,以确保这些决定是一致的。合理化的规格说明是交互的必要手段,形式化的定义也是审美体验的重要影响因素。会议是必要的,交流和分享应对问题的策略。
交流的重要性:对于存有疑问的实现人员,询问相应的结构师而不应该一边自行猜测一边工作。
产品测试:项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。
为什么巴比伦塔会失败:巴比伦塔项目的失败是因为缺乏交流,以及交流的结果的组织。
因为左手不知道右手在做什么,从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设,团队成员之间的理解开始出现偏差。 反思:要学会从失败中反思,成功都是螺旋上升的结果。对于这个案例,又告诉我们,在项目进行过程中交流的重要意义。
仅仅通过对编码部分的估计,然后乘以任务其他部分的相对系数,是无法得出对整项工作的精确估计的。
设计人员必须决定用户可选项目的粗细程度。
数据的表现形式:精湛的技艺出自创造,精炼、充分和快速的程序也是如此。技艺改进的结果往往是战略上的突破,而不仅仅是技巧上的提高。更普遍的,战略上突破常常来自数据或表的重新表达—这是程序的核心所在。 结论:数据的表现形式是编程的根本。
反思:优化的时候除了要思考选择更合适的算法,也要思考是否有更优质的数据结构去描述问题,从根本上解决问题。
为舍弃而计划。
抛弃原型概念本身就是一种对事实的接受——随着学习的过程更改设计。
进度与进程:根据一个严格的进度表来控制项目的第一个步骤是制订进度表,进度表由里程碑和日期组成。里程碑必须是具体的、特定的、可度量的事件,能进行清晰能定义。如果里程碑定义得非常明确,以致于无法自欺欺人时,程序员很少会就里程碑的进展弄虚作假。
可读性:即使对于完全开发给自己使用的程序,描述性文字也是必须的,因为它们会被用户和作者所遗忘。 反思:注释的重要性;变量名清晰;结构清晰。
展开阅读全文