软件工程心得

第一篇：软件工程心得

学习软件工程这门课程已经有一个学期了，整一个学期下来，应该说还是有许多值得肯定的地方的，其实在我看来，软件工程与其说是一门课程，不如说是一门思想。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于该门课程，成为了一个综合的一个能够解决问题的思想集合。

在上课的时候我还是很认真地去听老师所讲述的内容的，我觉得他的思想和我一向而来的培养计算机学生综合素质的理解还是在一定程度上不谋而合了，所谓的需求获取，那就是一个谈判，辩论，交流的过程，已经不是单纯的编编程序就能解决的问题了。从我所看到的听到的来说，我最怕的就是计算机系的学生被别人说成是个带着厚眼镜的，只能够在电脑前编编程序的，在交际场上不知道说什么而一个字都说不出来的人。我觉得这样的人进入社会之后是没有什么前途的，起码他们缺乏了与人沟通交流的能力。而这门课程在一定程度上给了我们这些学生一个机会来锻炼自己在另一方面的能力，设想一下，一个又有技术又能够与人交流合作的人所取得的成就自然要比一个单单只会编程序的人要大得多。

其次，这门课程教给了我们在完成一个实际项目时的一般程序及过程，我认为这是一份非常具有实际意义的教学内容。当我们在毕业之后，这是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，我们即使是从事与其它行业，不也是要从需求获取开始，一直有条有理地到最后成品的出炉吗？应该说这就是这门课的价值所在。无论是在上课，还是在学生会里面做学生工作，我都深深地感觉到，技术性的工作就好比变魔术，其实原理是非常简单的，甚至可以说简单的可笑，但是当你就是做出这么一个简单的东西出来之后，一些外行们有时候会用崇拜的眼光看着你，觉得你很厉害，很高深莫测。但是制作的过程他们却不知道，也许知道之后他们只是会哑然失笑，原来这个东西的制作过程是如此的简单。这个可以说就是技术的魅力了，而作为需求获取及之后的一系列过程则是类似于魔术揭秘的过程，但是作为这个秘密我们并不需要一揭到底，至于揭的程度如何那就是我们那就是我们学出的程度如何了，我们要让对方知道我们在做什么？以及如何去做？这些东西需要我们以一定的技巧叙述出来，所起到的作用就是能够让对方了解自己的进度，却又能够不让对方来干涉自己的工作过程。因为我们是技术员，对方只是外行，即使对方知道了这个魔术的操作过程，也并不代表他们就能够向变着魔术的我们来随便修改这个魔术的变法，况且我们能够用不同的过程来得出一个同样的结果，这个过程的得出的主动权如何掌握在我们的手上，就看我们如何以高明的方式来揭开这个魔术的谜底了。

当然了，在纯粹的理论上，我觉得开设这样一门课程是很成功的。但是毕竟现实里有太多的不确定的因素。最重要的因素就是授课的老师和听课的学生。这两个可以说是这门课成与败的决定性的因素。

作为老师方面来说，我觉得给我们上试验课的老师非常的优秀，作为一名了有十几年工作经验的老船长，看问题的确是有他自己独特的一套方法，我的话对他也是非常崇拜的。但是周日晚上的课程我还是有比较大的意见，首先，作为学生来说，最不希望上课的时间就是周五的晚上和周日的晚上，因为这是个我们进行调整的时候，前者的调整是为了假期的到来，后者的调整是为了准备学习的开始，这个时候的上课一般来说都是学生比较反感的。其次，对于我来说，原来小的时候非常崇拜那些有着高学历的人才，什么硕士，博士，博士后都是被放在神坛上的人物，觉得他们很厉害，走路都会散发光环。但是在我上了他们这些人的课之后我发觉我真的是很失望。作为一个具有高学历的人来说，他能够自己迅速的吸收知识这点的确是令人敬佩，但是他能不能够把自身所吸收的知识传授给他的学生，那就是一个未知之数了，虽然的确这是一门枯燥的课程，但是并不代表老师就可以在讲台上讲课没有一点激情，或者说没有一点能够让我们想听下去的欲望，这个不得不说是一件非常讽刺的事情。子不教，父之过；教不严，师之惰。虽然学生们也有一部分的责任，但是把一切责任都推到学生们的身上那也是非常的不公平的。

作为我们学生来说，当然也应该负起比较主要的责任。在大学里有了太多的基础课程，基础课程大多都比较枯燥无味，也许在第一个学期里我们还能够保持着新鲜感，但是在5个学期之后，可以说再有新鲜感就是一件比较困难的事情了，我们都已经开始变得迟钝了，现在出现了一门新鲜的课程，可能同学们比较难把那样不好的状态一下子改变过来。其次的，学生们没有认识到这门课程的价值。这门课的价值我已经在上面说过了，是不言而喻的。但是并不是每个同学毕业之后都回从事计算机行业，也不是每个同学都知道这门课程的意义已经不仅仅局限于计算机这个范畴，但是他们不知道，无知者无畏也。既然和我没什么关系，那我就不听，反正听了也没什么用，很多同学报着的就是这么个心态。对于这样的心态，我表示理解，也表示悲哀。在没有彻底了解一件事物的本质之前，我们是没有资格向这件事物随便的指手画脚的。最怕的就是在没有了解之前就把这件事物否定。如果有了这样先入为主的思想，那就比较没救了。所以作为我们来说，还是更需要得深入了解下这门课所起到的作用之后再下结论也不迟。只是有一点我还是觉得比较奇怪，现在被人嗤之以鼻的传销在当时能够吸引如此大的一批人，而且那些受害者明知道这件事情是不好的但是还会去做，就是因为“洗脑者”的口才说服了他们，那作为老师来说，如何来说服学生们来上一门正确的课程应该说是要相对的容易很多吧，但是我觉得这样的过程在我们的大学课程里真的是少之又少啊。今天在这里写了很多，算是我对软件工程这门课程的一点点心得体会，也许是正确的，也许在一定的程度上存在着观点的偏激错误，但是起码这些东西是我觉得存在着的一些问题，但愿软件工程这门课程能够开的越来越好，让更多的学生们能够从这门课程中受益，在以后社会残酷的竞争之中存活下来！

第二篇：软件工程课程心得

软件工程项目总结

在我们整个软件工程过程中，我体会到了许多，也学到了许多。

在项目要进行自由分组后，我们的项目小组便诞生了。我们小组由七个成员组成，在相互商量后我们也确定了我们组的项目，是做一个校园 b2c电子商务网站。我们也随即做了分工，由于我们团队只有我和另一名成员有类似的项目开发经验，所以我们便要担负起更重的任务。最后由于在整个团队中，对于界面开发这一块只有我的开发经验较深，所以我便担任了主要的界面设计人员。我们的项目也正式开始了。

需求调研和分析对于软件开发过程至关重要。我们在开发时如果不进行调研和分析，那么对于后来的项目进展将产生致命的后果。我们在项目的开发中便遇到了这样的问题。老师作为我们的客户，他对这个校园 b2c电子商务网站的要求便是我们必须了解的，我们也必须以客户的要求为根本构建我们的这个系统。我们开始自己随意的计划整个网站的设计，然后报给老师，老师作为一个客户并不是全部认同，随后我们也必须按着客户的要求更改我们的设计报告。我也明白了，再做一个系统时，必须随时和客户保持沟通，随时了解他们需要什么，他们想要什么功能。如果我们不去和客户沟通，不去调研客户的需求，做出来的系统即使在我们看来是一个很好，很完美的产品，但是如果客户不认同，那么我们所做的一切都是徒劳，还要返工去修改，费时费力。所以在做任何一个项目时，前期的需求调研和需求分析都是必须的，这是在做一个项目的基本，是关系成败的重要一环。

对于一个项目，它的需求设计也非常重要。在我们的校园 b2c电子商务网站开发的过程中，遇到了一些问题，如客户提交购买确认后，我们如何确定应该以什么方式将货物给客户，还有以什么确定货物的送达地点，客户的订单在哪里处理，订单以什么方式惊醒处理，在管理员应该实现的功能上反复增删等，这些问题很多都是由于设计不够清晰，不够完善而导致的。出现的这些问题很多都是非常棘手的，我们为了解决这些棘手的问题浪费了大量的时间，我们不得不在工程代码上改了又改，在数据库里增表、删表、加数据、减数据，当然，在文档里也要做出相应的修改以适应新的功能。还好，我们能及时地发现问题，通过相互

沟通讨论，问题也得到了解决。通过总结，我们也意识到，我们大家在做需求分析和进行需求了解时仅仅考虑了一些基本的功能，而至于管理员和客户之间的联系，以及具体的一些流程我们都没有深究，而导致我们到后期花费了大量的时间用于修复之前没有考虑周全而带来的问题。如果我们的需求设计能够比较清晰和完善，那么我们在开发过程中便会很明白的知道我们应该实现什么样的功能，在数据库里应该怎样建表，以什么方式插入数据，从而可以避免反复修改工程的问题，也能避免出现可能毁坏整个工程的问题。整个工程的需求设计对于一个项目的顺利进展至关重要。

对于文档在软件工程中的作用，我在这次项目开发过程中有了更加深刻的理解。文档在软件开发过程中是很有用的，文档是一项必不可少的东西，但文档也不能太多，太过繁琐，如果是那样就不太好了。首先我们要明确开发过程中为什么要写这些文档，文档的最根本的作用是为了更好的沟通。一个项目或产品可能需要延续很长的时间，开发过程中可能需要很多的环节，可能会遇到很多的问题和很多的解决的方法，这时，我们需要文档的帮助，我们需要有一个东西来记录，我们需要有一个共同的声音。文档只不过是一个准绳，将开发中的各个树枝树叶扶正。如果，这个准绳太多太紧，大树可能会发育的很高很直，但是就是有些畸形，如果这个准绳太少太松，大树可能就会变成灌木丛。文档的多少、繁简是有度的，绝对不能说越多越好。我觉得，文档需要说明解决问题的方法而不是解决问题的理论，因为解决问题的理论是在文档形成中做到的。文档完整即可，每一份文档说明一个问题，无需将多个文档的内容放在一个文档的里面。除了重要阶段形成文档，其它部分都只是讨论或者说是想法。不要让文档成为累赘，如果真是这样，我认为就是该考虑写这些文档的必要性的时候了。我们在文档的时候，一定要明白为什么要写这些。

在整个项目开发过程中，我们也同时遇到了许多程序接口问题，页面和功能相结合的问题，数据库建表的问题，这些问题都是源于我们项目小组成员之间的沟通不足。我深刻认识到，在项目开发时，项目小组中各个成员之间的相互沟通是非常重要的。如果我们要在功能方面作出修改，那么程序人员和页面人员及数据库人员就必须相互沟通，共同对整个程序作出相应的修改，这样才能避免最终整合时出现问题。

在这十个周里，我还对软件工程有了新的理解。在我以前的理解当中，软件工程，无非就是一个人或者几个人或一个团队集中在一起进行编写代码的工作，以实现开发出所用的软件。但现在我明白了，软件工程的作用，就是告诉人们怎样去开发软件和管理软件。具体地讲，它表现在与软件开发和管理有关的人员和过程上。所以，软件工程就不仅仅是单一的编程过程了。它包括了系统分析->建模->概要设计->详细设计->编码->测试->维护。编码可以理解为编程，这个只占总时间的20％左右。编程只是其中的一小部分。

在这次项目里我完成了许多工作，在界面设计上我完成了，首页、全部的商品页面、全部的用户页面及部分管理员页面的制作，在后期项目整合过程中修改了功能和界面结合时出现的bug，还有数据库插入数据及解决数据库集中整合时出现的问题。这些工作我都顺利完成了，虽然并不能算是非常的出色，但也算是尽力了。现在看到自己辛劳的成果，我感到很欣慰。

当然，在这次项目过程中我也发现了自己的一些问题。如现在的网站开发技术还不够强，在和小组成员相互沟通上还不够积极等。我希望以此为契机，在将来的项目开发中能做得更好。

第三篇：软件工程试验心得

心得体会

学了一个学期的软件工程课，终于知道了个软件工程的大概。学的时候总觉得很抽象，理解起来好像不难，但总是摸不着头脑一种很茫然的感觉。学习的过程中和一个宿舍的同学一起做了个小型管理系统的开发，觉得还是有点收获的，对于开设这门课的意义也有所领悟，现在就将我对这门课的体会以及在项目开发过程中遇到的一些问题简单的归纳一下。希望在以后的学习中不断的提高吧。

曾经以为程序就是软件，软件就是程序。现在知道了二者的不同之处，这是学习这门课程第一个收获。事实上在软件开发的早期阶段这也不能说是错误的。那个时候开发的软件都比较简单。当然可以把软件理解成程序，直到软件作坊的出现，使软件在程序的基础上加了个说明。以前做过的一些小型的软件比如加密软件，也只是在程序旁边附上一个软件的说明，看来已经很接近作坊了。不过大的项目没有接触过，用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生，使得人们不得不探索新的解决方法。这个时候软件工程应运而生了。

掌握软件工程化的思想，对于负责软件开发的管理人员（领导）更为重要。曾经看到过这么一句话，“坐在指挥台上，如果什么也看不见，就不能叫领导。软件工程将有能力的人团结在一起，然后把他们变成工人，因为工业化的生产是效率最高的。这就是根本所在。没有软件工程管理，简直就是乱来，就好象缺乏宏观控制的国家一样，会乱七八糟。

软件除了程序还要有使用和维护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、维护文档以及使用手册。

软件开发特别是大型软件是一项浩大的工程,需要几个人、十几个人、几十个人甚至几百个人合作开发几个月、十几个月甚至几年。要保证系统的协调性、统一性和连续性,就需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费一定的时间和精力,但是“磨刀不误砍柴功”,它相当于把今后开发过程中开发人员都要遇到的问题提前做了一个考虑。有了开发规范,在后续的开发过程中,设计人员就不必每次考虑如何为一个字段命名,编程人员也不必去想某个程序的结构和布局应当 怎样,测试人员也有了判断程序对错的标准。它约束开发人员的行为和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契,以便形成整个系统的和谐步调和统一风格,也便于今后的系统维护和扩展工作。

第四篇：软件工程实践心得

软件工程（SE）

软件是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。软件工程（Software Engineering,简称为SE）是针对软件这一具有特殊性质的产品的工程化方法。SE涵盖了软件生命周期的所有阶段，并提供了一整套工程化的方法，来指导软件人员的工作。任何事物都是从无到有的，软件当然也不例外。上世纪中期，软件产业从零开始起步，经过半个多世纪的发展，其大致经历的3个阶段：程序设计阶段、软件设计阶段和软件工程时代，现已成为推动人类社会发展的龙头产业，随着信息化时代的发展，软件对人类社会也将越看来越重要。人们对软件的认识自然经历了一个由浅入深的过程，在得到巨大需求的同时，也遇到了一系列严重问题，即软件危机。所谓软件危机，是指在计算机软件的开发和维护过程中所遇到的一些严重问题，其实质是软件产品的供应赶不上需求的增长。概括的说包含两方面的问题：

一、如何开发软件，以满足不断增长，日趋复杂的要求；

二、如何维护数量不断膨胀的软件产品。为研究和解决软件危机，一门新兴的学科——软件工程，应运而生。

软件工程的概念是为了有效地控制软件危机的发生而被提出来的，它的中心目标就是把软件作为一种物理的工业产品来开发，要求“采用工程化的原理与方法对软件进行计划、开发和维护”，它的主要对象是大型软件，它的最终目的是摆脱手工生产软件的现状，逐步实现软件开发和维护的自动化。软件工程的概念自提出来后，经过几

十年的发展，虽然软件危机没有得到彻底的解决，但在软件开发方法和技术方面已经有了很大的进步，提出了软件工程知识体系、软件工程三段论、软件工程生存期模型、服用原则等等。

软件开发过程大致经过7个阶段：可行性分析、需求分析、概要设计、详细设计、编码、测试、提交与维护。接下来逐一分析本人见解：

一、可行性分析：顾名思义，就是看项目究竟“能不能做”。有3个方面：技术可行性、经济可行性和操作可行性。要确定项目，首先要客观的、科学的了解项目的规模、难度和时间限制，才可以确定应该投入多少人力、物力和财力去做这个项目，必须准确的估计项目的规模与难度。看项目是否有价值去做，如果没有价值，就放弃；如果有价值，就要看目前的资源是否能满足项目的开发。如果项目有价值，且有必需的资源，那么就可以确定能做这个项目了。

二、需求分析阶段：解决“做什么、不做什么”的问题。围绕两个核心问题开展需求分析：应该了解什么？通过什么方式去了解？

一、了解什么：应该先了解宏观的问题，再了解细节的问题。最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适的技术来实现此需求。同时，需求说明不可有额二义性，更不能前后矛盾，如果有二义性货前后相矛盾，则要重新分析此需求。然后，选择合适的生存周期，建立合适的需求模型；

二、通过什么方式去了解：直接与客户交谈；有些需求客户讲不清楚，分析人员又猜不透，这是就要请教行家。需求分析是非常重要的阶段，如果做不好 的话，后果很麻烦。

三、概要设计：解决“怎么做”的问题。将需求描述的“做什么”问题变为一个实施方案的创造性过程，使得整个项目在逻辑上和物理上能够得意实现。概要设计是第一个开发活动，也是最重要的活动，是软件项目实现的关键阶段。设计质量的高低直接决定了软件项目的成败，缺乏或者没有软件设计的过程会产生一个不稳定的、甚至是失败的软件系统。一个良好的软件设计是进行快速软件开发的根本，没有良好的设计，会将时间花在不断的调试上，无法添加新功能，修改时间越来越长，随着给程序打上一个有一个的补丁，新的功能需要更多的代码实现，就变成一个恶性循环了。概要设计是软件设计级别中的高级设计，是从需求出发，描述了总体上系统架构应该包含的要素。概要设计尽可能模块化，因此描述了各个模块之间的关联，主要是根据需求规格或规格定义，合理、有效地实现产品规格中定义的各项需求，完成软件模块的划分并描述模块之间的关系，并不断分解系统模块，从高层分解到低层分解。它注重框架设计、总体结构设计、数据库设计、接口设计、网络环境设计等，将产品分割成一些可以独立设计和实现的部分并保证各个部分可以和谐的工作。此过程中画数据流图、IPO图、E-R图、界面设计等。

四、详细设计：解决“具体做什么”的问题，将解决问题的办法进行具体化。软件设计的低级设计，亦即详细设计，主要描述实现各个模块的算法和数据结构以及用特定计算机语言实现的初步描述，是针对程序开发部分来说的，但这个阶段不是真正编写程序，而是设计

出程序的详细规格说明，这种规格说明类似于其他工程领域中工程师经常使用的工程蓝图，程序员根据其中所包含的必要的细节写出实际的程序代码。用另一种方式说就是，详细设计是将概要设计的框架内容具体化、明细化，将概要设计转化为 可以操作的软件模型，但在实际项目进行过程中，依据项目的具体情况和项目要求，这个过程可能可以省略（逻辑上没有省略，表现在概要设计阶段或者编码阶段），直接按照概要设计进行编码；不过，个人认为最好有，有详细设计可以更好的保证编码顺利的进行，可以预先扫清编码过程中的障碍，提高代码的质量和编码的效率。主要包括模块描述、算法描述、数据描述，可以采用图形、表格或者文字描述等方式表达出来。

五、编码：实现项目。由项目的概要设计和详细设计，将设计变为代码需要通过编码过程来完成。实现设计有很多种选择，有很多实现语言、工具等可供选择，但一般而言，在设计中会直接或间接地确定了实现语言。编码过程的一个主要标准时变成与设计的对应性和统一性。如果编码没有按设计的要求进行，设计就失去意义了。设计过程中的算法、功能、接口、数据结构都应该在编码过程中体现。如果需求发生变更，设计业对应地发生变更，同时代码也应该一致地发生变更，这可以通过配置管理配置控制。可见，如果编码和设计不一致，很容易“跑偏”，走火入魔。编码时要严格遵循编码标准和规范，并提供必要的程序注释，增加可读性。另一个就是重构的理解，所谓重构是对软件内部的一种调整，目的是在不改变软件基本功能和性能的前提下，提高其可理解性，降低成本，当添加功能、修改代码和复查

代码的时候，更不要错过重构，另外，重构可以和设计互补。还有一点值得注意，要在必要的时候部署编码文档。

六、测试：看软件是否符合标准。软件编码完成之后，将软件提交给用户之前，需要对软件进行测试，这是保证软件产品质量的一个重要标准，也是评估产品质量的主要手段。软件测试是从软件工程中演化出来的一个分支，有着非常广泛的内容，并且随着软件产业的发展，它已经变得越来越重要。软件与生俱来就可能存在缺陷，为了防止和减少这些可能存在的缺陷，进行软件测试是有必要的，测试是最有效的的排错和防止缺陷和故障的手段。最原始的测试莫过于直接运行软件了，后来测试手段逐渐多样化。测试手段有静态测试、动态测试面向对象的测试、自动化测试等等之分。静态测试或称静态分析是指一种不通过执行程序来进行测试的一种技术，主要是检查软件的表示和描述是否一致，覆盖程序的编码格式、程序语法、检查独立语句的结构和使用等，主要包括代码检查、静态结构分析、代码质量等等，可以通过人工进行，亦可借助工具（如：语法分析器）自动进行。动态测试是运行被测试的程序，通过输入测试用例，对其运行情况进行分析，以达到检测的目的，显然动态测试封像我们通常意义上的“测试”。动态测试主要包括白盒测试、黑盒测试、灰盒测试（介于黑盒和白盒之间）。其他测试不再一一介绍。

七、提交与维护：测试完之后，就要把软件交给用户使用了。提交不是剪裁，给人家就行了，还要教会客户怎么使用这个系统。如果用户不会使用系统，就会不满意系统的性能，那之前的努力就白费了，打水漂了。为了保证成功地将我们开发的软件提交给用户，我们需要对用户进行培训，同时提交必要的文档及用户手册软件。维护就不用多说了，就是售后服务了。维护需要分析人员、编码人员和设计人员等角色的参与，有纠错行维护、适应性维护、完善性维护、预防性维护等。维护后，要写软件维护过程文档，至少提交一个软件维护记录。

以上是软件工程及其几个阶段的介绍，知道怎样开发软件只是软件工程的一部分，搞好团队合作也是很重要的。项目是一个很大的工程，需要一个团队的统筹规划，团结协作，集思广益，举一反三，才能够按预期完成。

第五篇：软件工程课程心得

软件工程设计总结

在我们整个软件工程过程中，我体会到了许多，也学到了许多。

在项目要进行自由分组后，我们的项目小组便诞生了。我们小组由七个成员组成，在相互商量后我们也确定了我们组的项目，是做一个图书管理系统。我们也随即做了分工，由于我们团队只有我和另一名成员有类似的项目开发经验，所以我们便要担负起更重的任务。最后由于在整个团队中，对于界面开发这一块只有我的开发经验较深，所以我便担任了主要的界面设计人员。我们的项目也正式开始了。

对于文档在软件工程中的作用，我在这次项目开发过程中有了更加深刻的理解。文档在软件开发过程中是很有用的，文档是一项必不可少的东西，但文档也不能太多，太过繁琐，如果是那样就不太好了。首先我们要明确开发过程中为什么要写这些文档，文档的最根本的作用是为了更好的沟通。一个项目或产品可能需要延续很长的时间，开发过程中可能需要很多的环节，可能会遇到很多的问题和很多的解决的方法，这时，我们需要文档的帮助，我们需要有一个东西来记录，我们需要有一个共同的声音。文档完整即可，每一份文档说明一个问题，无需将多个文档的内容放在一个文档的里面。除了重要阶段形成文档，其它部分都只是讨论或者说是想法。不要让文档成为累赘，如果真是这样，我认为就是该考虑写这些文档的必要性的时候了。我们在文档的时候，一定要明白为什么要写这些。

在这一周里，我还对软件工程有了新的理解。在我以前的理解当中，软件工程，无非就是一个人或者几个人或一个团队集中在一起进行编写代码的工作，以实现开发出所用的软件。但现在我明白了，软件工程的作用，就是告诉人们怎样去开发软件和管理软件。具体地讲，它表现在与软件开发和管理有关的人员和过程上。所以，软件工程就不仅仅是单一的编程过程了。它包括了系统分析->建模->概要设计->详细设计->编码->测试->维护。编码可以理解为编程，这个只占总时间的20％左右。编程只是其中的一小部分。

当然，在这次项目过程中我也发现了自己的一些问题。如现在的网站开发技术还不够强，在和小组成员相互沟通上还不够积极等。我希望以此为契机，在将来的项目开发中能做得更好。