软件构建

目录

• 面向对象 Object-oriented
  • 抽象
  • 封装
  • 继承
  • 多态
• 子程序
• 软件从c盘插件文件加载插件
• 程序布局
• 对于修改保存功能的处理
• 项目经验及总结：
  • 1、前期需求
  • 2、需求后详细设计
  • 3、开发编码
  • 4、编码后功能自测及检查
• 中小型软件开发
  • 1、软件整体布局
  • 2、使用的界面框架（这个可以和整体布局在一起，整体布局也需要依赖使用什么样的界面框架，但是依赖较小）
  • 3、布局好了以后，每一块的功能开发
• 事务安排软件
• 界面布局素材

ADT（抽象数据类型）：指数据以及对这些数据操作的集合

不要让ADT依赖于存储介质

给类

面向接口编程，而不面向实现

先完成接口的设计和编写，以及各接口之间的衔接，再完成实现类的编写

面向调用编程

面向扩展编程

对扩展开放，对修改封闭

把自己当建筑师来写

特别注意：软件中临时数据和要永久保存数据的区别，分清楚什么是临时使用，什么是永久要存的，软件就好做多了

面向对象 Object-oriented

抽象

把一类事物的公有的属性和行为提取出来，形成一个物理模型，这种研究问题的方法称为抽象

面向对象：把整个世界都看成是对象组成的，任何对象都具有属性和行为。所有的一切都是对象！！！

面向对象的编程，并不是类越多越好，类的划分是为了封装，分类的基础是抽象，具有相同属性和功能的对象的集合才是类。

面向对象需要封装变化点

封装

隐藏信息：把坏的东西隐藏起来

继承

注意区分继承和组合

多态

子程序

防止神秘数值

函数输入参数
指针：const Customtype* const pVal 加const保护输入
引用输入：加const保护

把问题暴露出来，而不是为空或者隐藏起来

参数个数上限7个

防范数据错误
nan、inf等 除零要判断 负数不能开根号等

软件从c盘插件文件加载插件

软件exe启动以后，查找指定目录dll，在

程序布局

程序首先是为人写的，其次才是为机器

像写书一样，将程序分成章节、段落和句子

代码结构清晰的重点还是在程序逻辑组织上面，好的代码考验程序员要有强的逻辑组织能力

switch块的布局应该像示例1一样，而不是示例2，因为示例2的break没有与之等价的左括号。

// 示例1
switch (i)
{
    case 1:
        // ...
    break;
    case 2:
        // ...
    break;
    default;
}

// 示例2
switch (i)
{
    case 1:
        // ...
    	break;
    case 2:
        // ...
   		break;
    default;
}

对于修改保存功能的处理

1、内部维护增删改列表

优点：保存时快，不用对比
缺点：内部代码需要维护增删改列表，导致代码变复杂，后期维护困难，容易出bug

2、在保存时对比改前和改后数据列表

优点：不用维护中间列表，不会由于需要记录数据的修改而增加复杂度
缺点：最后保存时做了过多的对比，造成保存时白白多做了事情，浪费性能

先做完，再完美！~~~~

项目经验及总结：

1、前期需求

在写代码前，若需求不是特别明确，要提前设计好对功能的扩展，防止后面需求更改会引起较大的结构改动，
需求现在暂时说不要的东西，后面肯定还会要，不要以为不会做。

看需求的时候要把所有的地方都仔细了解到，不清楚的地方一定要问需求。

需求中没写清楚的，如规则等，自己整理清楚记录下来，后面测试或其他人肯定还会问到。
对于需求中确定要做的，确定不做的，和不确定做的三种要明确下来，不确定的编码时要做好扩展

在开发功能前，对自己将要开发的功能要足够熟悉，从界面到后台的处理和所有数据的交互，即使领导没有要求写详细设计，在开发功能前也要写一个简要功能设计来帮助自己，后面的开发工作则按照这个来完成。当功能简单时可以仅参照需求来完成开发，而遇到一些复杂的功能时，在开发之前可能觉得内部代码逻辑在自己的掌握之中，而在开发过程中，由于中间需要维护的变量增多，中间的各种数据传来传去，代码的质量就下降了，即使这样功能完成了，后期也难以维护和增加新的功能，所以写这样一个功能设计是很有必要的。可以不需要太规范，但一定要实用，最重要的是要将功能中的复杂之处分析清楚。

1、分析详细的操作流程

2、看看可以使用哪种设计模式

报需求bug

1. 关键词错误
2. 规则错误（规则不明确，规则缺少，规则错误）

事情不要想当然哦

2、需求后详细设计

拿到分配的功能及对应需求后，首先将功能按步骤分解，拆分成多个小部分，然后写个大致的计划，相当于是概要设计了。

前期需求评审及详细设计时，要以进行开发工作的角度来看，如果前期需求了解不到位，仅仅走个过程，这部分时间都浪费掉了，做的详细设计都没有用上，前期的工作都白做了
主要原因还是前期的需求分析和详细设计的分析都过于浅显了。

3、开发编码

开发的时候，不要写一点代码就测试，这样过于浪费时间，多写几处在调试，多次调试打开软件也浪费时间。

跑通流程

代码编写完后仔细检查，编码质量不高
编码的时候多做容错，容错的地方各种情况都要考虑到，第一次编码要尽可能的完善，减少问题，后面模块检查消除bug就会减少
做完以后，各种各样的操作都要试一遍，仔细检查，杜绝可能出现的各种问题。

软件中如何尽可能少的使用标记

在逻辑复杂的地方，代码较长时，变量命名最好要符合意思，长一点没有关系，这样在后面自己更改时也更容易看懂

4、编码后功能自测及检查

如何测试自己的功能：做完后先按照需求中正常操作进行一个测试，自己的功能是否符合需求中每一个条目，如果没有问题，再操作与该功能相关的功能，测试其他功能的操作是否对本功能有所影响（自己不仔细测，后面造成的苦果还是自己难受）

功能多人协作

减少相互之间的耦合，减少沟通的成本

1、写代码的效率

先去做，然后发现你需要的东西；而不是先去找需要的东西，再去做

2、解决bug的速度/解决问题的能力

3、表达能力

2020-11-26

上午调了很久的页签切换菜单，下午依据第三方库已有的封装搜索框，遇到命令绑定无效问题，搞了一下午，问题还没解决，本来要修缮的子窗口一个都没调 ，其中穿插有同事问问题，包括领导和小弟；晚上调了下图标，对图标的应用纠结了，使用png和第三方icon两种

2021-3-24 施工仿真软件

1. 前期对应需求的时候要把自己对应的都要了解清楚，不能有遗漏的地方，功能操作逻辑都要理清楚

2. 详设阶段尽可能的把设计做完整一些，最好不要有遗漏的角落，因为编码的时候还是跑不了（不少卡的地方，这里的时间要提前算进去）

3. 编码阶段遇到了一些问题，一部分是技术问题（大大小小的譬如智能指针与普通指针问题，智能指针shared_ptr自己超出作用域释放了内存问题，但osg的好像不会，机制不一样）；

   还有是业务代码带来的问题，譬如界面面板和对应逻辑的机制，或者是业务代码带来的逻辑问题

4. 对于是技术问题或者是业务问题带来的有风险的地方，要注意下。

5. 有界面的要先做界面显示部分，在处理内部逻辑

6. 没好好休息

7. 明确哪些是自己要做的，不要做别人的功能，有需要要向别人提

8. 过段时间与上级交流做到了哪一步，哪里有问题要提出来

9. 严格按计划来，需求前期每一个细节都要了解好，不要管别人的

10. 一个界面数据显示，一个内部逻辑数据，对搭界面还是不够熟悉

技术问题：

1. osg碰撞求交，多面体求交
2. osg相机位置姿态设置
3. 多线程问题，两个线程之间数据传递，使用同一变量等等

有思路-打通流程-详细设计-编码-接口-打通流程-函数伪代码-具体实现

中小型软件开发

主要分为三大块：

1、软件整体布局

可以参考其他的主流软件的布局，如vscode、vs、钉钉和日常使用的软件布局

2、使用的界面框架（这个可以和整体布局在一起，整体布局也需要依赖使用什么样的界面框架，但是依赖较小）

3、布局好了以后，每一块的功能开发

事务安排软件

时间四象限

添加代办事件 时间设置 起始时间到结束时间 到结束时间后 闹钟

未完成的原因

界面布局素材

弹出框