第一次作业—初始博客

格式描述：

问题	链接
这个作业属于哪个课程	课程链接
这个作业要求在哪里	作业要求
我在这个课程的目标是	课程目标
这个作业在哪个具体方面帮助我实现目标	具体实现
作业正文	作业正文
参考文献	参考文献

课程目标：

我在这门课里的目标如下:

了解并体验软件开发流程，体验在软件开发的各个阶段的内容

决定自己以后的方向

磨练技术，准备实习

具体实现：

这次作业能够帮助我实现的目标是：

决定自己的方向

了解各种源代码托管软件

借鉴他人经验，少走弯路

学会如何书写文档

作业正文

1. 关于我和我的博客

我的博客

关于我:

我是一名技术菜的出奇的程序员，喜欢阅读和美食。自己怀着积极的态度，但是却往往坚持不下去。间断式的努力让我时常亢奋，亢奋期一过就会陷入低谷。在困难面前徘徊，在徘徊中失去方向。不过自己却很乐观，毕竟没到最后发生的所有事都是好事。自己还特别喜欢看书，薄弱的记忆力让我很快的忘掉自己读过的书，有些时候还会因此陷入回环，读了又忘，忘了又读，直至放弃。

2. 阅读与思考

1. 回想一下你初入大学时对你所在专业的畅想

当初你是如何做出选择你所在专业的决定的？

说起这个，那可是说不尽的辛酸啊！当时选软件工程方向是因为在高中的时候和信息老师的儿子的关系比较好，经常和他聊天，天天听见他说一些关于计算机方面的知识，当时我说这个很有趣的时候，他告诉我他爸是软件工程的，你以后大学可以选择这个专业，专门研究这些，你应该非常感兴趣。于是乎，我就填了这个，真的坑啊，我忘了他爸的光头啊！！！
你认为过去一（两）年中接触到的课程是否符合你对你自己所在专业的期待，为什么？

说实话，我还是有点小失望的，大一来了天天在吐槽之中，什么鬼啊？为什么还要学物理啊？我们不是学计算机的么？怎么再学这些啊，看着少得可怜的专业课，我陷入了沉思，后面也可能就麻木了嘛，毕竟学着快过时的技术，了解着计算机的历史变迁，还是挺有趣的。
你觉得你所在的专业是你喜欢的领域吗，它是你擅长的领域吗？

不是，也不是擅长的领域。虽说和当初的期待有所差距，但总的来说可以接受，生活不就是这样的么，我们总是得不到自己喜欢的东西。作为一名码农，就准备好好学习，我也不知道未来会怎样，但是奋斗总是没错的。
将来你会选择从事和你专业相关的工作吗？是的话给出你想去的城市、公司和岗位，否的话给出原因

会呀，毕竟自己只有计算机这一技之长。如果可以的话，我想呆在成都成为一名独立开发者，比起金钱，我更崇尚自由。

2. 对照前人们走过的路和描述未来发展，现在的你

自我感觉你已经具备的专业知识、技能、能力有哪些？已经写过的代码量是多少？描述你做的最复杂的项目/作业。

emmmm，这个我也不太确定有哪些吧，有着前端开发，也会web后端开发，会写微信小程序，也会开发C++,做过机器学习，也玩过图形学。但这些依旧不是我所热爱的，我还在寻找着自己的方向。代码量我也不知道有多少，反正应该不少了吧！最复杂的话应该是最近的主动学习算法了吧，大量的数学知识和全英语的论文与文档耗费了我大量精力。奇异值和SVN,PCA，TSNE的概念令人眼花缭乱。
离成为一个合格的本科毕业生，在专业知识、技能、能力上还差距哪些？

差的有点多，操作系统，编译原理,数据结构，数据库等这些都相当晦涩难懂。答辩能力也差得很多。

3. 目前是一个人生选择的十字路口，考研、工作、考公、出国，不同的选择在大三就有不同的努力方向。而无论考研还是工作的每条路径，也有许多不同的分支。

对照以上你阅读的前人们的经历，你的选择是什么？

我呀，应该是考研加工作吧，46分，很正常，我更倾向于工作的。
在这种选择下，你认为你相比其他同学来说有何优势，有何劣势？

感觉没有优势，每个同学都很努力，我只有和他们一样学习才能勉强跟上他们，劣势就稍微有点多了，我的知识储备和他们根本不在同一个量级上了，毕竟我的记忆力那么差。
针对你的选择，你给自己的大三设定的规划安排是什么？

努力啃书，努力补充数学知识，多看看英语文档，多学学以后就业能用的前沿技术。
你对于实现自己的梦想已经做了或者计划做什么样的准备？

差太多了，如果将自己的梦想比作高楼的话，我现在应该还在运建筑材料，做的准备应该是地基打了几根柱子吧，让自己能够看得更远。

3. 问题
- 我在第三章55页看了职业发展—考级之路这一段，有个问题“这些证书真的有企业认可么？行业认可度怎么样？”，我查了一些招聘要求，发现行业对这些证书不太认可的样子，我的困惑是“现在去考这些证真的有必要么？他们的认可度不太高的样子。”
- 我在第四章64页看了这一段文字"代码风格的原则是：简明，易读，无二义性"，有这个问题“怎样才能算是简明易读？每个人的知识面不一样，对代码认知也不一样。”。我查了资料，有这些说法"我们没必要为了别人而修改自己的代码，自己的代码整洁和注释良好就可以了。"，根据我的实践，我得到这些经验“ 个人觉得代码也不是写的易懂越好。团队开发时，因为每个人的代码风格都不一样，所以别人的代码写的再易懂也只是相对他自己来说比较容易看懂。所以这时候就有一些代码规范需要大家去遵守，但是代码规范又不是具体到某一点的东西，只能从大体上让代码变得整洁。总之，写代码的时候，要遵守一些常规的代码书写规范，不要有什么反人类的操作。最重要的是关键代码加注释！关键代码加注释！不然几个月以后，再简单地代码，自己也会看不懂的，怎么降低沟通成本呢？ ”。但是我还是不太懂，我的困惑是“是不是我们以后工作时写代码时只需要写上完全的注释，而不用向上兼容代码的使用者呢？”。
- 我在第六章了解到了敏捷开发，了解到他有很多优点，在网上查询的时候发现我们国家绝大多数的互联网公司都在使用着敏捷开发，但是，我发现网上的大部分的文章都对敏捷开发持有不友好的态度，甚至scrum.org的创始人Ken Schwaber，也是Scrum的创造者之一，他在他的博客上提到了在中国推行敏捷思想的文化障碍。我的困惑是“既然敏捷开发在国内受到文化差异的影响，甚至已经丢弃了敏捷开发所带来的优点，为什么这么多互联网公司还是在乐此不疲的采用敏捷开发呢？”
- 我在第九章整体这一章发现软件公司似乎并没有对项目经理进行强硬的技术要求，也就是说，项目经理可能是一个既不懂技术，又不懂测试的人，那么，身为程序员如何明白的表达这个需求做不了之类的观点？项目经理又如何让一堆技术人员明白他的要求呢？又何以服众呢？
- 我在第十三章这一章发现书中提供了很多有效的测试方法，在这里我有一个问题，是测试基本都是软件工作人员写的，他们不可能了解完所有BUG，什么样的测试才是有效的测试和全面的测试呢？毕竟人的考虑是有限的。我通过一篇博客了解到对于一个大型的，拥有足够多用户的软件产品来说，这个软件可能遇到的情况，也是”荒诞“的。因为一个软件开发者（团队），永远无法在测试中穷尽他们设计的软件会被怎样的使用，和遇到什么样的状况。，但是，我还是想问，是否存在一种标准去量化这些测试的有效度呢？
4. 版本控制工具

1. Git
```
优点： 
1、适合分布式开发，强调个体。 
2、公共服务器压力和数据量都不会太大。 
3、速度快、灵活。 
4、任意两个开发者之间可以很容易的解决冲突。 
5、离线工作。 
缺点： 
1、学习周期相对而言比较长。 
2、不符合常规思维。 
3、代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
```
2. SVN
```
优点： 
1、 管理方便，逻辑明确，符合一般人思维习惯。 
2、 易于管理，集中式服务器更能保证安全性。 
3、 代码一致性非常高。 
4、 适合开发人数不多的项目开发。 
缺点： 
1、 服务器压力太大，数据库容量暴增。 
2、 如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。 
3、 不适合开源开发。但是一般集中式管理的有非常明确的权限管理机制,可以实现分层管理,从而很好的解决开发人数众多的问题。
```
3. VSS(VisualSourceSafe)
```
优点:
  可以锁定核心代码，因为他的工作方式是一个文件只能由一个用户修改
缺点:
  工作效率低下，只适合小团队开发
```
4. CVS(ConcurrentVersionSystem)
```
优点:
    可以使多个用户并行工作。这样对于正在编写软件的项目团体有利。
缺点:
    版本控制某个项目下的一些核心文件比较困难，假如团队中的每个人都写文件的权限。这样往往会不小心的让核心代码被修改。
```
5. Microsoft TFS
```
优点: 
    可以在VS中的任务版上看见需求和项目进展。可以和VS无缝对接。
缺点:
    维护和搭建比较困难。
```
6. Trac
```
优点: 
    良好的扩展性，非常灵活的定制各种要求
缺点:
    中文化太少，核心功能太少，需求和缺陷没有分离
```
7. Apple XCode
```
优点：
    可以自动创建分类图表。自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：
    更新版本后，某个插件可能会失效。
```
8. BitKeeper
```
优点:
    简单: 非常易用的命令行接口 
    可伸缩: 嵌套的源码库，类似子模块 
    精确: 可跟踪文件的各种操作 
    安全: 所有文件访问都会经过统一校验
    可辨识: 源码注解即时生效
    快速: 高性能可伸缩，支持超大规模项目
    免费: 使用 Apache 许可证
缺点:
    不是很灵活
```
9. Darcs
```
优点:
    没有中央服务器. 任何一个本地repository都可以既是客户端也是服务器, 节点之间可以任意同步.
    本地epository也可以看作是个完整的branch
缺点:
    不易管理
    windows版有很多bug
```
10. Mercurial
```
优点:
    1. 跨平台
    2. 封装好
缺点:
    1. 分支管理不灵活。
    2. 支持社区略差。
```