补充，我在班级群里面指出了老师作业中语言表达不明确的地方，随后我的博客地址就被他贴到了作业上，我能知道上一个被他们公布博客地址的同学，他的博客就在网上被一些人“指手画脚”了，而且都是一些不知道什么人，我们的地址都对应我们的名字写在一个商人的博客上。我的博客可能在日后几天内出现大幅度点击量变化或者评论增加，这是一些人的惯用人段把？
要求零：https://edu.cnblogs.com/campus/nenu/2016CS/homework/2266
此要求是一位在反复强调过我们的毕业证后要求我们写的，我们询问了一下，这位竟然是我们的学长，又询问了与他同届的学长对他的评价有些不雅，所以还请各位看官，走过路过可伶过我，我真的不知道他的导师知不知道他的行为，我们学院的老师都有儒士君子的风范。不知道这位是不是与外面的商人学的这样，心酸啊。
要求一：
git项目名称：f4
git地址：https://git.coding.net/xup457/f4.git
项目目录：
f4.exe
f4.cpp
要求二：
同伴的博客地址：
同班的姓名：陈鹏宇
解题思路：
1，读取字符串分析算法，
2，数字精确度校对，
3，结果的判断，注意按照要求取舍，
4，读入指定文件
难点：
1，数字的校对，
2，产生随机数字，
3，以及读那本对于无正式工作经验的学生来说晦涩难读的《构建之法》第四章
变成收获：
读完了《构建之法》第四章，而然对作业没有直接帮助，在我们组讨论的过程却遇到了书中的描述情况，得以解决，在此感谢老师的推荐。
代码片段：
1，判断是否有括号：
bool com()
{
int flag=0;
for(int i=0;i<len;i++)
{
if(str[i]=='(')
{
flag=1;
}
if(str[i]=='_'&&flag)
return 1;
}
return 0;
}
2，功能1：
double solve()
{
double sum = 0;
int flag=0;
for(int i=0;i<len;i++)
{
if(str[i]>='0'&&str[i]<='9'&&flag==0)
{
sum=str[i]-'0';
flag=1;
}
else
{
i++;
if(str[i-1]=='+')
{
sum+=(str[i]-'0');
}
else if(str[i-1]=='-')
{
sum-=(str[i]-'0');
}
else if(str[i-1]=='*')
{
sum*=(str[i]-'0');
}
else if(str[i-1]=='/')
{
sum/=(str[i]-'0');
}
}
}
return sum;
}
3，功能2：对不起老师我不会写。
4，功能3：我不会由于老师不让我们彼此交流，所以即使请教了同学，也知道用逆波兰表达式写会容易一些，但是还是没有用，准备用自己的思路写，实在是rh老师不让我们交流啊。
得意之处：安全的写完了这篇博客，因为我的个人信息被外面的商人扣押所以十分焦虑。后来又有自己学院的助教因为我在群里面提问题将我的个人信息挂到作业网页上，我真的不明白我问老师问题有什么不对的，而且确实是他们的问题，如此大胆公开我的信息，他们的良心不会痛吗？
体会：通过这次的组队学习，学到了很多新的知识，比如，《构建之法》80页4.5.3有云：
4.5.3 不间断地复审
结对编程让两个人所写的代码不断地处于“复审”的过程，程序员们能够不断地审核，提高设计和编码质量，可以及时发现并解决问题，避免把问题拖到后面的阶段去。开发中的复审主要包括：设计复审、代码复审、测试计划复审和文档复审。这些复审可以在伙伴之间进行，也可以在团队内部进行。结对编程和传统开发过程的复审有什么区别呢？
1. 传统意义上的伙伴复审，即程序员之间的互相复审，有以下的问题：
1）复审人缺乏对程序的深入了解，减弱了复审的效果；
2）不能持久、定时地进行复审；
3）对需求和设计的不了解导致无法实现全面有效的复审。
2. 团队复审是指多于两人的团队就某一程序实体进行的复审，团队复审的缺点在于：
1）什么时候开会做复审？不可能一个团队天天开会。要找到一个所有人都能出席的时间，并不容易；
2）牵涉的人员众多，理解程度不一，复审的速度和效果不能得到有效的平衡—太快则有人不懂，太慢则浪费许多人的时间；
3）正是由于成本问题，无法对所有的设计和代码进行深入的复审；
4）由于人员众多，有面子问题。
在结对编程中，任何一段代码都至少被两双眼睛看过，被两个脑袋思考过。代码被不断地复审，这样可以避免牛仔式的编程。同时，结对编程避免了“我的代码”还是“他的代码”的问题，使得代码的责任不属于某个人，而是属于两个人，进而属于整个团队，这样能够帮助团队成员建立集体拥有代码的意识，在一定程度上避免了个人英雄主义。结对编程的过程也是一个互相督促的过程，每个人的一举一动都在别人的视线之内，所有的想法都要受到对方的评价。这种督促的压力，使得程序员更认真地工作。结对编程“迫使”程序员必须频繁地交流，而且要提高自己的技术能力，以免被别人小看。但是要注意，每个人每天的高效率工作时段不超过3—4个小时。结对编程中驾驶员和领航员的角色要经常互换，避免长时间紧张工作而导致观察力和判断力下降。一对程序员完成预定任务之后，就可以休息，或者开展其他较轻松的工作。而不应该死板地按照工作日八小时的规定而继续编程。什么样的人适合结对编程？极限编程对工程师提出了更高的要求。这种要求不关乎技术水平，也不关乎学历水平或工作经验。这种要求是对一个人的心智、道德修养的更高要求。结对编程中，编码不再是私人的工作，而是一种公开的“表演”。程序员的代码、工作方式、技术水平都变得公开和透明，这也许是有些人不喜欢这一方式的原因。
在相互审核的过程中我们彼此之间相互合作，彼此之间开始对明白对程序有深入了解，可以加强复审的效果，我们在阅读了这本书后给自己规定了时间坚持持久，定时进行复审，一开始我们对需求和设计也是不了解导致前一段时间内的复审不能全面有效的进行，后来参考了《构建之法》茅塞顿开，发现了自己身上的不足之处构建之法真的是一本奇书，读完后感觉受益匪浅。而且在学习的过程我们也遇到过很多人在一起讨论问题，结果讨论的效率还不如两个人慢慢讨论效率高呢，但看了《构建之法》后，过去人一多我们也是陷入了书上写的“牵涉的人员众多，理解程度不一”，“由于人员众多，有面子问题”等，看完书之后，想了一会，继续在这本书才明白过来，所以我说这本书没点经验真的不能使人信服，由于此书多为使用真实样例所以难以与经验缺少的人产生共鸣，而大学生多为此类型的人，老师的书是一本说真话的好书，继续我们的话题我们通过这本书明白了一个道理用书上的话来说就是：“代码的责任不属于某个人，而是属于两个人进而属于整个团队”，而且这一次的结对作业，以及《构建之法》的指导我深刻的了解到了结对编程对我们的好处还是引用《构建之法》上面的话，各位看官请好好体会“结对编程的过程也是一个互相督促的过程，每个人的一举一动都在别人的视线之内，所有的想法都要受对方的评价。这种督促的压力，是的程序员更认真地工作。结对编程“迫使”程序员必须频繁地交流，而且要提高自己的技术能力，以免被别人小看”，我觉被别人小看，我倒是不在乎，不过前面说的，确实是神来之笔，把结对编程的好处悉数说完又深入解释了结对过程中程序员的心理变化，堪称神来之笔，这样发自肺腑感人至深的开导语言还有很多，我们我们看完这本书便可以受用终身了。
三项事件：
1,在编程的过程中我们遇到的问题就是正视自己的位置，我要作为一个真正的程序员来完成，不是作为普通学生，我做的是客户要求我们组做得任务，而不是一场作业。必须拿出端正的态度来面对这件事把任务做好。
2,在编程过程中面对功能三我们组弄了很多种解决方案但是统统没有达到助教老师的标准，真不知他是不是，，，怎么可能，不要妄作猜测，现在很多人都在猜测，总之我们的实现功能三的时候，想了很多的方法但还是失败了，在此向老师道歉对不起。
3，在讨论的过程中这件事已经在上面的体会中说过了，在此再一次强调是由于《构建之法》的帮助使我们的配合更加地有理有据开始明白真正的结对编程是一件多么重要的事了。
关于照片
我联系过我们的任课老师他不建议我把自已的照片发到网上，我真的不理解为什么你们会要我们的照片不是已经有了我们姓名和地址了吗？还要多少信息你们才能放心。我不知道是不是有哪位道上的大哥在心情不好的时候碰巧打开我们博客碰巧看到了我的照片，碰巧又打开了外面那个商人的博客看到了我的姓名和地址，又很碰巧的来到了我们学校，又很碰巧的找到，额，不，是遇到我，对，碰巧遇到我，然后这位大哥碰巧拿我来平息怒火，您说我应不应该把照片发到网上呢，毕竟网上人太多，好人看到了就走了，坏人看到了可能会碰巧盯上谁谁谁呢。毕竟谁也不知道坏人怎么想，而且社会呼吁大学生不要在网上暴露个人信息。。
