人工智能应用开发流程的权衡
文章目录前言一、复杂和简单的取舍二、人与机器的平衡三、开发和运行的融合总结前言人工智能应用开发过程的挑战很多,主要表现在三个方面:①开发流程复杂冗长;②算法技能要求高,需要应用开发者熟悉算法;③应用维护很频繁,可能超过传统软件应用。因此,考虑到这些挑战,往往就需要在开发过程中做一些权衡。下面将针对这三种挑战,依次分析如何有效利用平台优势和业务具体场景,做出最佳权衡。
一、复杂和简单的取舍由于人工智能应用无处不在,可以与各行各业相结合,所以人工智能应用的开发需要足够灵活,能够适应各种行业的需求。但是往往灵活背后的代价就是复杂,尤其对于人工智能应用开发来说,其天然具备较高的复杂度。 在开发人工智能应用之前,同时需要业务经验知识和人工智能经验知识,这样才能设计出合理的方案。对于人工智能应用开发全过程的每个处理步骤而言,输入数据的统计分布、输人数据的覆盖范围、最适合的处理逻辑、输出都是不确定的。这种不确定性会不断传递给后续的处理步骤。随着处理步骤的增多和数据的不断变化,可能需要增加、减少或改变后续的处理步骤,或者改变某个处理步骤中的具体逻辑。因此,人工智能应用开发过程其实是一个不断试错、不断调优、不断迭代的过程,很难一次性开发出一个可以满足要求并直接部署的人工智能应用。这就是人工智能应用开发过程天然具备的复杂性。 为了降低这种复杂性,通常需要固化一些开发流程模板,可以基于模板来开发自己的人工智能应用,不需要全部的灵活度,但是有时候足以解决当前面临的问题。当然这种模板也可以被用来二次加工、不断迭代和优化。这种基于已有模板的开发方式更加简单,也更容易解决相对受限领域的具体问题。
二、人与机器的平衡人工智能应用开发需要利用人工智能算法来处理数据,因此开发人员必须同时具备软件工程和人工智能方面的知识和技能,开发门槛相对较高。虽然基于工作流模板的开发方式可以大幅降低人工智能应用开发门槛,但是开发者(工作流的使用者)仍然需要按照工作流的每个处理步骤不停地迭代。如上所述,人工智能应用开发过程其实是一个反复迭代的过程,并且需要较强的人工干预。 大多数情况下,人工干预的程度也跟待解决问题的难度强相关。如果问题没有特别复杂,一般采用一些简单的参数调优即可,和软件工程师对数据库性能参数调优样。对于一些非常经典和成熟的机器学习算法,算法的架构基本相对稳定,即使是算法工程师也未必会对其进行大幅度的修改,更多的是一些小范围优化。这些超参数包括但不限于算法本身的一些阈值选择或训练策略选择等。因此,大部分开发者为了快速将算法应用到实际问题中,通常基于经验对这些参数进行调节,从而找到更好的算法和模型。但是如果有更强的机器,人工只需定义好规则和搜索空间,就可以利用机器强大的算力来做参数的自动选择和调优。这个调优过程就转变为一个自动化搜索过程。 现在一些传统的人工智能算法都逐渐成熟,大多数可以借助大集群算力和一定的搜索调优算法来完成最优算法的自动选择、优化和训练。 因此,很多人工不断进行调优、迭代的实验过程,逐渐地都可以交给机器来完成,尽量减少开发者的负担,这就是人与机器的平衡。如果要在算力上多投入一些,就可以在人工上少投入一些,反之亦然。开发人工智能应用需要在人和机器方面做一个平衡。人工智能应用开发平台所能够提供的是更多的灵活性和层次性,能够适应不同比例的人力投入和机器投人。
三、开发和运行的融合在人工智能应用开发和部署之后,需要及时维护。在维护阶段,用户可以选择应用指标监控模块来实时查看人工智能应用的推理效果。如果推理效果不满足要求,则需要手工或者自动维护,将不合适的数据回流到开发态。然后开发者可以重新查看和理解这些数据,并基于这些数据对已有人工智能应用进行迭代优化。 由于数据的变化会严重影响人工智能应用推理效果的好坏,因此人工智能应用的迭代需要非常及时。这也就使得人工智能应用的开发态和运行态紧密结合,形成一个闭环。对于有些可以自动维护并自动进行迭代优化的场景,这个闭环基本可自动运行,仅需在人工智能应用版本更迭时进行人工审核。 未来,随着人工智能应用的进一步复杂化,包括其内部模型本身的复杂,以及运行态环境的复杂(包括端、边、云),进行人工智能应用开发态和运行态的融合将更为必要,并且这种融合通过人工智能应用开发平台体现出来,可以进一步简化维护人工智能应用的难度。
总结总体上看,以上三个层面的权衡,其实本质上对人工智能应用开发平台提出了非常高的要求。只有提供足够多的领域模板、足够多的自动化调优能力,以及足够强大的人工智能应用开发态和运行态闭环能力,并在具体业务场景中做出最佳权衡,才能真正提升整体开发效率、降低整体开发成本,给业务方带来最终价值。
人工智能应用开发全流程的成本分析
前言人工智能应用开发的成本很大程度上会影响人工智能在各个行业的渗透率。成本越低,则渗透率越高,人工智能对行业的影响速度也越快。然而,人工智能应用开发的总体成本模型非常复杂,但大致包括以下几个层面：
一、设计和开发成本如上篇所述,如果结合开发流程模板来开发人工智能应用,则相对比较简单。而且,随着机器学习、深度学习等人工智能算法的发展,人工智能应用的使用门槛正在逐步降低,并且结合大算力做最优算法的选择和搜索变得越来越可行,因此可以把更多成本交给机器,进一步降低人工成本。对于不同的人工智能应用,以及相同人工智能应用的不同阶段而言,人工成本和机器成本的比例都是不一样的,这需要人工智能应用开发者按照成本预算自行决策。 然而,人工智能应用开发的最主要难点还在于如何识别业务问题,并将业务问题与最匹配的应用开发流程模板联系起来,即如何进行端到端的设计。这一点是很难靠机器来代替的,目前主要以人工为主。例如,某客户想做一个智能门禁系统,以更好地管理人员的出入,保证安全。对于这样一个问题,人工智能应用开发工程师可以想到多种可能的方案,如指纹识别、人脸识别、虹膜识别等。每种识别方案背后的算法技术所依赖的软硬件的成熟度、成本,以及算法本身的成熟度都各不一样。这时就需要与业务需求方进行沟通,从成本、研发难度、精度要求、体验等各个维度来综合考虑并选择出一种最佳方案。即便是具体到某一个方案,也有很多细节需要选择。假设客户选择了人脸识别方案,那么人工智能应用开发工程师会想到一系列问题,包括并不限于以下几点:①采用什么类型和型号的摄像头,以及摄像头如何布局和安装?②光照的变化怎么处理?如何处理强光和弱光场景?③所需识别人员有多少?④如果待识别人员名单发生变动如何处理?⑤整个软硬件系统方案是什么?⑥目标识别精度和速度是多少?⑦如果识别不了某些人,怎么处理?⑧如何对待识别人员进行动作约束?例如,需要对准并正视摄像头才可以识别,如果待识别人员不配合,需要如何处理? 这就涉及如何针对业务问题和场景,将客户需求层层分解,并转换为具体应用开发流程模板的选择问题,从而形成一个端到端的解决方案。这个阶段需要反复沟通和设计或实验验证,进而也增加了开发的成本。从降低人工智能整体设计和开发成本的角度看,人工智能应用开发平台会按照三个阶段不断演进:第一阶段,大部分依赖于人工设计和开发;第二阶段,平台提供大量的应用开发流程模板,开发者仅需要负责业务问题的转换和需求分解,以及基于模板开发时的部分参数选择或调节;第三阶段,开发流程模板会覆盖部分业务问题和需求更贴近领域具体问题,并且平台会结合更强的优化算法和大集群算力来加速调参。随着人工智能服务单位算力的成本越来越低,以及平台的积累越来越多,人工智能应用的设计和开发成本会逐步降低
二、部署和维护成本在人工智能应用部署方面,部署成本体现在多设备部署方面。未来的人工智能推理一定是端边云协同的,因此一次开发和任意部署的能力尤为必要。 如设计和开发成本所述,在部署完成后,人工智能应用的维护往往非常重要。人工智能应用本身的脆弱性导致其维护成本非常高。在人工智能应用的运行态,推理数据量可能会很大,返回训练集中做重新训练时,重新标注的成本会很高,并且重新训练的算力成本也比较高。因此,如何自动判断人工智能应用推理表现的恶化,自动对造成这种恶化的关键数据做选择、标注并重训练模型,是大幅度降低维护成本的关键。 从降低人工智能部署和维护成本的角度看,人工智能应用开发平台会按照三个阶段不断演进:第一阶段,依赖纯人工部署和维护;第二阶段,具备端边云多场景化部署能力,并基于自动难例发现算法,采集对应用恶化起关键作用的数据,然后基于这些数据做半自动标注和重新训练,降低应用维护成本;第三阶段,可以采用纯自动方式进行模型部署和自适应更新,仅需在重新部署时引入人工确认。
三、边际成本人工智能应用开发的边际成本主要体现在两个方面:一是将人工智能开发流程模板进行跨场景复制时总成本的增量;二是将人工智能应用本身进行跨场景部署和维护时总成本的增量。 对于人工智能开发者而言,如果将已开发好的开发流程模板不断扩大以支持更多的业务场景,当然边际成本就会很低。但是,通常这些模板(尤其是专业模板)跟业务问题有很强的关联,而业务问题和场景差异很大。比如,同样是一个面向图像目标识别的开发流程模板,有的业务场景比较简单,如检测某个固定场景、固定光照条件下单的、清晰的目标物体,就可以套用一个简单的模板解决;而有的业务场景比较复杂,如远距离视频监控目标物体,远距离造成目标物体不清晰,并且物体较小,如果光照条件变化大,待识别的目标有多个种类并且类别间差异非常小时,算法的复杂度将急剧上升,这时就需要套用一个复杂的模板,或者重新开发一个面向此类场景的模板。因此,现有人工智能开发流程模板必须确定其所能覆盖的业务问题范围及其局限性。任何的人工智能开发流程模板都是有局限性的,只是局限性的大小不同。为了尽可能扩大模板覆盖业务问题的范围,就需要预先对很多场景进行针对性设计和抽象,并且结合算力自动选择适合当前问题的方案。 当人工智能应用开发好之后部署在不同场景时,不同环境造成的推理数据的差异是一个很大的挑战。正如前文所述,人工智能应用需要根据推理数据的变化而不断进行维护。如果维护能够尽可能自动化,那么边际成本就会更低。 从降低人工智能边际成本的角度看,人工智能应用开发平台会按照三个阶段不断演进:第一阶段,依赖已有的人工智能开发流程模板和应用,手工进行跨场景优化和复制;第二阶段,在已有开发流程模板和应用的基础上,增加一定程度的跨场景自适应能力;第三阶段,开发流程模板和应用所能支持的场景更丰富,并自动给用户的新场景提供最优模板变种,自动更新应用。 综上可以看出,当前人工智能应用的设计、开发、部署、维护阶段本身的可复制性都比较差,这使得边际成本难以降低,也造成了当前人工智能应用可复制性差的问题。
总结综上所述,人工智能应用开发更需要借助大集群算力、模板库、业务知识库,以及每个模板内依赖的半自动标注、自动算法选择、自动模型训练和优化等人工智能应用开发平台的基础能力,才可以真正降低人工智能应用开发全生命周期的成本,使得人工智能应用更加普及,实现人工智能无处不在。
项目开发—项目开发流程8个步骤
以下是项目开发流程的八个步骤：
1、项目开发目的分析与确定
软件开发流程的这一阶段，主要是在软件开发商将开发项目确定下来之后，需要与需求方进行讨论，确定需求方对于软件开发需要实现的目标及其具体需要的功能等等，并确定是否可达成。
2、需求分析
这是软件开发流程的第二个阶段，也是为软件开发的正常进行确定具体思路的阶段。在确定软件开发可进行后，必须要对客户需要实现的软件功能需求进行具体详细的分析。同时应当考虑在开发过程中可能出现的变化情况，制定需求变更计划随时应对特殊情况的发生，保证软件开发流程的顺畅进行。
3、设计
软件设计要根据上一阶段对软件功能需求分析的结果，来设计软件系统的框架结构、功能模块和数据库等等。分为总体设计和详细设计两个部分，
4、编程
软件开发流程中每上一个阶段都是下一个阶段的实施进行的基础。编程也是根据对软件设计，将软件设计的各部分需求通计算机程序代码来实现运行，编程有统一、规范的程序编写规则，保证软件程序的易懂性、易维护性。
5、软件测试
在根据设计将客户软件需用编程代码来实现之后，也就是软件程序完成之后，需要对编写的程序，形成整体构架、功能进行单元、组装、系统三阶段的测试，以测试程序编写的正确性，以及对客户需求功能满足的充分性，以此来确定软件是否达到开发要求，同时也是一个发现问题、纠正问题的过程。
6、软件交付
软件开发流程通过以上核心环节完成了软件开发，接下来就是在软件开发达到客户需求之后，开发者将软件系统交予客户，并将软件安装程序、数据库的数据字典、《用户安装手册》、《用户使用指南》、需求报告、设计报告、测试报告等产物交付给客户；
同时指导客户进行软件安装、以及安装技巧，提醒客户注意软件运行状况、环境、服务器及相关中间件的检测与注意事项，知道客户软件的实际操作方法、使用流程等等问题，实现合同规定任务。
7、验收
用户在接收开发商交付的软件开发结果，并进行实际操作、测试运行，实现满意结果之后，对开发出来的软件进行验收。
8、维护
定制开发的软件通常都需要提供售后服务，定期对软件进行维护，或者根据用户出现的新需求，进行应用软件程序的修改，使之不断满足客户实际需求。
扩展资料：
项目启动阶段要做好的工作：
需要做好前期的需求分析工作，系统架构师作为客户与项目团队之间的桥梁，应该和客户进行很好的沟通，了解业务，为接下来的系统设计做好业务基础。
一般采取的方法是到客户那里进行实地问卷，考察交流。当系统架构师向客户描绘系统应该实现的功能与客户达成共识后，才进入系统的设计。
进入设计阶段，架构师不能够只为了实现业务而随意的设置系统构件，这个时候不但要考虑系统的功能，还要考虑系统的性能和系统的扩展性。
当所有的构件已经设计完成后，可以宣布系统的基础模型已经构建成功，这个时候应该用实例去测试这个模型。当系统的业务要求和性能要求满足客户的需求后，进入下一个阶段，如果不符合，则继续进行这一个阶段。
人工智能项目的开发流程概述
据“5G推进组”官方公众号消息，近日，在IMT-2020（5G）推进组指导下，华为携手行业伙伴完成了全球首个5G高低频CA（CarrierAggregation，载波聚合）技术的实验室测试，实现单用户下载速率5.2Gbps。
据介绍，测试的完成意味着，CA技术在高低频协同上已获得技术验证，为毫米波未来大规模商用走出关键一步。
测试采用SA（Standalone）独立组网，高频使用26GHz(n258)频段，基于单载波200MHz，低频使用3.5GHz。
据了解，CA通过聚合5G高频和低频频谱来同时发挥高频带宽大和低频覆盖好的优势，从而保障5G用户的连续高速率体验，是5G高低频协同的主流技术方向。
一方面，CA技术更接近于射频侧的信号处理，能够及时感知信号波动，从而基站能够更好得做分流和调度，提升传输效率；另一方面，该技术可同时支持NSA和SA组网架构，网络架构和演进十分灵活。
另外，考虑到Sub6G各频段间已采用CA技术的基础，高低频CA有利于架构和分流点统一，使能全频段5G组网演进。
据悉，移动宽带体验从兆比特每秒到百兆体验再到千兆体验，未来甚至会出现10Gbps的业务体验需求。毫米波存在大带宽优势，在5.5G时代可满足日益增长的业务需求。
联乐实业，工业存储/工业电脑服务商，17年专注高可靠性工业存储产品解决方案服务商！详情进入www.univo.com.cn或垂询400-888-2720项目开发的完整流程（详解版）
项目开发的完整流程前言一般情况下，企业开发软件时会按照基线和定制两块并行方式执行项目开发工作。无论什么公司，都需要遵从一套成熟的产品研发过程体系，才能做出质量较好的产品。因此，如果出现项目较多的情况，应该合理地安排基线和定制之前的里程碑，让基线产品能够尽量多地收集用户的通用型需求，为定制项目进度实现技术支撑，减少定制项目中大量更改代码、需要新增模块情况发生。此外，产品研发过程体系也需要按照业务实际时间要求变化，不要拘泥于一定要按照瀑布方式，或是敏捷方式进行管理，凡事都需要找到契合自己的方式。
【这里以一个基线产品开发过程作为流程解释基础，需要注意的是，以下说描述的各个阶段，在项目执行前要明确各个阶段的目标、指定计划、及时沟通，并确保各个时期所有成员对项目理解一致】
项目启动会项目启动会的目标是明确该产品开发项目的目标。目标不是孤立存在的，目标与计划相辅相成，目标指导计划，计划的有效性影响着目标的达成。所以在执行目标的时候，考虑清楚自己的行动计划，怎么做才能更有效地完成目标，是每个人都要详情清楚的问题，否则，目标越是不清晰或是过高，都会影响项目的实际结果。
项目启动会需要说明项目目标、阶段划分、组织结构、管理流程等关键事项，并将这些内容写入PPT(最好是有固定格式和范文，让团队内部或者公司内部共同遵守规范)，需要大家达成一致。对于关键角色任命，事前也需要听取相关领导和项目主要干系人的意见。
用户需求软件开始开发前需要确定代价和所获得价值的对比，也就是ROI(ReturnOninvestment)，一旦确定需要创建，就需要安排一系列的资源来支撑这个软件的生存。这是需求的最原始描述。
为什么既要有用户需求，也要有产品需求？因为两者是有差异的，用户需求由用户提出，对技术一般不描述，只描述产品目标。产品需求是根据用户需求转化而来的技术实现需求，需要针对用户提出的产品目标进行细分，总结出具体的每一个功能点，再针对每一个功能点细分为各种不同的操作流程，对每一个操作流程进行技术化定义。
用户需求和产品需求容易发生不一样，这是因为虽然大家都在谈需求，但是出发点可能不同，造成了双方关注点和思维方式不同。用户需求关注的是系统如何支持业务流程，背后的需求是“实现业务目标”。技术人员关注的是合理技术方案，背后的需求是“工作量”、“实现难度”和“系统性能”。
产品需求我们需要弄清楚产品经理或项目需求提出者为什么要做这个项目？这是最本质的业务需求。需求分析确定的业务需求，都是从业务需求推导出来的，都必须为业务需求服务。
产品需求一般包括产品需求规格说明书和产品需求矩阵。产品需求矩阵一般按照子系统、功能集、执行单元的结构列出所有的功能需求，每列则对应每项功能的工作步骤以及每个步骤的工作量。
产品需求写完后，需要进行评审。在需求评审会上，产品、技术详细评审需求是否完整，产品功能的正常场景是什么？是否形成闭环？异常场景是什么？是否考虑周全？
需求评审后，开发和测试负责人，分别编写技术方案和测试用例。技术方案评审，开发负责人拉上涉及到其他系统的负责人一起讨论，技术方案中必须要有业务流程图和时序图，业务流程图是为了梳理开发对业务的理解，是否和需求一致。时序图是了梳理本次需求涉及的系统交互。技术方案评审通过后，确认工作量和交付时间，反馈给产品。
总体设计设计阶段的目标主要是对待开发系统的构架进行分析和设计，并建立系统构架的基线，以便为之后的实施工作提供一个稳定的基础。
设计阶段包括了系统架构的输出，一个好的系统架构设计可以帮助人类梳理业务逻辑且抓住核心需求，设计稳定可扩展的业务系统，评估业务开发周期和开发成本，有效的规避风险。例如盖房子的时候得有建筑图纸，有了图纸，才能核算施工周期。
总体设计是整个系统的框架型设计，意义及其重大，一般情况下不能省略(只有维护项目可以省略总体设计，因为基准项目已经设计完毕)，所有的产品开发项目均需要首先进行总体设计，它是设计首要步骤，决不允许本末倒置，不能出现先编码后设计的情况，这是软件开发的第二大痛点(第一大是需求不明确、任意变更需求)。
总体设计分为三个阶段：
第一阶段：初始设计。在对给定的数据流图进行复审和精化的基础上，将其转化为初始的模块结构图。
第二阶段：精化设计。依据模块“高内聚低耦合”的原则，精化初始的模块结构图，并设计其中的全局数据结构和每一模块的接口。
第三阶段：设计复审阶段。对前两个阶段得到的高层软件结构进行复审，必要时还可能需要对软件结构做一些精化工作。
概要设计概要设计的目的是描述系统的每个模块的内部设计，对总体设计和详细设计承担承上启下的作用。
概要设计按照结构化设计方法进行设计。结构化设计方法的基本思路是：按照问题域，将软件逐级细化，分解为不必再分解的的模块，每个模块完成一定的功能，为一个或多个父模块服务(即接受调用)，也接受一个或多个子模块的服务(即调用子模块)。模块的概念，和编程语言中的子程序或函数是对应的。
概要设计阶段把软件按照一定的原则分解为模块层次，赋予每个模块一定的任务，并确定模块间调用关系和接口。
在这个阶段，设计者会大致考虑并照顾模块的内部实现，但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要制定得十分细致明确，需要编写严谨的数据字典，避免后续设计产生不解或误解。概要设计一般不是一次就能做到位，而是反复地进行结构调整。典型的调整是合并功能重复的模块，或者进一步分解出可以复用的模块。在概要设计阶段，应最大限度地提取可以重用的模块，建立合理的结构体系，节省后续环节的工作量。
概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据，各个模块的详细设计就可以并行展开了。
详细设计详细设计阶段就是依据概要设计阶段的分解，设计每个模块内的算法、流程，为每个模块完成的功能进行具体的描述，要把功能描述转变为精确的、结构化的过程描述。
详细设计这个阶段，各个模块可以分给不同的人去并行设计。设计者的工作对象是一个模块，根据概要设计赋予的局部任务和对外接口，设计并表达出模块的算法、流程、状态转换等内容。这里要注意，如果发现有结构调整(如分解出子模块等)的必要，必须返回到概要设计阶段，将调整反应到概要设计文档中，而不能就地解决，不打招呼。详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块对应一篇详细设计文档。
概要设计阶段通常得到软件结构图，详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等。而详细设计的目的是描述某一个模块内部的处理流程、开发方法和编码技巧。一般来说，详细设计由项目简介、模块说明(具体说明每一个模块内部的流程、功能、逻辑、消耗以及未解决问题)、接口设计(包括内部接口和外部接口)、数据结构设计(包括物理结构和逻辑结构)、特殊处理等几个部分构成。软件的详细设计，最终是将软件系统的各个部分的具体设计方法、逻辑、功能采用文字方式进行表述。这样在实现过程中，编码人员原则上严格按此进行代码实现即可。
编写代码编写代码可以遵循以下几点原则：
先做核心模块的压测：很多程序员，习惯把东西做完，然后等着快上线的时候才做性能测试，那么如果前面设计出了问题，这个就很头大了。当然，后期快上线的时候也要做性能测试，但前期的我认为还是很重要的。当然，做好这一点，需要懂一些业务，你要知道业务压力在哪里，业务请求的重心在哪里，很多时候，产品经理不讲，你也要问清楚。
确保过程可控：代码执行时一定要保持中间的输出，比如说，每处理10万条日志，写一条状态日志，记录处理的日志条目数和当前的执行时间。
多打日志：很多时候，代码写的自己也不是很满意，比如某个处理效率不够优化，某个处理的方法不够简洁，或者扩展性比较差，代码写的很弱智，但可能短时间没有办法想清楚最合理的解决方案，考虑到上线初期这里并不是重心所在，所以也不会特意去优化它，但这种情况下我往往会留下注释，并说明下一步优化的可能思路是什么，或者想到的可行方案是什么。
简单易懂的逻辑：千万不要把自己绕进去了，时间一长，谁都看不明白你的逻辑。如果逻辑真的很难在一个函数内完成，尝试切分。
不要沉迷于框架：框架最大的问题是什么？是过于繁冗的嵌套。为什么我一直很烦框架？因为经常遇到需要一秒钟几千次请求的处理场景，那么调优的时候，要从数不清的框架中寻找数据处理的逻辑，寻找性能卡点，可能改动代码只有两行，但是找问题需要两天。程序员记住，你的技术能力绝对不能被框架约束住。
使用熟悉、成熟的技术：很多人根本没搞明白自己的障碍和问题在哪里，根本不知道相关技术产品的优势和劣势在哪里，看一堆第三方的数据测评，脑子一热，去学新技术，然后，掉进坑里出不来，如果是创业公司，可能项目就死在里面了。使用新技术前，建议全面了解该技术的特征，适用范围，以及不适用的范围。
代码审核众所周知，在团队中进行代码审查(CodeReview)可以提升代码质量，分享项目知识、明确责任，最终达到构建更好的软件、更好的团队。
代码审核及其重要，一般来说每周都要做一次代码审核。首先，代码审核有利于你跟踪项目进展情况，我们能真实地看到手下的人进展如何，并且更早发现他们是否误入歧途。有时候，手下人会说“完成得差不多了！”，你去看代码时发现什么都没有或者只是一堆垃圾，诸如此类，总之离完成还很遥远。在管理中，这种情况是最让人讨厌的，所以我认为代码审查是避免这种麻烦的最佳途径。
单元测试要认识单元测试，首先要明白什么是“单元(Unit)”。所谓“单元”指的是代码调用的最小单位，实际上指的是一个功能块(Function)或者方法(Method)。所以单元测试指的就是对这些代码调用单元的测试。
单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试。所以，单元测试的编写和执行都是由软件工程师来做的。相对于单元测试，还有集成测试。集成测试基本都是黑盒测试，主要是由测试人员根据软件的功能手册来进行测试，需要有专门的测试环境配合。集成测试又分功能测试、回归测试等。
需要单元测试的代码实际上是开发人员自己写的逻辑，测试逻辑所依赖的环境是否正常不是单元测试的目的。在环境访问代码中引入逻辑，只会让逻辑更难测试，导致逻辑代码无法进行单元测试。因此，可单元测试的代码，才能够采用单元测试。判断可测试的代码还有一个方法，就是看这个方法能否用一个main函数直接运行，如果可以的话就是可单元测试的代码。可测试的代码还有另一个特征，就是该方法单元的参数，开发人员可以自由模拟，不需要依赖外部环境。
集成测试集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。一些局部反映不出来的问题，在全局上很可能暴露出来。
集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的借口是否正确。它根据集成测试计划，一边将模块或其他模块组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各个组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。也可以理解为在软件设计单元、功能模块组装、集成为系统时，对应用系统的各个部件(软件单元、功能模块接口、链接等)进行的联合测试，以决定他们能否在一起共同工作，部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。
系统测试系统测试阶段包括系统测试方案及用例编写、功能性测试、性能测试、稳定性测试。
为了验证需求分析确定的功能是否齐全并被正确实现，同时还要对安装、部署、适应性、安全性、界面等非功能性需求进行测试。系统测试也有测试人员负责，应该在需求分析完成后进行设计，在集成测试完成后进行实施。
功能性测试一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。
性能测试验证系统的稳定性和效率，检查系统是否满足规定的性能要求。性能测试通常选择一些典型的功能，检验这些功能在大量用户同时使用系统时系统是否稳定。性能测试由测试人员负责，可以在系统测试完成后进行，也可以对重要模块先进行性能测试，可以贯穿整个测试周期，目的是尽早发现系统的性能瓶颈并提早解决。
稳定性测试和性能测试都必须等到系统基本没问题、趋于稳定时再进行才有效果，否则很难顺利测下去，出现异常也不能定位究竟是系统架构的问题，还是功能上的缺陷。
稳定性测试(亦可称可靠性测试)通过给系统加载一定的业务压力，让系统持续运行一段时间(一般为7×24小时)，检测系统是否能够稳定运行。
产品发布产品发布是系统测试结束后的最后一步，通常在软件产品开发过程中不需要产品试制环节，可以直接上线，只需要系统测试员输出系统测试报告并批准产品发布(上线)就可以了。
产品发布前需要通过产品发布说明会形式，对整个产品开发过程从立项开始回溯过程，指出整个过程中的不足点，总结经验，为下一个项目提供经验案例。这一会议可以通过正式会议形式召开，需要召集产品经理、主要开发人员、测试人员、上级领导等参与，准备充分，尽最大可能说清楚这个产品发布之后的效果、效益，为上线后的价值评估做准备。这一环节不可缺少，即便在互联网公司，迭代速度很快的情况下，这一环节也需要满足。
开发过程复盘所有的总结，只有带着问题去思考才会有收获，这就是复盘。不论我说多少，如果没有过类似的经验，就很难有很强的共鸣。我觉得看清一个问题最好的方式，就是你曾经处在一个问题的两个不同的角色中。
总结项目经验教训的目的，在于总结问题、分析原因，避免以后犯同样的错误，而不是追究谁的责任。
假设一个需求理解的缺陷，如果在需求阶段发现，修改一下可能只要一个小时，但是如果到了设计完成时发现这个缺陷，因为涉及的人员、文档增多，估计要一天时间，而如果等到代码都编写完成时才发现这个缺陷，可能需要十天八天了。如果缺陷没被发现，而是直接到了生产系统中呢？这就不是工作量的问题了，估计损失就难以估计了。在质量管理的理论中，缺陷每延迟一个阶段被发现，修复的代价就要乘上十倍。
项目开发流程图