个人介绍

“衣带渐宽终不悔，为伊消得人憔悴”

我是来自计科一班的陈攀文，我是一个开朗热情，大胆勇于尝试的人。热爱编程，喜欢敲代码的感觉。加入了嵌入式团队，目前正在进行后端方面的学习，主要学习的是Java后端。我觉得学习后端能让我真正体会到一名程序员是什么样的，让我能够有更多的机会去编写代码。能用代码实现自己想做的东西能让我获得成就感。可是拘于学习的东西还不够，对于很多原理方面，底层方面的东西还不够了解，希望在以后的学习中能够学到更多这方面的知识。有自己的域名，虽然东西还没怎么做，现在只有前端界面（前端还是我女朋友给写的，我就只买了个服务器配了个环境）但是欢迎大家来看看 点这里
爱编程，但是我不太喜欢算法，虽然打心底我知道数据结构啊，算法啊是十分重要的，可是我还不太喜欢偏算法方面的东西。但是重要嘛，肯定是要下功夫的，题还是要刷的。

问题回答

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

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

小时候喜欢玩儿游戏，对电脑接触的比较多，所以对电脑有比较强烈的好奇心，想去更多的了解它的原理。计算机科学与技术这个专业也更多是偏向计算机原理方面的，算是计科院里面教授计算机原理比较多的一门专业，所以便选择了这门专业。

你认为过去一（两）年中接触到的课程是否符合你对你自己所在专业的期待，为什么？

比较满足自己的期待。在专业课中学习了C语言和数据结构。先学习一门语言能有助于后面其他语言的学习；数据结构也是基础中的基础。表明学校对计科专业学生的基础是十分重视的。包括今后将会学到的汇编语言，操作系统原理等等也证明了这一点。

你觉得你所在的专业是你喜欢的领域吗，它是你擅长的领域吗？

专业领域的话，我觉得计科专业更偏向硬件方面，因为后面会学嵌入式开发，其实我并不是很喜欢偏硬件的东西，就像介绍中说到的，我更喜欢后端。因为还没学嵌入式开发等等的东西，所以现在也还谈不上擅长与否，但是我相信现在积累一些敲代码的经验，以后肯定还是会学的比较顺利吧。

将来你会选择从事和你专业相关的工作吗？是的话给出你想去的城市、公司和岗位，否的话给出原因

会从事，毕竟现在学计算机还是比较好找工作吧，而且自己这些年又在这方面花了这么多时间。我还是想留在成都，公司的话还没想好，岗位就后端工程师。

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

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

能力的话确实太少了，除了所开的专业课，学了些Java，Java Web方面正在学，
目前能够用SSM框架做些简单的后台，但里面的原理这些还不太清楚，打算去学习一下。 代码量，如果写的所有代码都算的话，5000行应该是有，但是真正算是做东西的话，应该2000行左右吧。 最复杂的项目：C语言链表写学生管理系统，写的比较复杂（现在看来有的可以简化），而且因为当时初学链表，链表的各个操作也分开进行了很多测试和改进，最后写了接近700行。 然后的话就是用JAVA Web的一些基础操作去给一个前端界面接了后端，这个代码量不是很多，主要涉及各个层，例如表现层业务层数据层之间数据的传输，所以对于初学者的我来说，还是比较复杂。

离成为一个合格的本科毕业生，在专业知识、技能、能力上还差距哪些？

那差的可就多了，汇编、数字逻辑、操作系统等等重要的课还没开，自己也还没开始学。Web方面像并发啊，各个框架的原理啊这些东西都还没学，任重而道远啊。

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

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

我选择工作。大多数人考研是为了什么，还是为了之后找工作。既然现在有机会有能力去做好，为什么非要考研去做呢，在本科就努力学好技术，毕业就业，我觉得更好。而且我觉得以后在工作中学到的经验，可能会比读研学到的更多吧。

在这种选择下，你认为你相比其他同学来说有何优势，有何劣势？

优势: 有比较明确的方向，并且能付出行动。行动的话，团队给了一个很好的环境，一般没课的时候就在团队自习，然后一些比赛，会积极参加，并尽量去争取名次，比如盛特杯。
劣势：成绩上，可能还是不是特别好吧，绩点和排名就能很好的反映出来。只算得上中上水平，这方面还要加油

针对你的选择，你给自己的大三设定的规划安排是什么？

继续好好学习专业知识和后端知识，然后多看看别人的面试经验，准备春招秋招。

你对于实现自己的梦想已经做了或者计划做什么样的准备？

加入了团队里面有很多优秀的学长学姐和同学，资源十分丰富，是一个很好的平台。我觉得这算是我做的一个比较好准备和选择吧。

提出问题

问题一

软件工程师的思维误区

我看了书上P48-51的内容，对3.2软件工程师的思维误区有问题。这里主要讲了三个思维误区：不分主次、过早优化、过早扩大化。其实我觉得虽然“软件是‘软’的”，但在实际的开发过程中，适当的提前优化和扩大化还是有必要的。主次这个暂且不谈，因为项目在开发中，各种问题肯定会层出不穷，解决问题肯定是需要分主次的。但是优化、扩大，我觉得可以在来发中适当的进行，因为在实际开发之前的构想阶段，可能有些问题确实是想不到的，只有在开发中，代码的编写中，然后在编写过程中的测试中（此测试并非指最终测试，指的是调试或者前期的简单的测试）发现了问题，可以就做出一定的优化，同时需要扩大化时也可以经行适当的扩大，以适应需求或改进前期没有想到的问题。所以我觉得早期的优化和扩大化还是有一定比较的。

问题二

小强地狱

此问题出现在书本的P241-242上，主要问题是开发任务与测试需求之间存在的矛盾。我觉得过于追求开发新功能上，而不去管开发中遇到的某些bug会让开发有一些失衡。开发和测试的关系应该是相辅相成的。去完成客户需求需要开发人员和测试人员同时进行。因为某些bug没有及时修改而倒是测试人员无法进行测试，这肯定会影响工期，即使提前完成了开发，但是bug没有修复，还是没法满足客户的需求。所以我觉得“小强地狱”并不算一种很好的方法。更好的可以让测试与项目开发的人员多沟通，沟通出目前急需修改的一些bug（不修改就几乎没办法进行更多的测试），然后让一部分人去修改这些bug，让测试人员和开发人员尽量能够保持步调统一，这样可能是一种更好的方法。

问题三

招数：设计变更

此问题出自于书本的P326-328，主要问题是在项目的最后阶段，经用户的反馈之后，发现原设计有需要改进的地方，怎样权衡利弊，做出修改，交出成品期间会出现的问题。在此讨论期间，可能会出现这种情况：有bug需要及时修复，但是需要消耗较大的精力甚至成本。此时又有某些新功能需要添加，这些功能并不在之前客户的需求之中，但是得到了用户的反馈，因为在开发中，添加此功能并不需要改动太多原来已经做好的东西，但是需要更好的构建这个功能。虽然是可以使用DCR来进行管理，但是在开发中真正会怎么处理呢？

问题四

迷思之六：技术的创新是关键

此问题出自于书本的P348-349，主要是想告诉读者不要拘泥于“技术创新是‘关键’”的观念中，并且举出了“铱星计划”来佐证观点。我觉得作者所举得例子不能很好的作证观点。因为作者举出了一个“技术的创新”的实例，可这个创新在最后却没有收获到用户的认可和成功。我觉得这个例子作证的观点是“并不是所有创新都是能被大众所认可的”或者“创新之前要充分分析市场需求”。因为这个手机的出现，确实是技术的创新，可是最终却失败了，原因是因为它的想法有许多不靠谱的地方，或者说过分注重技术方面的实现却丢掉了商业模式等各个方面的分析，但这并不能和“关键”画上等号。这和“技术的创新是关键”的观念貌似没有太大的关系。我认为技术创新是关键，但同时也需要其他方面创新的支持。

问题五

迷思之八：创新者就是冒险家

此问题出自于书本的P354-355,主要是为了否定一些人认为创新者就是冒险家的观点。其实我觉得“创新者就是冒险家”这个观点的提出就不是很有必要，“就是”二字过于肯定。我觉得一般人而言，对创新的理解，可以是创业，去开辟事业，这确实需要承担风险。但创新也可以是更新，对现有的东西进行改进，进而得到新的东西。对于一些创新来说，根本就配不上冒险二字，比如去改进板凳所存在的不方便的地方，这种改变算是创新，但是并不需要承担风险。当然还有更多其他的例子。所以我觉得这个论点的提出其实不是很有必要。

源程序版本管理工具

Git

优点

适合分布式开发，强调个体。

公共服务器压力和数据量都不会太大。

速度快、灵活。

任意两个开发者之间可以很容易的解决冲突。

离线工作。

缺点

模式上比SVN更加复杂。

不符合常规思维。

代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

GitHub

优点：

GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首先，他可以作为一个版本控制系统和协作工具，用它来发布工作。

利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。

创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。

学习Git也有很多好处。他被视为一个预先维护过程，你可以按自己的需要恢复、提交出现问题,或者您需要恢复任何形式的代码，可以避免很多麻烦。Git最好的特性之一是能够跟踪错误，这让使用Github变得更加简单。Bugs可以公开，你可以通过Github评论，提交错误。

在GitHub页面，你可以直接开始，而不需要设置主机或者DNS。

缺点：

如果，你是Github使用新手，首先的挑战就是摆正心态——需要不断实践和时间。

他可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。

这是由设计者决定的，然而，一些人发现 GUI 有点混乱，选择CLI代替。一些开发人员学习主要使用Git命令，这样可以解释为什么他们不太喜欢GUI的原因了。稍加练习,命令的学习是不太困难的。然而，你喜欢天天写命令吗？特别是跟踪项目历史或解决冲突的时候。所以就有了另外一群喜欢GUI的人们。将提交、修改、移动文件等操作可视化，会有一个更好的体验。而这些，就如之前提到的，需要时间来适应。

如果，你专门在GIthub上工作，版本控制存储库就值得你拥有，也需要你长期付出。

Bitbucket

优点

支持Hg，最易学易用（但不是最强大的）的分布式版本管理工具。同时也支持Git。他的网页端的git仓库不如github好用，但是作为远端仓库足够了。

完全免费的闭源项目，还支持5人以内的合作开发。

提交大文件速度很快且不限容量

缺点

和GitHub相比，开源项目只有较少部分在Bitbucket中（大部分在Github里，是因为Bitbucket用户没有GitHub多？）