提问回顾与个人总结

一、提问回首

提问博客点这里

关于第一章中的“软件的非延续性”

经由这一学期的实践,我对软件的非延续性有了对照详细的熟悉。

在我们的项目中,后端涉及对照庞大的状态机,而可能一些小的输入转变就会触发状态机的改变,进而影响系统的运行状态。测试后端状态机是整个项目最难题、最庞大的地方,在这部门,软件的非延续性就体现得淋漓尽致。

而应对这种难题的方式也有许多,一方面,可以做充实的测试,只管笼罩状态机的每一条状态转移路径,另一方面,在设计时也要做好充实的思量,只管让系统的状态数较少,转移数较少,从而使得系统的稳定性提高,易于维护和治理。

关于第二章中提到的“单元测试”

在学期初提出的问题是

是否有需要追求100%笼罩率的单元测试

经由这一个学期的实践,我以为我找到了谜底,测试是必须的,但100%笼罩率的单元测试既不需要,不也现实。

在这个学期的项目中,我们的产物从前端到后端涉及到了浏览器、服务器、Docker、文件服务器、磁盘文件系统。其中,许多功效都是需要多个组件协同完成的,而单独处于一个组件内部的单元测试经常无法兼顾整体,例如,在服务器系统内就很难监控到Docker的运行状态,响应的单元测试也就很难开展。由于不存在一个组件可以接见和控制到整个系统的每个组件,若是真的存在这样的组件的话,那说明系统的设计也是欠好的,没有很好地实现系统条理之间的隔离,整个软件的耦合度对照高。

然则,这是不是意味着我们可以放弃对单元测试的要求而为偷懒找捏词了呢?不是的。

首先,单元测试依然起着十分主要的作用,拿修建楼房为例子,单元测试的作用就是保证每个砖块、每根钢筋的质量,虽然它很难保证整个楼房的蓝图设计是准确无误的,然则作为第一层保障,它可以有用地保证我们的最低层组件事情正常。

以我们的项目为例,在后端服务器实现中,会用到许多的工具类,这些类之间的耦合度很低,各自完成相关的一系列功效,为上层提供服务。单元测试在这里就可以施展很大的作用,对每个工具类的每个方式举行周全的测试,可以为未来进一步的开发清扫许多潜在的隐患。

而除此之外,我还熟悉到了测试不仅仅是单元测试这么简朴,测试是一门学问,响应的也有诸多经典的测试方式,例如,在我们的项目开发后期,经常接纳录制剧本的方式举行测试,通过浏览器录制一系列操作形成剧本,这个剧本可以重放,从而在软件开发历程中可以随时回归测试,保证之前剧本中包罗的功效运行正常。

以是,总结来说,测试十分主要,但100%的单元测试往往不切现实,但在单元测试无法笼罩的地方,必须要有其他的测试手段举行填补,要保证软件的每个环节都有响应的测试作为保障,才气在接下来的开发中保持软件的高质量。

关于第四章中提到的“结对编程”

在学期初提出的问题是

结对编程的开发方式开起来很美妙,然则在现实团队开发中真的有普遍使用吗

经由本学期的结对编程实践,我依然对当初提出的问题持保留意见,也尚不能完全认同结对编程中的所有优点。

在书籍中先容到结对编程有如下几个优点

  • 可以起到教学作用,手艺高的程序员可以辅助手艺较弱的程序员提高
  • 可以提高代码质量,由于代码的每个部门的质量都取决于一对程序员中在该方面手艺较高的一个
  • 可以提高团队凝聚力,促进团队交流,利于团队治理
  • 可以有用应对团队职员更改

针对这几点,我也想谈谈我在实践过接对编程后的明白和疑心。

  • 可以起到教学作用,手艺高的程序员可以辅助手艺较弱的程序员提高

关于这个优点我完全认同,在接对编程实践中,我从同伴身上学到了不少器械,不论是编程技巧照样设计艺术,同时,我有时也能够为他提供一些辅助和想法,应该是完全起到了相互促进的作用。

然则,在这个优点背后有一个问题值得思索,也是我所疑心的。这样的时间成本是否较高,一方学到器械的价值是另一方需要停下开发的脚步,而且,并非每小我私家都有成为先生的潜质,有的人手艺高明然则表达能力不强,让他们教授别人手艺或许不如让他人查阅相关资料来的效率高。同时,编程和头脑都是有节奏和状态的,打断编程者的延续输出实在对于编程职员来说是一件效率很低的事情,这样看来,这个教学作用的成本是否较高。

  • 可以提高代码质量,由于代码的每个部门的质量都取决于一对程序员中在该方面手艺较高的一个

这个优点我也完全认同,然则,在我实践历程中的体会就是,到达这个最优往往会履历一番周转。

当双方在某个设计点上意见纷歧致时,需要停下举行剖析,这自己没有问题,尤其是在双方手艺水平相差较大时,一方会主导话题,从而使得问题的讨论和解决较快。而当双方手艺水平相那时,问题就可能泛起,可能双方各有不错的设计,但这两个设计相去甚远,说服随便一方接受明白另一方的设计都是对照难题的事情。其本质就是默契问题,是否双方有很高的默契度,编程和设计习惯上气概一致,这些都影响着结对编程的效果和现实性。倘若双方无法保持高度默契,那么有时时间就会被虚耗在类似上面提到的场景上。

  • 可以提高团队凝聚力,促进团队交流,利于团队治理

这一点我完全认同,也以为十分现实,当下,许多公司也有手艺茶话会这样的流动,目的也是为了可以一边交流手艺、提高团队水平,一边也可以提高团队的凝聚力、促进团队交流。

  • 可以有用应对团队职员更改

确实有这方面的意义,然则我小我私家感觉这依然没有解决本质问题,这样的解决设施下,风险依然是在职员自己上,只不外将一小我私家变成了两小我私家而已。

而我以为更好的解决设施可以是完善相关的内部文档,每小我私家卖力各自事情局限内的手艺文档维护,这样可以有用地规避掉职员更改的风险。

这一点在这学期的强制转会中深有体会,据我领会,有的团队就将项目拓荒初期的学习和手艺文档维护了下来,从而使得转会新来的成员可以快速上手项目,团队的开发进度不会受到很大的影响。

关于第十六章中提到的“要成为领域的专家,才气创新”

在书中,作者的看法是这样的

这个想法看起来没什么错,我们不就是为了成为某个领域的专家,才来上学,拿学位,希望拿到学位之后成为专家,然后再最先这个领域的创新?然则统计数据解释,70%的创新者说,他们最乐成的创新,是在他们的特长领域之外发现的。

之后作者举出了HTTP的降生阿里巴巴的降生等例子,佐证上面的看法。

经由这学期的实践,我对这个看法有了一定的明白,也有了一些自己的看法。

在这学期,我们是自选项目,也算是做了一些创新性的设计实现,然则这背后是经由了一定的调研和学习才得来的。虽然不能说经由调研我们就成为了领域的专家,然则至少对领域有了一定的领会和认知,知道哪些是实现了的,哪些是空缺的,哪些器械由于没人想到以是没人做,哪些器械由于难度太大以是没人做。

固然,作者的意思不是说对某个领域闻所未闻就贪图在其中有所创新,而是说创新的领域纷歧定是自己最特长的领域。这一点,经由这学期的实践,我有了全新的明白。

创新和实现差别,创新更关注的是要站在一个应用者和设计者的角度去思索,而不是实现者或者架构师的角度,它更多关注的是需要什么而不是若何实现。固然,这两者都十分主要,单纯有想法但无法实现也无济于事。然则,这背后正是作者想要表达的意思,纷歧定每小我私家都有实现某个器械的能力,然则每小我私家一定都有想到、想出某个器械的能力。

那我们的项目为例,我们发现在初学编程时,环境的设置很贫苦,IDE的安装很贫苦,以是我们想解决这个问题,于是我们提出了自己的WEB版IDE,对这方面的需求提供了一定的支持。这个创意源自于我们的真实需求,同样,那些伟大的创意,也往往来自于真实的需求。这正是作者想要表达和论述的。

关于第十七章中提到的“磨合阶段”

经由这学期的实践,我发现没有磨合阶段的团队和无法磨合的团队都很少,以我们的团队为例,人人在最最先虽然意见不统一,然则经由一段不长的时间的调整和交流,很快人人在熟悉上就可以杀青一致。

我以为,除了一些极端职员难以融入团队,可能会成为团队的害群之马以外,大部门时刻,团队都是可以磨合和愉快互助的。

而在学期最先时,我提出了如下问题

若何判断一个团队是处于“磨合阶段”照样说这个团队的职员设置自己真的存在问题呢

针对这一点,连系我的实践体会,我以为,若是一个团队能够明确地完成分工,而且每小我私家都能够清晰自己的职责和义务,那么这个团队就可以继续互助下去。纵然最最先存在团队成员的进度不能很好地达标的情形,但也依然可以以为团队的职员构成自己没有问题,是可以互助的。

由于若是每个成员都清晰自己的义务和职责,那么这至少说明晰人人在事情和熟悉上杀青了一致,在这个一致杀青的基础上开展后续的互助都是有可能的。而倘若成员之间连分工和职责分配都无法明确,则要么是团队治理出了问题,PM没有很好地协调成员,要么就是团队成员无法杀青一致,整个团队内对义务和目的没有一个清晰的熟悉和掌握。

以是,我的明白是,团队成员之间能否对团队义务和目的有一个统一的熟悉和掌握是可以作为评判团队职员设置是否合理的一个主要尺度。

二、新的问题

实践出真知,经由一个学期的实践后,再回首最初提出的问题,确实显得有些稚嫩和缺乏实践了。

不外在实践历程中,我也产生了一些新的问题,下面提出来和人人配合探讨。

若何匹敌历史代码遗忘问题

这个项目总共历时2个月,从最初的搭建,到厥后项目功效越来越多,鲁棒性越来越强,这其中都是需要举行代码的修改和添加的。

然而,在项目后期经常会泛起一个情形,就是几周前的代码在几周后再次阅读时不能很快地回忆出其中的实现细节。

这里并不是想表达代码的可读性较差,纵然是在充实利用面向对象编程和函数式编程的优势的情形下,回首以往的代码依然要破费一定的时间去阅读。

特别是在系统的状态较多较庞大的情形下,这种问题尤为显著,需要破费对照多的时间理清晰系统的状态迁徙。

我以为,完整的设计文档和代码注释会有辅助,同时,设计多个小型专用系统来替换单一的多功效大型系统也会有所辅助。

然则我并无法知足于上述两种可能的解决方案,同时,由于问题露出较晚,以是我也没有机遇去实践磨练上述设施是否真的有用。

HashSet扩容机制在时间和空间上的浪费,远大于你的想象

以是在这里提出这个问题,希望能够获得辅助。

软件功效和软件平安性的矛盾

网络平安是一个很大的领域,而WEB应用依赖于网络,自然WEB平安也是一个很大的话题。

在项目初期,我们破费了不少时间在平安机制的设计上,甚至对于平安机制的考量一度影响到了我们正常功效与焦点功效的开发进度。

我们每小我私家都认可,在软件领域,软件的平安性无论对于用户照样开发者都是十分主要的,它关乎双方的利益。然则,在能力有限,或是缺乏响应的专业手艺职员的情形下,过多的平安设计思量经常会影响到功效的开发。

以是,我很疑心应该将平安机制设计放在软件开发的哪个阶段。

倘若在最初软件设计时就将大部门平安机制思量到并设计在最初架构中,那这样肯定会影响到软件的开发进度,特别是在缺乏专业手艺职员的情形下。

而若不在最初设计时将平安机制思量在内,而寄希望于在后期逐渐添加平安机制,那么很可能泛起一种情形,就是为了添加平安机制,软件架构需要一些更改,这有时甚至会损坏单元测试的可用性,由于更高的平安性背后往往是更低的便利性,可能会有一些原本可以正常事情的单元测试不能在新的平安机制下运行,这就又给回归测试带来的难题,进而迫使软件开发进入了一种对照危险的状态。

以是,我很想知道,在有限的条件下,应该若何平衡平安机制设计和功效开发。

三、实践知识点回首

需求阶段

在需求阶段,我学到的知识点是

需求调研不仅要保证提出的需求是真需求,同时也要保证我们的产物有优于同类产物的地方

我们的项目是WEB版的IDE,实在,这个领域的同类产物照样有不少的,然则我们在需求调研时提出了我们怪异的地方,即面向新手

我们提出的需求是,许多新手初学编程时会被诸如环境设置、IDE设置等一系列设置事情阻碍,而我们的目的就是为他们消除阻碍,能够提供一个开箱即用的编程环境。

那么,我们提出的需求是真需求吗?是的。

据调查,许多大一新生在编程学习的前半个学期都市对开发环境有着或多或少的疑心和不解。然而明白这背后的一系列内容又自己超出了他们现有的能力局限,那么,我们产物的使用人群和使用场景也就应运而生了。

而我们的产物是否有优于同类产物的地方呢?是的。

凭据调研,市面上大多数的WEB版IDE的功效都十分壮大,基本涵盖了非WEB版IDE的绝大部门功效。但同非WEB版的IDE类似,这些WEB版的IDE依然使用难度较高,需要一定的履历,也需要一定的设置,并不能做的开箱即用,而这就是我们产物的优势。

设计阶段

在设计阶段,我学到的知识点是

有用地分开义务为若干个子义务会有利于设计的希望

在我们项目最初的设计阶段,我们就将项目举行了分开,大略分为了前端、编辑器、后端这三个部门,而这三个部门又各自被分开为若干个更小的部门,然后针对每个部门的功效需求去单独设计。这样,一方面有利于强化对于项目的整体掌握,另一方面也有利于控制软件的庞大度,可以使得每个小部门都获得较优的设计和实现。

实现阶段

在实现阶段,我学到的知识点是

团队开发中的逐日例会十分主要,有利于每个成员掌握整体的开发进度

在alpha和beta阶段都有14天的scrum阶段,其中天天都要举行例会,在实现阶段的逐日例会是十分主要的。

一方面,通过逐日例会,每个成员都可以对照清晰地掌握团队整体的开发希望,进而便于计划自己未来几天的义务。

另一方面,也可以起到监视和督促的作用,在逐日例会上,人人都市汇报自己的事情希望,这在无形中就起到了督促作用。

此外,逐日例会也能够起到活跃团队气氛、促进团队团结的效果,逐日例会不仅是汇报事情的地方,也是团队成员交流的机遇。

测试

在测试阶段,我学到的知识点是

要经常回归测试,不要等到最后统一测试,那样往往费力不讨好

在alpha阶段,我们的测试基本上是在公布前统一举行的,在开发历程中的测试较少,以是最后公布前的测试事情十分重要。

统一测试的坏处在于,一方面,统一测试的事情量很大,面临一个初有体积的项目,要举行笼罩度较高的测试是十分耗时耗力的事情。另一方面,在最后统一测试的修复成本较高,在软件开发阶段发现并修正错误往往是对照容易的,然则当软件完成了整合,再举行测试并修正错误,那样的修复成本往往较高,由于在软件整合完成之后发现的BUG有可能是整合导致的,也有可能是某个组件自身带来的,这样不仅问题定位难题,而且修复时经常会涉及到多个组件,牵一发而动全身。

公布

在公布阶段,我学到的知识点是

推广十分主要,优异的推广能够助力让产物最终拥有大量的用户

在alpha阶段的公布环节,我们团队并没有十分重视产物的推广,因而导致在alpha阶段最终用户数量不多,响应的,收到的用户反馈也就较少,为beta阶段的睁开带来了一定的难题。

而在beta阶段,我们及早举行了公布和推广,有力地吸引了一批有用用户,他们为我们的项目提出了名贵的意见和建议,从长远来看,这将十分有助于我们产物的进一步生长和更新。

维护

在维护阶段,我学到的知识点是

要做好系统数据网络事情,在维护阶段要亲切关注系统数据纪录,及时发现系统可能存在的问题

在alpha阶段,我们的后端系统并没有设计太多的日志系统,用户的操作基本都没有被有用纪录下来,导致维护时泛起了问题很难定位。

在beta阶段,我们针对后端系统的设计强化了系统日志方面的实现,纪录了所有数据库查询操作、API接见操作等诸如此类操作的纪录,便于在维护时定位错误和排查隐患。

四、明白与心得

无论是小我私家项目、结对项目照样团队项目,都需要有一个思绪清晰的领导者(治理者)来掌握整体的前进偏向。

在小我私家项目中,自己是谁人治理者,在结对项目中,两人都是治理者,而在团队项目中,PM是主导的治理者,每小我私家也都介入其中。

为什么说这个治理者十分主要,由于在多人完成一项义务时,思绪统一是很主要的一件事情。每小我私家都有自己的主意,那样是无法拧成一股绳来互助的,需要有人来治理和协调,让人人的想法杀青一致,才气使得团队高效地互助。

同时,治理团队和治理软件开发周期也是一门学问。

治理团队涉及到协调人人差别的意见,只管不偏不坦,保证每小我私家的个性的同时又要保证团队的统一。要能够充实施展每小我私家的特点,只管知足每小我私家的兴趣和想法,这自己就是一项十分有挑战的事情。

而治理软件开发周期愈甚,软件开发涉及到多个环节,每个环节都有每个环节的义务和特点,在每个阶段都指定明确的目的对于定期完成软件开发而言有十分主要的意义。

同时,软件开发不仅是手艺的挑战,也是设计的挑战。

高明的手艺可以辅助程序员实现功效,然则并不能辅助程序员设计出优异的产物。软件开发往往细节之处见真功夫,这种功夫纷歧定是实现难度有多高,往往是设计思想上的巧妙。优异的设计可以让产物加倍易用,加倍具有粘性,让用户加倍依赖于产物。

这一点我在我们的项目中深有体会。我们的IDE主打易用,以是在许多地方的设计上都是精雕细琢,如功效的结构、UI的设计、项目的入口等等,都力图让用户能够快速上手,长期使用。

此外,我也有一些想举行反思的地方。

首先是和人人的交流方式上,我以为我一直存在一定的问题,同时,这也是团队互助中十分主要的地方。团队互助,人人不仅仅只是简朴的在一起做个器械,人际层面的往来对团队的建设也十分主要,优越的交流方式有利于提高团队的凝聚力,营造优越的团队空气。在这一点上,我以为我做的还不够,有时会将小我私家情绪迁怒到他人,也是谢谢人人对我的包容吧,能够让团队的互助一直很愉快。

另有就是缺乏思索,尤其是设计上的思索。好的软件开发职员会设计优异的接口和服务,让使用者一看就能觉出这是人人之作,利便易用的同时功效周全。这一点上我以为我做的还不够,许多时刻都是功效有了就可以了,而不再进一步思量若何优化接口,优化API设计,让调用者加倍利便地使用接口与服务,这一点在未来的软件开发设计上也是需要提高的。

总结起来说,这一学期的软工实践体验是很充实的。从单人项目到结对项目再到最终的团队项目,实践了差别模式下的开发历程,也最终取得了一个小有规模的产物,无论是历程照样效果都值得欣慰。同时,通过一系列的实践,我也深刻体会到了团队大型软件开发的难度和痛点,也为未来的进一步学习和生长奠基了基础、明确了偏向,从这些角度上讲,都是十分有益的。希望这个学期的实践可以成为未来软件开发生涯的一个好的劈头。

原创文章,作者:admin,如若转载,请注明出处:https://www.2lxm.com/archives/16672.html