关于构建之法的若干个问题
1.第一章32页，原文：“有人认为，“中文编程”，是解决程序员编程效率的一个秘密武器,请问它是一个“银弹”么？
关于这个问题，我首先要回答：“中文编程”绝对可以大幅提升中国程序员的编程效率。
我首先要说一个我的经历，就是我之前碰上了一个学长，他看过我写过的一些python程序，然后吐槽我对一些特殊函数的命名是中文，说不符合编程规范。
可以看出，他也许是一个中文编程的反对者，而且像他这样的中文编程反对者不在少数。
我首先要说一下为什么我认为中文编程的理解。
我认为，中文编程意味着不仅仅某种语言自带的函数可以用中文，还意味着变量，函数命名可以用中文。
我认为这么做带来的好处是用可以少量增加编码时间（主要是输入法麻烦），来换取大幅降低读代码的时间，效率大大提高
我们看我第一次个人项目两个英文的变量名，比如说
如果我不说，各位看官可以看出这两个变量是什么意思么，数字的可能性？其实是数字填充方式的意思，如果用英文表达清楚，那么这个变量名会非常长，而且也未必好理解
而且同样的意思，用中文表达往往比英文要短很多的
用中文一瞬间就读懂了变量的意思，我认为快速读懂变量，函数意思可以大幅减少读代码的时间
我们再看一个英文变量名
target?换成flag行不行，作为一个非英语母语的编程者，我认为这两种方式没有区别
同时还有，squared与block，也可以相互替换
而且英文还有大小写的问题，这就造成了一个变量可以有很多种命名方式，导致多人编程需要制定严格且详细的编码规范
但是用中文命名就非常舒服了，不管是target还是flag，我想，除了标记就没有其他的答案了
这样可以总结出，中文编程可以让自己的代码可读性大大加强，编码规范也更容易制定
如果库函数可以用中文调用呢？我想，这可以大大减少程序员学习文档的时间吧，也是一种提高效率的手段。
最后，中文编程可以降低编程工作者的英语门槛，可以让程序员更加专注于程序本身的逻辑，也可以间接提高效率。
到这里我就要问了，为什么这种提高中国程序员编码效率的手段会遭到那么多编程者反对呢？
2.第三章66页，软件工程师的成长
这个“精通者”的经历我也深有感触，在学习某一项新技术的时候，安装与配置环境很令人头大，如果没有成熟的教程，看文档的过程更令人头大。
这就是这本书定义的低层次问题，但是这种门槛往往会让我更愿意用现成，已经掌握的技术（说来惭愧，VS也是我刚刚用的编辑工具，之前一直是VC6或者vim，没探索过别的），如果对新技术不了解或暂时不急切就不去探索。
我想问一下，我目前这个问题在以后的发展中能对我造成多大阻碍，换计划说，我这样对新技术保守的态度带来的弊端有多大？
3.第四章98页，两人合作
关于性格对合作的影响，根据我的观察，和我同年级的计算机专业的本科生大概能通过编码风格分成两类
第一种是重视代码运行效率大于代码可读性，第二种是重视代码可读性大于代码运行效率，我属于前者
亲身经历，不同类型的程序员交流技术往往因为思维方式的不同导致交流难度大于相同类型的程序员
而且同种类的程序员往往在技术方面的观点也相似，长处与缺点也相似。
我认为把程序员分为这两类的原因是思维方式的不同，而不是性格不同
程序员的性格大体相似
因此，我认为思维方式对合作的影响比较大
我想问我这个观点合理不合理，我上述观察的现象在公司内是否也存在?
4.第四章98页，两个人的争论
这两个人争论的有一个点，就是关于C++的新特性有没有必要用
我个人的观点是，能用朴素的手段快速解决就没有必要用新特性
我这个观点就导致了我大一上C语言课从来没调用过string,h这个库，自己搭了一万个轮子
但是这样不了解新特性就会造成编码效率的降低
但是花时间去了解新特性可能会出现长时间不用又忘了，同样浪费时间
这就造成了一个矛盾
我想问一下，一个语言更新出现了一些新特性，普通的编程者不知道这些新特性是用来解决什么问题的
那么这些新特性是否需要在语言更新时就花时间进行学习。
5.两人合作 79
关于goto
我记得大一的时候学C语言老师禁止使用goto
现在这里又说了可以使用goto
我是这样理解的，大一禁止使用goto是因为我们刚接触编程，goto虽然很方便，但是用goto来回跳会导致逻辑混乱
现在允许使用goto,是因为我们已经接触和编写了一定量的代码，对程序逻辑有一定的把控能力，因此可以使用goto来让逻辑更清晰
我这样理解合理不合理？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
早在20世纪50年代，有关软件的编程语言就已经出现，但是关于软件工程这个概念却要远远晚于软件发展。据资料显示，软件工程这个概念最早出现在20世纪60年代末期。
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
一个测试工程师走进一家酒吧，要了一杯啤酒
一个测试工程师走进一家酒吧，要了一杯咖啡
一个测试工程师走进一家酒吧，要了0.7杯啤酒
一个测试工程师走进一家酒吧，要了-1杯啤酒
一个测试工程师走进一家酒吧，要了2^32杯啤酒
一个测试工程师走进一家酒吧，要了一杯洗脚水
一个测试工程师走进一家酒吧，要了一杯蜥蜴
一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@
一个测试工程师走进一家酒吧，什么也没要
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿
一个测试工程师走进一
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷
一个测试工程师走进一家酒吧，要了NaN杯Null
一个测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶
一个测试工程师把酒吧拆了
一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱
一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧
一万个测试工程师在酒吧门外呼啸而过
这个笑话我认为非常能反应软件工程中软件测试的特点，笑话虽然是这么说的，但是软件测试也是这么做的，我认为很有趣。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
tfs:TFS（Taobao FileSystem）是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的Linux机器集群上，可为外部提供高可靠和高并发的存储访问。TFS为淘宝提供海量小文件存储，通常文件大小不超过1M，满足了淘宝对小文件存储的需求，被广泛地应用在淘宝各项应用中。它采用了HA架构和平滑扩容，保证了整个文件系统的可用性和扩展性。同时扁平化的数据组织结构，可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读写性能。
git:Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。
Mercurial:Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目。
github:gitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名gitHub。
bitbucket:BitBucket 是一家源代码托管网站，采用Mercurial和Git作为分布式版本控制系统，同时提供商业计划和免费账户。
trac:Trac是一个为软件开发项目需要而集成了Wiki和问题跟踪管理系统的应用平台，是一个开源软件应用。Trac以简单的方式建立了一个软件项目管理的Web应用，以帮助开发人员更好地写出高质量的软件；Trac应用力求不影响现有团队的开发过程。
bugzilla:Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期。
rational:Rational是提供基于业界开放标准的工具、最佳方案和服务，用于开发商业应用和构建软件产品及系统，包括移动电话和医疗系统等设备使用的嵌入式软件。在IBM的帮助下，Rational将进一步提升软件开发能力，创造更多业务价值。有了它，企业在未来的On Demand（随需应变）时代中将拥有更快的反应、更有弹性的运营策略和更加明确的发展方向，从而取得更大成绩。
xcode:Xcode 是运行在操作系统Mac OS X上的集成开发工具（IDE），由苹果公司开发。Xcode是开发OS X 和 iOS 应用程序的最快捷的方式。Xcode 具有统一的用户界面设计，编码、测试、调试都在一个简单的窗口内完成。