《人月神话》于 1975 年正式出版，Brooks 在书中提出了一个著名的法则，即：“向进度落后的软件项目中增加人手，只会让进度更加落后”，这句话后来被称为 “Brooks 法则”。//@甘道实验:大型编程项目却极具挑战，部分原因在于人员管理问题以及如何协调大量人员，这是一项极其困难的脑力工作。实际上，软件开发是极少数既需要协调人量人力又不具备实体的工程技术项目，建筑项目也很复杂而且涉及大量参与者，但他们面对的是有形的实体，所以能以物理形式进行跟踪。同样，桥梁隧道之类的工程项目也是如此，现场参与者虽然成百上千，但各个步骤或者施工环节确有切实的线索可抓。但在软件中很多工作无形无相，所以除了我们自己的想象力外再无跟踪事态的可靠线索。 所以大型软件项目因复杂性而失控的可能性远超人类从事过的几乎任何其他项目，其根源就是软件项目的无形性，而且大型软件项目很快就会超出个人的理解力上限，没人能理解项目中的所有代码，毕竟这是成百上千人的成果。所以面对这些规模更大的项目，如果不对复杂性做出限制，那么项目的每个步骤都可能崩溃失控。以往，无数大型项目都在砸下巨量资金后失败了，原因就是其过于复杂，已经无人能理解究竟发生了什么，就如同过于庞大的巨兽被自身重量所压垮。 具体来讲，复杂性其实贯穿于软件开发的各个阶段，复杂性在编码过程中，因为如果底层代码的质量不好，超大规模系统也可能就由此崩溃。所以必须立足底层，立足细节抓代码质量，关注每个语句、例程和类，步步为营，以此为基础才能扩大规模，同时继续保持代码质量，即在设计和架构层级控制复杂性，对复杂性控制要广泛而深入地体现在软件开发的各个阶段。
甘道实验大型编程项目却极具挑战，部分原因在于人员管理问题以及如何协调大量人员，这是一项极其困难的脑力工作。实际上，软件开发是极少数既需要协调人量人力又不具备实体的工程技术项目，建筑项目也很复杂而且涉及大量参与者，但他们面对的是有形的实体，所以能以物理形式进行跟踪。同样，桥梁隧道之类的工程项目也是如此，现场参与者虽然成百上千，但各个步骤或者施工环节确有切实的线索可抓。但在软件中很多工作无形无相，所以除了我们自己的想象力外再无跟踪事态的可靠线索。 所以大型软件项目因复杂性而失控的可能性远超人类从事过的几乎任何其他项目，其根源就是软件项目的无形性，而且大型软件项目很快就会超出个人的理解力上限，没人能理解项目中的所有代码，毕竟这是成百上千人的成果。所以面对这些规模更大的项目，如果不对复杂性做出限制，那么项目的每个步骤都可能崩溃失控。以往，无数大型项目都在砸下巨量资金后失败了，原因就是其过于复杂，已经无人能理解究竟发生了什么，就如同过于庞大的巨兽被自身重量所压垮。 具体来讲，复杂性其实贯穿于软件开发的各个阶段，复杂性在编码过程中，因为如果底层代码的质量不好，超大规模系统也可能就由此崩溃。所以必须立足底层，立足细节抓代码质量，关注每个语句、例程和类，步步为营，以此为基础才能扩大规模，同时继续保持代码质量，即在设计和架构层级控制复杂性，对复杂性控制要广泛而深入地体现在软件开发的各个阶段。
程序员所理解的if-else条件语句。如果问编程的精髓是什么，一言以蔽之，就是decision，就是if-else条件判断语句。
写代码的时候，如果碰到“判空语句”，您是习惯写成“if(object == null)”还是“if(null == object)”呢？目前来看，我使用的C＃其实两种写法都无所谓，从语境上讲，其实在判空的时候，把null放在右边更加符合我们的语境，即“object是否等于null”。
但是，遇到一些编程大神的时候，他们会告诉你：“null得放在判断语句的最左边，这样可以避免一些麻烦！”。
也许是C＃“保姆式”的编程环境，所以C＃程序员在编程的时候很多情况下都是“不拘小节”的，因为很多东西都是托管的！而指针则是半托管状态，即在不主动调用指针的情况下，C＃会自动处理！
于是，我请教了一个Java程序员和一个C++程序员的朋友，问他们对于此事有何看法。
其中，Java程序员跟我说，虽然他习惯把null放在if语句判断条件的左边，但是实际上放左边和放右边其实没有区别，只是习惯而已！
但是，写C++的程序员直接给我写了一个Demo。
在C++中，if语句里是可以使用“=”号直接赋值的，这时候把null放在if语句左边，则可以避免出现写成“if(object=NULL)”这样直接把变量赋值成null值的错误。
因为NULL值在C++中是常量，给常量赋值的话会直接编译错误！另外，C++指针如果为NULL的话，放左边可能会报指针错误，而放右边则不会！（不解！）
因此，如果您是C＃程序员或者Java程序员，完全不需要顾虑if语句判空时null应该放左边还是右边。因为“null最好放左边”这个说法，本身就来自于C++程序员！
#程序员# #编程# #编程语言# #计算机#