精华内容
下载资源
问答
  • 2020-03-18 12:03:54

    1.可行性分析

    主要是对一个项目是否进行做出决定,一般由公司高层来决定,这种决策对公司尤其是创业公司至关重要。方向搞错了,执行力再强也没用。想创业的同学,这个问题定要多多思考哦。
    可行性分析可能包括但不限于以下几个步骤:市场调研、技术难度、盈利能力等诸多方面。
    a. 市场调研:对市场做一些具体的调查,主要对一些问题做出回答,比如市场是否有对项目的切实需求、市场中是否已经有公司或组织在做、是否符合法律法规。
    b. 技术难度:公司是否有技术实现这个项目,其中技术人才是一个重要因素。

    c. 盈利能力:能给公司或者组织带来多大的收入。

    有的时候,是不需要考虑盈利能力的,比如第一次给其它公司做项目,只要成功了,今后自然还有项目再做。或者,这是一个公司内部的项目,主要是为了减少成本的。(我们也可称之为盈利的)
    思考:很多时候,探讨一个项目是否值得做,价值不大。因为你只有去做了,可能是做了3年,
    才发现这个项目有前景或者不值得做。不过Fans同学仍然认为,思考是有必要的。

    2.需求分析

    可行性分析中探讨市场需求时,这时的需求很可能是一个比较大而抽象的需求,需要在需求分析阶段细化需求。需求往往是很多的,而不是一个原子需求。

    需求分类:功能需求、界面需求、性能需求。
    a.功能需求:描述系统的功能,一般来说会细化成一个个的小功能,小到开发人员能够实现。
    每一个小功能通常都有一个编号,比如F000001.
    b.界面需求:打个比喻,系统的功能好比人的内涵,需要一些时间才能理解。
    系统的界面好比人的外貌,长得美帅很可能立即吸引一批人。
    举几个界面需求的小例子,整体界面布局,色彩,字体大小。
    这类需求往往会有一个解决方案:系统皮肤。
    c.性能需求:描述系统的性能,比如页面的响应时间,同时响应的请求数等。
    d.稳定性需求:724365不停运作,商业重要项目中会有此要求;
    每个月有一次或几次维护,在网游行业非常常见。
    e.安全性需求: 保护系统内部数据不外泄等安全方面的需求,比如用户的帐号和密码,个人其它隐私信息。
    f.其它需求:…
    思考:时间或者进度是需求么?

    3.架构设计

    架构设计是从技术角度对系统进行一个全方位的规划,通常着眼于全局,而非局部细节。
    没有最好的架构,架构都是根据需求来做的。架构通常都会有架构师参与。

    包括但不限于以下几种事项:
    a.选择项目开发所使用的技术,可能包括编程语言,数据库,框架或类库或平台。
    b.定义系统技术基础,比如分布式平台的规划和部署、数据的流转等。
    c.将系统划分为不同的模块,定义模块与系统技术基础之间的关系。
    d.定义模块之间的接口或通信或者交互。一个系统通常会包含很多个模块,分模块开发体现了一种
    分而治之的思想方法。定义模块之间的接口方便后期不同模块的整合。

    4.详细设计

    详细设计是将架构设计进一步细化,通常会比较细致,一方面方便开发人员具体开发,
    另一方便于项目经理跟踪项目进度。

    详细设计通常由开发人员来制定,可能会有以下任务:
    a.模块内部的设计,大概怎么做得有个全局的思考,可能会书写详细设计文档。
    b.完成自己的模块功能,通常会严格参照需求文档或者功能列表文档。

    c.与其它模块的交互。

    5.编码实现

    一般来说,初级程序员编程时,对需求、架构、设计没有深入的考虑,也不是很有必要。老师布置了
    一个任务,或者自己想要做个小项目,通常在内心都有一些考虑,然后就开始敲代码了。
    生产环境下开发,急于编码是个大忌,有经验的人通常会认可此种观点。
    原因分析:
    a.需求变化的概率是非常大的,根据确定的需求编码往往不能适应变化。
    b.即使需求不变,急于编码很容易考虑不周,结果往往是只实现了功能,却导致了性能差、逻辑不清、冗余代码多等种种问题。
    比如,同一个功能,为了用户的方便,可能会有好几种操作界面,后台的功能实现既相似又有不同,急于编码非常容易导致代码冗余和混乱,维护起来非常费劲。尤其是在这次实习做项目中。o(︶︿︶)o
    c.一旦编码有了一定的进展,对大多数人来说,就失去了重新开始的勇气。
    有的时候,重新开始写优于重构,尤其是在需求或者设计发生变化时。

    6.测试

    根据需求和功能列表,写测试用例,然后测试系统。
    根据Fans现在的经验来看,人工测试占了很大一部分。比如为了测试用户名和密码,手动输入 用户名和密码,且考虑到正确性和合法性等诸多情况,这样为了测试一个功能,往往会有很多个测试用例。时间久了,会让人感到厌烦和疲惫。

    对于想在测试道路走下去的人,做个测试开发工程师、测试经理还是有挑战的。

    7.验收

    根据当初的项目计划或者产品计划,也可能是结合需求文档,来检查当前项目是否完全完成了当初的计划。
    验收过程可能会和前面几个流程有些重复的地方,我的理解是9个流程之间存在一条主线:项目开发和维护。
    验收的过程会涉及到很多事项,具体有哪些事项,可以"身临其境"来想。

    8.部署

    项目计划是振奋人心的,
    需求分析是细致入微的,
    架构设计是运筹帷幄的,
    详细设计是指导方针的,
    编码过程是艰苦卓绝的,
    测试过程是精挑细选的,
    验收过程是中规中矩的,
    部署过程是春种秋收的,
    维护过程是精心呵护的。

    9.维护

    a.保证现有软件持续正常运行
    常见例子:
    ①服务器由于负荷太大,挂掉了,需要立即重启;
    ②网游为了保证系统稳定运行,每过一段有几个小时的维护时间。
    ③系统越来越慢,需要诊断原因,网络带宽问题还是内存泄漏还是CPU不够用。
    b.二次开发
    常见例子:
    ①百度有海量的搜索请求,分析下搜索请求,挖掘一些信息,比如浏览器的市场份额情况、统计热搜词。
    (侧重于数据)
    ②使用系统API,做一些其它方面的功能。(侧重于功能)
    c.系统升级
    常见例子:
    ①QQ空间由5.0升级到6.0,公司内部做好开发,普通用户没有多大的影响。
    如果想升级,点击一下按钮-升级到6.0,就可以了。
    ②天龙八部由2.0升级到3.0,客户端需要下载很多新的组件,然后更新,最后重新启动。
    以上介绍的只是一些概念上的流程,很多地方都是自己的个人揣摩和猜测。
    实际过程中的开发流程,各式各样,按照自己所在公司的流程来开发才是最合适的。

    更多相关内容
  • Head First软件开发.pdf

    千次下载 热门讨论 2012-11-19 11:46:11
    在你完成《Head First软件开发(中文版)》阅读之时,你将能跟踪工作量完成状况,解释开发团队中开发人员的编码能力与时间效率值,并且为项目反复进行需求、设计、开发与部署等工作。 这《Head First软件开发(中文版)...
  • Java编码规范

    2020-10-25 03:30:25
    在软件的生命周期中,维护的花费通常很大的比例,且几乎所有的软件,在其整个生命...本文档定义了我公司软件开发过程中使用的开发语言的编码规范,指导软件开发人员在进行项目开发过程中提高代码质量、统一编码要求。
  • 云开发:未来的软件开发方式

    千次阅读 多人点赞 2019-12-23 20:58:00
    这种方式颇为适合大型组织的软件开发模式,由高级工程师设计出基本的模型与软件架构,生成对应的方法名称,以及其所需要的返回结果。这种模式事实上在过去已经有了,剩下的就是普通的开发人员去填充对应的代码。再...

    我知道这篇文章你可能读不懂,但是它值得你去分享,未来就在那。

    如你所见,在过去的几年里,发生了快速的变化(这句话,我已经说烂了)。好比如说:

    • 编程门槛的降低。大量的低编程能力水平可以进入这个行业(如上一篇文章)

    • 基础设施的完善。只需要执行 git push,便能完成 push to production(尽管四年前我们在项目上实践过)

    • 云主机开发。远程开发机器,代码不在本地机器上。

    • 多人实时开发编辑技术。诸如于 Visual Studio Live Share,可以多人实时协作编程。

    • 5G。更快速的网络连接,更好的通信质量。

    • ……。

    在经历了与公司大佬、同事、社区大佬等的一系列的技术讨论之后,以及近年来开始云代码开发,我又有了一些新的顿悟。于是,我就撸了这篇文章。

    在你失去继续往下阅读的兴趣之前,让我先说第一个结论:

    云开发,是一种生于云上的闭环 + 代码化的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端共同协作透明化地完成整个软件的生命周期(需求、设计、编码、构建、部署、运营),而非相互隔离,又或者是借助于多个软件才能完成工作。

    因此云开发是一种解决方案,它解决的问题是:如何以更高效地方式进行软件开发?

    作为 v0.1.0 的定义,我对它的定义可能还不是非常准确,但是重点有这么几个:

    • 共同协作的方式开发软件

    • 软件开发的在线闭环

    • 应用生命周期的代码化和可追溯

    你看吧,我们过去解决了一个又一个的线下协作问题,现在构建新的线上协作平台的时机已经逐渐成熟了,是时候开始准备构建你们的云开发平台。

    我知道你想说市面上已经有这样的工具,比如 xx 的 xx。但是,一来它朝着一个错误的方向前进,你知道的某公司更懂 2B;二来,它包含了大量的功能,但是却没有闭上环。当然了,我只是从官方的首页看到的功能,一眼得到这个所谓的结论。

    PS:只要是它们没办法体现我总结的核心三要素,笑~。套不上我的理论,他们一定是错的,手动滑稽,逃~。

    引子 1:核心三要素

    这三个要素是软件开发的要素,只有深入要素本身,才能成为真正的云平台。

    我不想多说废话了,手疼。

    如果基础设施真的已经是基础设施,那么你不应该在云平台强调它们。这就是为什么尽管基础设施很重要,但是却不是核心要素之一。基础设施已经是一个通用域,作为一家时髦的公司,如果你们还没有……。

    微架构

    微架构,即以模块化的组合方式协同构建大型应用(前端、后端、APP等)的架构方式。每个微应用都可以独立开发、独立部署、独立运行,对应的替换的方式有模块化、子模块的方式,微服务、APP 插件化(独立构建、独立运行)、微前端等。

    微架构是一个模式,它不是银弹,它以技术的方式拆解了复杂软件架构,适合于复杂场景下的问题,还有人类脑容易不够大的问题。

    后端:服务导向架构

    五年前,Martin Fowler 和 James Lewis 一起写下了那篇《微服务架构》,微服务成为了今天新项目的主流架构之一。最近几年来,它结合着《领域驱动设计》这把锤子,已经成为了一个利器。

    作为服务导向架构的一种实现方式,掌握它背后的设计与实现模式,是云开发中不可或缺的重要一环。

    后端:函数即服务

    两年多以前,我在 GitHub 写下了我的第 N 本电子书《Serverless 架构应用开发指南》,而在最近 Serverless 终于在国内慢慢有一点的热度。两年前,我陆续收到阿里云、腾讯云的 Serverless 尝鲜体验(作为一个 MVP 还是没白混),但是它们并不成熟,甚至于无法调用自己的云服务。而今天,越来越多的云厂商的 Serverless 终于可以跑起来了,

    同理于服务导向架构 BAAS (Backend as a service)又或者是 Serverless,也是如此,它们进一步拆解了复杂问题到人能 handle 的范围。

    APP:应用即『插件』

    最近几年,对于 APP 来说,开发者也探索出了大量的微架构方案。我习惯地称它们为应用即『插件』,因为 APP 作为一个基座,提供了各式各样的能力。就目前来说有三种展现方式:

    • APP 内 Web 应用。

    • APP 插件化。市面上已经有大量这一类的方案,诸如于 RePlugin、Atlas、VirtualAPK、DynamicAPK。

    • APP 小程序。即功能以小程序的运行在容器化,即可以像 Web 容器一样实现远程更新,还能有效地控制开发商的权限,培养自己的生态。

    尽管让人们下载 APP 的成本越来越高,APP 平台化成为了一种趋势。

    哪怕 APP 的原生仍占很重要的一部分,但是 App 平台的方案 + 应用插件化模式的生态构建,也是云开发要考虑的重要因素。

    前端:微前端与应用组件化

    今年是微前端开始火爆的一年,微前端框架层出不穷:SingleSPA、Mooa、qiankun、ngx-planet,还有诸如于《前端架构:从入门到微前端》这样的书籍。它让越来越多的企业开始思考前端架构的未来,也完善丰富的微前端相关的基础设施。从某种意义上来说,这是组件化的一种方式,只是原先的组件只是简单的 UI 组件,而现在的组件是一个完整功能的应用。只需要设计好对应的 pipe,就能完成一个应用的开发。

    而随着 5G 的到来,微 “服务化” 前端应用、Web Component 的体积已经变得让人可以接受。进行功能编排,将成为云开发的一个重要组成——毕竟,插件市场地不断火爆,可以看出一些端倪。

    代码化

    对于这部分的一句话总结是:

    • Given Future[Dev]

    • When Everything as Code,

    • Then you can Guard

    • Then you can Refactoring or Rewrite it.

    然后,以下大概就是三种完全不同的模式。

    设计到代码:填空式开发

    起先我只有两种模式,直到月初在公司内部听到了相关的分享,Get 了第三种模式:面向于大型组织的类型流 (https://github.com/notyy/TypeFlow) 开发。

    这种方式颇为适合大型组织的软件开发模式,由高级工程师设计出基本的模型与软件架构,生成对应的方法名称,以及其所需要的返回结果。这种模式事实上在过去已经有了,剩下的就是普通的开发人员去填充对应的代码。再结合 Serverless 等基础设施,便可以直接集成上线。

    它表面上看它是设计生成的代码,实则设计即代码。

    需求到上线:无代码编程

    年初,我写下了那篇《无代码编程》,通过这篇文章,我结交了更多无代码/低代码已经有大量的案例表明,这是一种可行的开发模式。

    无代码编程的本质是业务模式 + 编程模式的抽象化,以领域特定的场景解决领域特定的问题。所以,低代码编程 / 无代码编程它只能解决领域特定、简单场景的需求,无法解决大部分的问题。

    无代码编程做了一件了解不起的事情是,直接对于业务和设计即需求的抽象,实现了直接由需求到代码的直达。

    代码化:DSL as DSL

    DSL 即 DSL,即把每件事物都变成 DSL。考虑到我正在编写一篇关于 DSL 如何设计的文章,我就不展开详细的讨论:

    1. 汲取领域名词

    2. 模型分析与抽象

    3. 模型行为抽象

    4. 寻找关键抽象

    5. 场景代入

    6. 实现 DSL

    7. 迭代优化

    而代码本身也应该是一种 DSL,才能进一步完成云平台的建议。需求、设计、代码、构建、部署、运营都应该抽象成 DSL,才能完成真正意义上的云平台。

    协作设计文化

    软件开发是一个集体行为,软件设计也是一个集体行为。所以,一个好的云开发平台应该要融入共同协作的基因

    软件开发文化

    采用了敏捷,却始终敏捷不起来,有一部分的原因在于:部门墙。对于非互联网公司来说(对于大部分互联网公司也是如此),开发一个软件往往需要在多个部门甩锅:业务部门、技术部门、测试部门、市场部门……。

    业务(领域)驱动设计

    以我多年的读书经验来看,人们采用开发出失败软件的原因,无非就是两点:『缺少协作设计』和『知识传递』。对了,还有技术水平不行,这个反而不是那么重要。

    而 《DDD (领域驱动设计)》和事件风暴,正是软件开发文化的一种实践,通过协作设计的方式,传递知识,以妥协出符合大家需要的应用。

    服务端服务中台与客户端组件中台

    可能是我对于中台的误解,我习惯性称中台为『不可清空的垃圾回收站』。但是,它做了一件不可思议的事件,将 “基础设施服务” 化,成为了一个 common 的 common 的 common。好了,调侃到此结束。

    随着中台建设的进一步完善,大量的基础设施,将从原先的各个业务部分,统一到了这个 ~~垃圾回收站~~ 大平台。

    有了这个基础部分,我们才能迈向下一步。

    引子 2:编程的本质

    好了,我要继续瞎扯了,首先再次回答那个问题,如何以更高效地方式进行软件开发?那么,首先我们需要找到一个解决方案,以应对那个问题:如何解决人类智商不够的问题?

    解决复杂问题

    于是,首先,让我们引入 Cynefin 框架来解决复杂问题。

    PS:复制和粘贴大法好啊,一时爽一直爽

    简单(Simple),该域中的因果关系显而易见,方法是感知——分类——响应(Sense - Categorise - Respond),我们能够应用最佳实践。

    繁杂(Complicated),该域中的因果关系需要分析,或者需要一些其他形式的调查和 / 或专业知识的应用,方法是感知——分析——响应(Sense - Analyze - Respond ),我们能够应用好的实践。

    复杂(Complex),该域中的因果关系仅能够从回想中感应,不能提前,方法是探索——感知——响应(Probe - Sense - Respond ),我们能够感知涌现实践(emergent practice)。

    混沌(Chaotic),该域中没有系统级别的因果关系,方法是行动——感知——响应(Act - Sense - Respond ),我们能够发现新颖的实践(novel practice)。

    第 5 个域是失序,该域中不清楚存在什么样的因果关系,这种状态下人们将会恢复到自己舒服的域做决定。Cynefin 框架拥有子域,简单和混乱之间的一线之隔是灾难性的:骄傲自满导致失败。

    有了这个框架之后,我们便来到了第一个结论。对于编程来说,我们的关键性问题在于:如何将复杂问题繁杂化?。因为简单的问题便简单,繁杂的问题也容易解决。

    复杂问题的应对之道

    什么是复杂问题?

    引用公司大佬的三句话:

    1. 场景多且复杂

    2. 人类的智商不够

    3. 语言不统一

    这三个问题的答案暂不免费公开,有意者可以咨询我 —— 其实都在本文里。

    看完文章后,回过头来回顾一下这个问题。

    大型组织的软件开发模式

    为了解决上述的问题,对于大型组织来说,采用的第一个模式就是:拆解。

    • 资深开发人员,设计架构

    • 中级开发人员,review 代码

    • 普通开发人员,完成开发

    • 新手开发人员,写写测试

    而就当前而言,这几个部分存在一些割裂。代码反应架构,架构实现代码。缺少相应的架构守护、质量门禁等等,并且诸如于 review 的工作是由机器完成的。

    云开发

    好了,看到这里不容易。因为剩下的内容已经不重要了。

    什么是云开发?

    再一次地,让我们看一下定义:

    云开发,是一种生于云上的闭环 + 代码化的软件开发方式。它可以让业务人员、开发人员、运营人员等在同一个云端共同协作透明化地完成整个软件的生命周期(需求、设计、编码、构建、部署、运营),而非相互隔离,又或者是借助于多个软件才能完成工作。

    于是乎,它不同于云主机 / 远程主机开发模式,只需要一个浏览器 / 客户端 / IDE,便可以在线完成:

    • 实例化需求

    • 架构、交互的设计

    • 编码的代码化

    • 自动集成与构建

    • 无环境部署

    • 人工智能运营

    举起我的炒板栗:

    1. (调试)输入一个 console.log 或者 fmt.Println 便可以在生产环境对应地打出日志。

    2. (需求直接上线)改一个 Icon 的需求,在图标上传到 Kanban 的时候。NLP 后,自动提交到代码库,部署到生产环境。

    3. (代码创建需求)把默认字体的色彩,由 #000 改成 #384452 的时候,能反触发对应的需求变更——不过就是 commit message,反向地创建需求嘛。

    4. (设计同步)模型上添加一个新的字段,对应的完成前端、后端模型的自动化更新。

    5. (代码构建同步)新的分支,新的 pipeline,用完即删。

    6. ……

    它基于这么一些原则:

    1. 代码化优于过程化数据。

    2. 流程自闭环优于交互。

    3. 度量内建优于可视化。

    要的就是这么简单,对于开发来说,只是对应于领域建模、详细设计、填空式开发等。

    如何构建云开发平台

    成熟度模型

    就定义来说,我们可以将其划分为五个阶段:

    1. 具备基本的远程编程能力及自动化部署。即代码无需在本地

    2. 在云端能完成软件开发的完整生命周期。能在云端完成所有的软件开发的工作,并且配套

    3. 云开发平台上的云开发平台。(自举)

    4. 借助于代码化的方式,将软件开发的每一个步骤都变成代码

    5. 实现开发全流程的自动优化。如自动化的蓝绿部署,自动化选择方案,自动化优化。

    6. 无人编程。Human Over

    第一个阶段。靠人海战术就可以实现了。

    第二个阶段。依赖于抽象软件开发模式。

    第三个阶段。证明自己,体力劳动。

    第四个阶段。进一步抽象软件开发。

    第五个阶段。抽象人工部分,智能完成。

    所以,嗯,大概要 N 的时间才能完成这个系统的设计。毕竟,云开发是一个复杂问题,我们需要不断拆解系统,结合微架构、代码化、协作设计三个核心要素,以免我们在历史的长河中消失。

    云开发平台基石

    虽然,我一直在强调实现只是一个细节,但是还是得大致了解一下实现机制。

    集成开发环境

    编码环境 + 设计环境。

    微信小程序、支付宝小程序、在线 Web IDE,VS Code / Monaco Editor 几乎已经当前成为了定制编辑器 / IDE 的最好选择。这样一看,JetBrains 再不努力,可能会失去未来,就像当年的 Delphi 一样,笑~。

    这方面的技术在业内已经相当成熟了,不就是加一些插件嘛。

    不过呢,它们只是在堆砌一些功能,缺乏闭环上的设计:

    1. 需求关联设计,关联代码

    2. 代码展示设计,关联需求

    3. 构建关联代码,连接部署

    如你所知的提交信息规范是一种形式,它可以关联到需求;如你所知的领域建模是一种形式,让代码关联到设计上;

    基础设施

    尽管,在文章开头的时候,我说了基础设施不重要。但是到真正需要实施的时候,我们不得不强调它的重要性。我们需要的东西有:

    • 微架构支持

    • 部署和构建支持

    • 自动配置化管理

    • ……

    而围绕在它背后的是各种模式的提炼。

    模式提炼

    无论是在哪个行业,值钱的东西在于原则与模式。原则与模式是用来快速提升能力的方式,换句话来说,就是让新手能像以大牛一样的方式工作——尽管会烂用模式。所以:

    • 代码的模式类库

    • 开发流程模式

    • 用户体验设计模式

    • ……

    这些是核心所在,抽象、提取、模式化。

    全流程闭环

    如你所猜想的一样,构建这样一个平台的难点,不在于实现功能,而在于设计。只需要保证在当前阶段的信息,能够传递到下一阶段即可,而不在于你使用什么工具。

    你可以使用 Jira、Trello、Mingle 或者基于 Git + DSL 的方式,只需要保证它们能关联到下一阶段,即可。一步步往下,将信息关联到设计、代码、构建、部署、运营,运营再反应到需求上,就能完成上的设计。

    So?

    原型设计与关键因子

    作为模式的拆解,我做了一个简单的分级,以便于一步步实现整个系统:

    需求

    事实上,采用诸如 Cucumber 一样的 Given-When-Then 三段式设计就够了。所以在我的 story 工具里,利用了注释作为额外的信息扩充。Cucumber 使用的 DSL 已经有丰富的

    # id: OGr9CObWR
    # startDate: 2019-11-21T23:44:27Z
    # endDate: 2019-11-21T23:44:27Z
    # priority:
    # status:
    # author:
    # title: add executable bin file
    # language: zh-CN
    @math
    功能:add executable bin file
     场景:
     假设:
     当:
     并且:
     那么:
    

    有了这个设计,我们可以将这个设计结合到我们的下一步设计中。

    设计

    其实 UML 本身也是一个不错的原型,只需要创建一个 DSL 将其中的一部分转成 UML,再结合一下 UI 上的 DSL 便能实现流程上的设计:

    flow login {
     SEE HomePage
     DO [Click] "Login".Button
     REACT Success: SHOW "Login Success".Toast with ANIMATE(bounce)
     REACT Failure: SHOW "Login Failure".Dialog
     SEE "Login Failure".Dialog
     DO [Click] "ForgotPassword".Button
     REACT: GOTO ForgotPasswordPage
     SEE ForgotPasswordPage
     DO [Click] "RESET PASSWORD".Button
     REACT: SHOW "Please Check Email".Message
    }
    

    最近,我们在做一个对应的架构设计平台:

    结合我的 https://github.com/phodal/design 用于代码生成设计,设计转为代码。

    代码

    代码生成并不是一件新鲜的事物,有大量的人在做大量的事件。编写一个 DSL,用这个 DSL 结合编程语言描述 DSL 来生成不同的编程语言,这便是我最近在做的事情之一。它并不复杂,只是繁琐。

    嗯,我花了很多时间在设计这个步骤的两个 DSL,其中一个是生成语言的 DSL,一个则是独立的编程 DSL。

    与此同时,对于代码来说,我们关注于:验收标准和适应度函数。

    验收标准

    • 设计生成代码,代码反应设计

    • DSL 生成代码

    适应度函数

    • 软件质量门槛

    • 自动化架构守护

    • 自动化测试生成(回录)

    • 系统演进设计

    借助于此,我们才能承上启下。

    构建

    对于持续集成来说,需要手动去配置是一个糟糕的事情。所以,我们 Jenkins 使用了 Pipeline as Code 来抽象流水线的构建。但是,它没有真正解决问题,因为现实的软件开发是非常复杂的。对于一个项目来说,它存在过多的分支,不同的构建。所以,真正意义上的持续构建,应该采用诸如于 Pipeline as Pipeline 这样的方式。

    部署

    事实上,DevOps 技术已经足够的成熟,我们已经能实施相关的步骤:

    1. 部署自动化

    2. 部署代码化

    3. 提交即上线

    4. 部署自治

    代码质量的控制,自动化测试,决定了部署成熟度。

    运营

    这一步,我还不是非常擅长,以我有限的经验来看,现有的工具就够了。唯一要做的事情是,收集数据,抽象模式,构建 DSL,串联起来。

    1. 运营可视化

    2. 运营中心化

    3. 代码化运营

    4. 运营需求化

    需求 -> 代码 -> 运营,运营反馈需求。

    云开发平台成熟度模型

    嗯,看标题就够了。

    Level 1:可追述、电子化

    Level 2:全流程闭环

    Level 3:云平台上的云平台

    Level 4:代码化云平台

    Level 5:自动化优化流程

    level 6:human over

    结论

    最后,再让我们回到这张图上:

    这就是核心所在。

    哦,对了,做平台是一件苦逼的事情。

    我的微信号:

    哦,不对~,这才是我的:growth-ren

    引用:

    • Cynefin 框架部分:https://www.infoq.cn/article/2013/10/cynefin-framework-playing-lego

    • GitHub 上的类型流:https://github.com/notyy/TypeFlow

    • 无代码编程:https://www.phodal.com/blog/low-code-programming/

    • 微前端如何落地:https://www.infoq.cn/article/xm_AaiOTXmLpPgWvX9y9

    • 需求 DSL:https://github.com/phodal/story

    • 设计 DSL:https://github.com/phodal/design

    • 编码 DSL:https://github.com/phodal/code

    展开全文
  • 软件开发概要

    千次阅读 2022-01-11 16:21:36
    分享软件经营,小白入坑必看

    根据功能不同分为:ERP软件开发、APP软件开发、软硬结合开发(例如物联网、智慧城市、车联网等,涉及到软硬件结合)、互联网项目开发

    ERP软件:企业管理软件,例如政府公务系统、企业的内部系统;

    现代企业管理的理想工具,可确保流程顺利进行。您能借助ERP解决方案的强大功能,轻松分析销售、市场营销、客户服务、订单处理、制造、库存管理等信息。

    一般为定制化开发,根据企业的实际业务,合理规划业务流程,实现企业业务信息化管理的功能。

    ERP软件是一个在全公司范围内应用的、高度集成的系统。数据在各业务系统之间高度共享,所有源数据只需在某一个系统中输入一次,保证了数据的一致性。

    对公司内部业务流程和管理过程进行了优化,主要的业务流程实现了自动化。

    Erp项目一般项目比较大,定制化开发完成后,后期主要是运维工作,整体流程固化,一般不会有大的变动。

    系统要求:安全要求一般(内网系统,一般不进行外网共享),对性能要求不高。

    APP软件:针对手机端的项目,包含ios端和Android端。ios和androis开发使用的技术是不一样的。

    ios端:指针对苹果手机的app软件开发,

    android端:值针对安卓端的app软件开发。

    软硬件结合:一般为嵌入式开发,在学习了软件技术后,还需要学习相关硬件的知识。但是硬件的标准又不统一,开发难度很大。比如:大疆的内置系统、智慧城市、城市天眼等。

    互联网项目:可以通过互联网访问的项目,一般要求美观、功能、速度、稳定性。

    特点:用户多,流量大、并发高,海量数据,易受攻击、功能繁琐、变更快。

    项目性能指标:

    响应时间:执行一个请求从开始到最后收到响应数据所花费的总体时间,要求时间尽可能短。

    并发量:系统能高并发。

    TPS:每秒处理事务的数量要高。

    高性能:提供快速的访问体验

    高可用:网站服务一直可以正常访问

    可伸缩:可以通过硬件增减,调整处理能力

    高可扩展:系统间松耦合,方便的通过新增或移除,新增或减少新的功能或模块

    安全性:提供网站安全访问、数据加密、安全存储等

    敏捷性:随需应变,快速响应。

    新技术使用比较多。

    根据架构分为:B/S项目和C/S项目

    B/S 项目:通过浏览器进行访问的项目,为架构发展趋势。

    C/S项目:通过客户端进行访问的项目,例如游戏客户端、影视客户端等

    编程语言:目前常用到的编程语言为java、php、VB、C、C++、C#

    java:面向对象的一种基础语言,使用最多的开源语言(免费)。

    C语言:使用比较窄,主要使用在银行系统、操作系统内存(linux、Windows),安全性比较高

    C++:在C语言的基础上,进行优化后的一种语言,网络游戏和部分网站使用,可视化开发,可以直接拖拽控件进行开发,控件全部封装好了。

    php:是一种通用的开源脚本语言,语法类似C语言,PHP语言具有较高的数据传送处理水平和输出水平,可以广泛应用在Windows系统及各类Web服务器中。如果数据量较大,PHP语言还可以拓宽链接面,与各种数据库相连,缓解数据存储、检索及维护压力。随着技术的发展,PHP 语言搜索引擎还可以量体裁衣,实行个性化服务,如根据客户的喜好进行分类收集储存,极大提高了数据运行效率

    VB是Microsoft公司开bai发的一种通用的基于对象du的程序设计语言,为结构化的、zhi模块化的、面向dao对象的、包含协助开发环境的事件驱动为机制的可视化程序设计语言。是一种可用于微软自家产品开发的语言

    应用软件的层级划分:表现层、ESB层、业务层、持久层

    表现层:用户直接操作的层级,包含web端、APP、微信公众号、小程序等。

    表现层与业务层完全分离,通过跨域实现前后端数据通信。

    主要使用的技术:HTML、JSP、JS、CS、JQuery等

    ESB:企业服务总线,是网络中的连接中枢,一种松耦合的服务和应用之间的标准集成方式。

    面向服务架构-分布式的应用由可重用的服务组成

    面向消息架构-应用之间通过ESB发送和接收消息

    事件驱动架构-应用之间异步的产生和接收消息

    ESB可以消除不同服务之间的技术差异,实现了不同服务之间的通信和整合。

    ESB通过接口进行数据交换:

    接口协议包含:socket通信、webservice协议、http和https协议、ftp和sftp传输

    socket通信:比较复杂的一种通信协议,遵循tcp/ip进行传输,目前很少使用。

    webservice协议:在socket之后使用比较普遍的传输方式。

    httphttps协议:目前最流行的传输方式,大部分公司都在用。

    ftpsftp传输:需要开通端口号22或21,是要用于文件上传和下载。ftp传输为Windows下的,sftp是linux下的。

    数据传输的格式:逗号分隔法、xml、json

    逗号分隔法:最早的数据方式是一串字符串,用各种特殊符号隔开,然后通过截取符号的前面,后面或之间,来获取数据。(贼累,眼睛要看花的)

    xml:可扩展标记语言,公司双方定义xml的根元素和子元素,双方开发人员都按照根元素和子元素,在里面赋值,取值,现在很多开源框架都还用xml作为存储和配置文件

    jsonJS 对象简谱。目前流行的数据传输格式,简洁,方便,易懂基本全占。目前公司都建议用json结构传输

    业务层:负责所有业务的处理和数据的传递。复杂的逻辑判断和涉及到数据库的数据校验都需要在此做处理。

    javaWeb架构演变

    阶段一:servlet阶段(MVC

    1.在该阶段架构模式中,Servlet/Filter扮演Controller角色,JSP扮演View角色,JavaBean扮演Model角色

    2.该阶段的数据库访问技术为具体DB的jdbc 

            该模式虽然实现了所谓的MVC模式,但却存在诸多问题:

          (1)前后端分离不彻底。由于JSP技术前后端分离不彻底,开发人员往往会在JSP页面中嵌套Java代码,从而需要前端开发人员懂java技术

          (2)JSP页面可读性差,编写效率低,尽管引入EL,JSTL等技术

          (3)Sevlet/Filter作为控制器,面临的稳定性,安全性考验(Servlet是线程不安全的)等

          (4)数据库访问技术采用传统的jdbc,造成过多的冗余代码

    阶段二:SSHSpring+Struts+Hibernate

    1.在该架构模式中,Controller采用Spring框架技术,View采用Structs框架技术,DB访问技术采用Hibernate框架技术

    2.从SSH中,很容易看出前后端出现了专业化,精细化分工,且朝框架演变,如前端框架采用Structs,后端框架采用Spring等

    阶段三:SSMSpring+SpringMVC+MyBatis

    该模式中,Spring扮演Controller角色,SpringMVC扮演View角色(当然,小型系统,可直接采用SpringMVC即可),Mybatis扮演DB访问技术

          SSM架构模式,在当前的JavaEE中,算是比较流行的开发模式了,也是大都数企业的技术选型之一

    阶段四:微服务思想(SpringBoot+CloudDubbo等技术)

    业务层代码块:controller/struts2/servlet、service、dao、model

    view:视图。这个很容易理解,其实view层就是用户用户可以看到的东西。后台怎么处理不关心,只关心怎么样想用户展示信息,现在大部分系统进行了全后端分离,指表现层。

    前端开发技术:基础js+css+html。

    中间演化出:aps、jsp、php、jQuery、Angular、Ajax

    报表插件:FusionCharts Suite XT、HighCharts、Google Chart Tools、Sencha ExtJS Charts、Chart.js、Flot、jqPlot等

    controller:主要负责具体业务模块流程的控制,会调用Service层的接口来控制业务逻辑。Controler负责请求转发,接受页面过来的参数,传给Service处理,接到返回值,再传给页面

    Service:业务逻辑层。接着controller层中,可以想到,service层是业务逻(

    商务逻辑)的具体实现。它向上层的controller层提供接口,并且使用dao层提供的接口。

    dao:数据访问对象。他只负责对数据进行访问,而不管其他的什么业务逻辑,其实就是只干活,而不管为什么干。在dao层里面要完成的是数据访问逻辑以及对数据的访问。数据访问,大部分情况下就是对数据进行操作。dao层为上层的service层提供接口。dao层在操作完成后,如果是查询,则返回对象,如果是增删改,则仅仅需要返回一个boolean值表示成功失败即可。

    model:业务对象模型和一些公用方法、常量。被dao层、Service层、Controller层同时使用。

    业务层向表现层和ESB层提供接口服务:webservice请求或http请求

    http请求方式:post,get,一般使用post请求。

    1、java web项目,未前后端分离,服务需要通过servlet或Struts2进行接收和响应数据。Struts2由于安全原因目前很少使用了。

    2、前端后端分离后,http请求存在跨域问题,可以通过添加请求头进行解决

    业务层在dao层,使用mybatis、hibernate与持久层进行数据交互。

    持久化层:数据的存储。

    目前常用的物理数据库,存储在磁盘空间中。

    大型数据库:Oracle、Sybase

    中型数据库:mysql、sql server

    小型数据库:access

    内存数据库:以内存为主要介质的数据库,它将数据存放在内存中直接操作,能提高应用的性能,主要使用于电商网站。

    Mongo DB、Redis、Memcached

    项目搭建:项目开发完成后,需要搭建在服务器上,在搭建过程的工作

    1、服务器环境:linux、Windows

    2、中间件:项目不能直接部署在服务器上,需要部署在中间件上,中间件部署在服务器上。常见的中间件:Tomcat、jboss、weblogic。

    3、部署方式:分布式部署、集群部署。

    项目相关工作:

    一、需求分析:

    1、相关系统分析员向用户初步了解需求,然后用相关的工具软件列出要开发的系统的大功能模块,每个大功能模块有哪些小功能模块,对于有些需求比较明确相关的界面时,在这一步里面可以初步定义好少量的界面。

    2.系统分析员深入了解和分析需求,根据自己的经验和需求用WORD或相关的工具再做出一份文档系统的功能需求文档。这次的文档会清楚列出系统大致的大功能模块,大功能模块有哪些小功能模块,并且还列出相关的界面和界面功能

    3.系统分析员向用户再次确认需求。

    工具:

    业务流程图:Visio绘图

    原型设计:Axure、摹客原型等,种类很多

    文档:word、Excel、ppt等

    二、概要设计

    开发者需要对软件系统进行概要设计,即系统设计。概要设计需要对软件系统的设计进行考虑,包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接口设计、运行设计、数据结构设计和出错处理设计等,为软件的详细设计提供基础

    三、详细设计

    在概要设计的基础上,开发者需要进行软件系统的详细设计。在详细设计中,描述实现具体模块所涉及到的主要算法、数据结构、类的层次结构及调用关系,需要说明软件系统各个层次中的每一个程序(每个模块或子程序)的设计考虑,以便进行编码和测试。应当保证软件的需求完全分配给整个软件。详细设计应当足够详细,能够根据详细设计报告进行编码

    工具:

    数据库设计:sysbase powerdesigner

    页面原型设计:Axure、摹客原型等,种类很多

    文件编辑器:notepad++、UE等等

    四、开发

    UI开发:UI用户界面开发。

    UI设计工具:Photoshop、Sketch、Axure等

    UI开发工具:Dreamweaver、WebStorm、Sencha Touch、Sublime Text等

    后端开发工具:

    java集成开发工具:Eclipse、MyEclipse、NetBeans、idea等

    文件编辑器:notepad++、UE等等

    java反编译:jd-gui

    版本管理工具:svn、gitlab、git

    自动化构建工具:Ant、Maven、Gradle等

    java单元测试:Junit等

    接口测试工具:Postman等

    规则引擎:drools、IBM ODM等

    C#相关工具:---待补充

    五、测试

    测试编写好的系统。交给用户使用,用户使用后一个一个的确认每个功能。测试同样是项目研发中一个相当重要的步骤,对于一个大型软件,3个月到1年的外部测试都是正常的,因为永远都会有不可预料的问题存在。完成测试后,完成验收并完成最后的一些帮助文档,整体项目才算告一段落,当然日后少不了升级,修补等等工作,只要不是想通过一锤子买卖骗钱,就要不停的跟踪软件的运营状况并持续修补升级,直到这个软件被彻底淘汰为止。

    测试工具:jmeter、LoadRunner

    六、运维

    FTP工具:FlashFXP、

    代码对比器:Beyond Compare 等

    Windows下登录UNIX或Linux服务器主机的软件:secureCRT等

    oracle可视化工具:pl/sql

    mysql可视化工具:mysql workbench、MyDB Studio等

    系统监控软件:CactiEZ等

    内网穿透工具:花生壳、nginx等

    负载均衡工具:nginx等

    项目计划管理工具:Project等

    Weblogic10.3.6最高兼容jdk1.6,1.7需要修改配置,1.8及以上不兼容。

    展开全文
  • 最全的软件开发报价标准

    千次阅读 2021-05-06 12:07:33
    实万软件开发过程包括从立项到完成验收全过程中,所涉及到需求分析、概要设计、编码开发、测试、验收等相关过程。 因此,实万软件开发成本就包含了这些过程中所有人力成本和非人力成本,软件维护等成本。软件报价...

    **

    最全的软件开发报价标准

    **
    不同的软件开发公司、不同的软件系统、不同的功能模块、不同的开发周期都会影响所开发软件系统的价格。
    根据功能需求文档,进行开发难易评估和开发时间评估,从而较精确的计算出需要投入的工作量,根椐各个岗位投入的工作量就能评估出比较精确的开发总费用。

    实万软件开发过程包括从立项到完成验收全过程中,所涉及到需求分析、概要设计、编码开发、测试、验收等相关过程。
    因此,实万软件开发成本就包含了这些过程中所有人力成本和非人力成本,软件维护等成本。软件报价就是成本和利润之和。
    其中,人力成本包括直接人力成本和间接人力成本;非人力成本包括非直接人力成本和非间接人力成本。
    实万软件报价系统

    直接人力成本包括开发方项目组成人员的工资、奖金、福利等人力资源费用。其中,项目成员包括参与该项目开发过程中的所有开发和支持人员,如项目经理、需求分析人员、设计人员、开发人员、测试人员、部署人员、用户文档编写人员、质量保证人员和配置管理人员等。对于非全职投入该项目开发工作的人员,按照项目工作量所占其总工作量比例折算其人力资源费用。

    间接人力成本指开发方服务于开发管理整体需求的非项目组人员的人力资源费用分摊。包括开发部门经理、项目管理办公室人员、工程过程组人员、产品规划人员、组织级质量保证人员、组织级配置管理人员、商务采购人员和IT支持人员等的工资、奖金和福利等的分摊。

    直接非人力成本包括如下:

    1. 办公费,指开发方为开发此项目而产生的行政办公费用,如办公用品、通讯、邮寄、印刷和会议等;
    2. 差旅费:指开发方为开发此项目而产生的差旅费用,如交通、住宿和差旅补贴等;
    3. 培训费:指开发方为开发此项目而安排的培训产生的费用;
    4. 业务费:指开发方为完成此项目开发所需辅助活动产生的费用,如招待费、评审费和验收费等;
    5. 采购费:即开发方为开发此项目而需要采购专用资产或服务的费用,如专用设备费、专用软件费、技术协作费和专利费等;
    6. 其他: 即未在以上项目中列出但却是开发方为开发此项目所花费的费用。

    间接非人力成本指开发方不为开发某个特定项目而产生,但服务于整体开发活动的非人力成本分摊。包括:开发方开发场地房租、水、电、物业,开发人员日常办公费用分摊,战略、市场宣传推广、品牌建设、知识产权专利等费用分摊,以及各种开发办公设备的租赁、维修和折旧分摊等。
    还包括其他支持服务,培训及售后等活动所需要的各种成本,如数据迁移费和维护费等。

    **总结:**小公司甚至根本不知道软件报价要涉及这么多因素,只简单根据功能需要的工时报价。售后不能保证。大公司报价单都体现着专业。因为术业有专攻,每个岗位都有专门的人才执行落地,售后保证无忧。所谓一分价格一分货在软件行业也是试用的。所以定制软件不能只看报价,要综合所有因素考虑。毕竟软件不像别的产品。没有好的售后,基本就是买了个寂寞和烦恼。

    展开全文
  • 软件测试和开发比例

    千次阅读 2020-12-11 20:03:55
    我知道这不是一道编程题,但我想,这个问题与软件开发密切相关,所以我希望这个问题不要被关闭,以便能得到专业的回答。 1、回复一: 这是我的个人经验。在微软我们有一只强大的测试开发组织。这和传统的QA有点...
  • 软件开发管理与质量控制

    万次阅读 2018-11-12 19:51:48
    软件开发管理与质量控制
  • 软件开发中的瀑布模型

    万次阅读 2017-07-04 14:30:02
    软件开发的流程 软件开发的流程有很多种模型,这里讲的一种软件开发的流程是瀑布模型  瀑布模型是将软件生存周期的各项活动规定为固定顺序的若干阶段工作,最终得到软件产品。 他的核心思想是按工序将问题化繁为...
  • 软件开发V模型--解读

    万次阅读 2018-07-04 10:03:42
    RAD(rap application development),就是软件开发过程中的一个重要模型,称为快速应用开发模型。其模型构图形似字母V,所以又称V模型。 他通过开发和测试同时进行的方式来缩短开发周期,提高开发效率。可以说,V模型...
  • 本文将向各位读者展示如何开发杀毒软件。 在很多人思维中,特别是IT从业者、程序员看来,杀毒软件及其开发技术历来是...本文将从杀毒软件开发方案、功能结构设计、界面设置、代码编写、实际应用等各方面,逐步展示...
  • 软件开发已成为世界几乎每个部门不可或缺的一部分,因此软件开发的发展和变化对我们的生活产生了巨大影响。尽管我们无法始终准确地预测技术的发展前景,但我们仍有望在新的十年中延续一些趋势。 以下是我们预测并...
  • 软件开发过程改进为什么能帮助软件质量提升?
  • 浅谈工程化软件开发和维护

    千次阅读 2019-10-15 19:01:55
    题目不难,工程化思想在软件开发和维护的作用。以下是论文部分,很多东西都很肤浅,很多概念我也不是很清楚,也有很多地方是在网上查找到不能算我个人的东西,当个玩物看看就好。各位看官,如有雷同,莫怪莫怪。 浅...
  • AV1编码技术详解

    万次阅读 2020-12-18 20:18:23
    AV1,目前业界最新的开源视频编码格式,对标专利费昂贵的H.265。它由思科、谷歌、网飞、亚马逊、苹果、Facebook、英特尔、微软、Mozilla等组成的开放媒体联盟(Alliance for Open Media,简称AOMedia)开发。而当前...
  • 在嵌入式软件开发,包括单片机开发中,软件架构对于开发人员是一个必须认真考虑的问题。软件架构对于系统整体的稳定性和可靠性是非常重要的,一个合适的软件架构不仅结构清晰,并且便于开发。 我相信在嵌入式或...
  • Python-编码

    千次阅读 2020-12-23 12:51:20
    字符编码的常用种类介绍第一种:ASCII码ASCII(American Standard Code for Information Interchange,美国信息交换标准代码)是基于拉丁字母的一套电脑编码系统,主要用于显示现代英语和其他西欧语言。它是现今最通用...
  • 信息编码基本原理 我们日常甚或中
  • 7、软件工程-编程.pdf

    2022-07-02 11:25:11
    SOFTWARE ENGINEERING 软件编程 软件编程 福州大学·软件学院·软件工程系 王灿辉(wangcanhui@fzu.edu.cn...从而 把编码降到某种机械地翻译详细设计规格说 明书的地位,按40-20-40规则只开发工 作量的20%左右(不含
  • 软件开发人/月成本估算方法

    万次阅读 2018-05-23 09:21:45
    软件项目管理软件开发阶段:需求分析、系统设计、编码、测试、项目管理、文案软件开发人月成本估算方法1 开发人员工资 B 2 国家规定的福利(五险一金):0.476B 3 奖金以及物资奖励(过节费等):0.2B 4 办公成本...
  • 软件开发V模型

    万次阅读 2014-11-02 21:47:12
    RAD(rap application development),就是软件开发过程中的一个重要模型,称为快速应用开发模型。其模型构图形似字母V,所以又称V模型。 他通过开发和测试同时进行的方式来缩短开发周期,提高开发效率。可以说,V...
  • JAVA软件开发了解

    千次阅读 2018-09-13 16:50:16
    2.1.1 什么是软件开发 软件开发是根据用户要求建造出软件系统或者系统中的软件部分的过程。软件开发是一项包括需求捕捉、需求分析、设计、实现和测试的系统工程。软件一般是用某种程序设计语言来实现的。通常采用...
  • 软件开发模型: 定义: 软件开发的全部过程、活动和任务的结构框架,通过该模型能清晰、直观地表达软件开发全过程,明确地规定要完成的主要活动和任务,它奠定了软件项目工作的基础。 其中最为代表的就有此五类模型...
  • 字符编码那些事--彻底理解掌握编码知识

    万次阅读 多人点赞 2020-05-04 16:42:33
    每一个程序员都不可避免的遇到字符编码的问题,很多人在字符编码方面同样遇到不少问题,而且一直对各种编码懵懵懂懂、不清不楚。这篇文章就是针对字符编码中的一些问题进行了详细的阐述,能从根本上理解字符编码
  • 为什么需要软件开发报告

    千次阅读 2014-12-18 17:08:19
    一份好的软件开发报告要完整地体现出来,必须包含软件开发的各个方面:软件需求分析、软件概要设计、软件详细设计、软件数据库设计、软件编码、软件测试、软件交付准备、软件鉴定验收、培训等一系列工作。...
  • 软件开发人月成本估算方法

    千次阅读 2017-06-15 17:16:10
    软件开发阶段:需求分析、系统设计、编码、测试、项目管理、文案 软件开发人月成本估算方法 1 开发人员工资 B 2 国家规定的福利(五险一金):0.476B 3 奖金以及物资奖励(过节费等):0.2B 4 办公成本...
  • 一文带你弄懂C++中的ANSI、Unicode和UTF8三种字符编码

    千次阅读 多人点赞 2021-10-31 21:13:23
    在日常的软件开发过程中,会时不时地去处理不同编码格式的字符串,特别是在处理文件路径的相关场景中,比如我们要通过路径去读写文件、通过路径去加载库文件等。常见的字符编码格式有ANSI窄字节编码、Unicode宽字节....
  • 完整软件研发流程

    万次阅读 多人点赞 2019-09-16 13:04:45
    软件产品开发流程: 下图所示的是一个软件产品开发大体上所需要经历的全部流程: 1、启动 在项目启动阶段,主要确定项目的目标及其可行性。我们需要对项目的背景、干系人、解决的问题等等进行了解。并编制...
  • CPAT:转录本蛋白编码能力预测软件

    千次阅读 2019-01-28 19:59:00
    欢迎关注”生信修炼手册”!随着高通量测序在lncRNA研究领域的应用, 越来越多的lncRNA被发现。对于转录组测序的数据而言,组装得到转录本之后,首先要做的就是区分蛋白编码和非蛋白编码...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 46,505
精华内容 18,602
关键字:

编码占软件开发