软件开发项目中小白应该注意的一些地方——《人月神话》读后感下
作为一个编程经验不足，软件开发项目经验不足的小白，阅读完《人月神话》之后获得了不少启发。这里将文中好的观点以及结合我自身体验产生的想法写下来，希望对自己的编程和项目开发起到一定的帮助作用。
第八章 胸有成竹
编程工作量随代码规模的扩大呈指数增长。代码规模的扩大意味着程序复杂度的提高，子功能函数数量的增加。在系统越来越复杂的情况下，为了保证程序的质量，程序员不得不时时留心各个函数的调用关系以及各个功能模块的配合，导致了工作量的指数增长。因此不能用小型项目的编程效率去估计大型项目的编程效率，这样只会导致计划的落后。
Corbato的数据告诉我们一个道理，使用适当的高级语言，编程的生产率可以提高5倍。同样的问题，假设一个人用c来解决只需要一天下午，那我估计同样的人用汇编来写可能就需要两天甚至更多，至于python，可能一个函数就解决了，这就是使用不同语言的差距。但是这里要标明我的个人观点：并不是解决所有问题都应该追求用高级的语言解决，因为你使用的封装库在方便你编程的同时隐藏了你应该了解的底层知识。
第九章 削足适履
在学习c语言的时候经常会出现这样的现象：为了避免使用动态内存的麻烦去定义一个足够大的数组，当被问及为什么要这么做时，“反正内存够用”。这样的编程习惯是应该被抵制的，除非以后编写的所有程序都只是自己一个人玩一玩。对于使用程序的用户来说，一个好的程序应该尽可能给用户较大的输入自由度，而不是在程序旁边标注：“此程序最多可以输入多少个字”，这样做真的很low。
说起“内存够用”，我想起了我的数据结构老师朱明老师在讲快速排序的时候对书上“左右腾挪”的做法的吐槽：“明明内存够用，干嘛那么费劲，我直接新建一个数组往里填不就行了”。当时听到这句话的时候我一下就笑了，有趣。我觉得老师的这段话是在说这样一个道理：在问题比较复杂的时候，以耗费内存为代价写出简单易懂的程序要比想尽办法写出的别扭的程序要更好一些。当然这里说的和上一段说的并不是同样性质的问题（自行体会）。
这一章让我想起的另外一个东西就是我妈的红米2。我是比较喜欢新鲜功能的人，所以每次MIUI系统升级的时候我都会迫不及待的下载安装包。可是问题也渐渐出现，红米2的硬件配置根本带不动最新的MIUI系统，使用起来非常卡，体验及其不友好。我用的一个千元蓝厂机的系统升级就不一样了，每次只是最以往的系统做优化，根本不会提供给你最新的系统。两者的区别说明了一个简单的策略问题，以用户体验为上，根据硬件配置提供给用户相应的软件功能，不要累垮了硬件烦死了用户。
第十章 提纲挈领
正式文档的重要性（摘自原文）：
1.只有书面记录决策，分歧才会明朗，矛盾才会突出，项目成员才能得到清晰、确定的策略。
2.文档能够作为同其他人沟通的渠道，减轻决策者在团队沟通问题上的负担。
3.项目成员根据文档可以清楚的知道项目的进程以及当前存在的问题，便于工作的进一步开展。
软件项目的正式文档有哪些：
项目目标：一开始的时候可以定一个大致的目标，在开发过程中根据出现的问题以及用户的新需求不断的修改目标，软工老师称之为“沿途下蛋”。
技术说明：包括用户手册和内部文档，在程序开始编写的时候就要开始记录，随着过程的深入不断改进。
进度安排：这个方面emm，小白可能一脸茫然，不过找有经验的人提供指导就可以了。
资金预算：学生阶段，开发预算都有报销，暂不考虑。
任务分配：要记住一点，每一项工作都值得你去做好，不必去争取做最难那一部分的机会，以后有的是。
绩效管理：学生时代敏感的话题，我的看法是：所有东西，一是一，二是二，做得好做得不好都清楚的展示出来，不要去嘲讽做得不好的人，解决因为这些人带来的进度问提才是关键。
第十一章 未雨绸缪
“普遍的做法是，选择一种方法，试试看；如果失败了，没关系，再试试别的。不管怎样，重要的是先去尝试”——富兰克林·罗斯福
这里我想说的不是尝试，而是失败之后重新去做的勇气。我们小组这两天忙着讨论换题的事情。不得不说，当大家意识到“特大社区”不需要我们去做的时候心里多少都有失落。项目选题阶段，我们组快速高效的确定了我们的思路，课程社区和校内二手平台。由于占坑晚了三分钟，二手平台的想法与我们擦肩而过。不过没关系，课程社区挺好的。我们认真讨论了需要的功能，并做了两次详细的问卷调查。一切都是那么顺利……直到上课汇报，我们浏览了往年的项目，这才发现我们思路撞车极为严重。我们赶忙又对往年的各个项目进行调研，结果就是，我们决定做的主要功能都存在相应的网站，而且做的很不错。就像惊天雷炸了一样，所有人的心情都难以言说。最后，我们放弃了原来的想法，重新确定了选题。
变化是不可预知的，未雨绸缪是不可能的。我们唯一可以做的就是不断尝试，在不断地失败中调整方向继续前行。
第十二章 干将莫邪
工具的创造和使用是人类区别于动物很重要的一点。同样，学会制造合适工具的程序员会因为工具的使用极大地提高工作效率。
在看到这一章之前，每次用c编程我都会将要用到的常用的函数自己写一遍，而且常常忘记细节，带来了不必要的麻烦。以后要给自己量身打造一个函数库，方便自己使用。当然，在团队合作中，应该尽可能使用公用工具以减少不必要的麻烦。
第十三章 整体部分
浏览知乎的时候偶尔看到，“能写程序和会写程序的区别是什么？”。我想区别大概就是，能写程序只是将一堆代码写了出来就完事，留下一堆的bug不管，而会写程序是知道如何编写程序能够减少bug，如何测试能有效的查找出bug。
这一章介绍了几种很好的在设计中减少可能的bug的方法，这里摘录下来：
1.保证产品的概念完整性，整体设计方案出自一两个人。（如之前所述，学生阶段我不建议使用这种方法）
2.详尽的文档记录：细致的功能定义、仔细的规格说明、规范化的功能描述。
3.采用自上而下的设计。设计中采用模块化编程思想，分而治之。
关于系统调试，在调试之前要保证各部分模块能够正常运行。在测试bug的时候，注意采用控制变量法。
第十四章 祸起萧墙
“灾祸来自白蚁的肆虐，而不是龙卷风的侵袭。”
里程碑必须清晰明确的定义。“截止下个周末完成编程”，这样的里程碑带来的结果只能是到下个周末程序写好了但是有一堆bug，任务进度由此被拖后腿。最近深切感受到了明确里程碑的重要性。组长说这两天我们调研一下web前后端开发需要的技术吧，结果，两天后，大家所说的都是百度知乎上随便就能找到的，html,css等。组长问：“你们调研了所有常用的技术吗？不同技术之间的优缺点比较过吗？”，一下子大家都蒙了，里程碑没说清，所以只能重新完善调研。
懒是万恶之源。尤其现在身边很多人（包括我）不由自主犯懒，ddl没到眼前不做事。不用说，团队里大部分人是这样的话，这个团队就没救了。还好，这次我参与的团队每个人都很努力，那我也就不好意思拉大家后腿了。所以，关键的是团队的氛围，首先组长要身先士卒带动队伍的积极性，其次要求组员能够认真完成自己的任务。在良好的氛围下，少数懒人也会有所作为。如果所在团队大部分人都持懒散的态度怎么办？退出队伍，去找适合自己的队伍。
第十五章 另外一面
在学习单片机的时候，我经常会遇到一个问题，网上所谓的教程说的不明不白，看似很厉害的文档，总是将我最想知道的知识隐藏起来，导致看完之后仍然云山雾绕。后来我找到了《圣经》般的文档——芯片手册。手册详细的说明了这个芯片是干什么的、它对环境的要求、有效的输入范围、指令、精确度等。虽然是英文文档，但是坚持读下来会发现对这个芯片的了解无比清晰。软件也是这样，详尽的程序手册能够帮助用户清楚准确的知道如何使用这个程序。对于程序而言，另外一种常见的做法是，将程序的相关信息（功能、输入输出等）以注释的形式添加到程序中，这无疑给别人使用这个程序带来了极大地方便。
