配置背景 大多数项目中，都会有没办法使用前端工程化方法维护的html页面，或者使用jade/pug(下文统称pug)技术来维护这些html页面。 其实pug技术也不是全能的，毕竟还要经过一次编译，对本地环境需要有node.js的要求。 对于不方便安装node.js的机器，开启nginx/httpd的ssi配置项能够极大的提高代码的可重用性。 配置方法，以nginx为例 nginx是使用配置文件来描述提供服务的项目，对于那些需要开启ssi配置项的项目，可以在对应的server描述中添加下列配置项： ssi on; ssi_silent_errors off; ssi_types text/html; 重启nginx或重载nginx配置项后，ssi功能便启用啦，详细的配置项字段值参考nginx文档https://nginx.org/en/docs/http/ngx_http_ssi_module.html ssi的使用方法 他的使用方法，建议参考php的文件引入，两者功能很相似。 <!-- #include file="文件名称" --> <!-- #include virtual="文件名称" --> file描述的是服务器上的绝对路径 virtual描述的是相对于服务器根目录的相对路径 正确的使用ssi会极大的降低html的可维护性，读者可以自行尝试多种可能性，比如网站主题换肤(所有html共用模板文件，共同引入主题样式文件；或者引入子文件夹中的主题样式文件)。 虽然ssi不能像webcomponent或pug那样灵活，但是相较于纯html项目来说已经是前进了一大步。

贴近下属，但也要远离下属。贴近下属的生活，原理下属的生活职业规划。如果想贴近下属的职业规划，争取为下属涨薪就是最好且最优的选择。 学会察言观色。不是附和，而是知趣。别人不想听的时候，就不要浪费各自的时间了。 培育下属固然重要，但不是拔苗助长，不是强行灌输自己的思想就一定能达到自己的目的，通常情况下都会适得其反。 每个人都是隐藏的金子，要善于发现下属的优点并能让他得到成长，让他得到成长不是把本不该下属做的事分给下属做。发现优点是一个闪光的过程，不是让下属害怕优点被发现的过程。 人是过程的集合，固然有一段经历会让人影响深刻，但这段经历不是止步不前的理由。 当今的管理学有相当一部分的应用是错误的，不要照搬照抄，比如人效，只要保证每个人的工作能够顺利按时完成即可，只要份内工作做完了，哪怕坐在工位上打游戏看电影又有何妨。要求下属延长工时，又不发放福里，相互折磨不说，还会疏远管理者与下属之间的关系。 管理者什么都会并不是一件好事，甚至很有可能动摇管理者的权威。什么都会，但什么都不精通，不管拿什么出来都会成为笑话。 学会说话，要能委婉但又犀利地描述自己的观点。在照顾双方情感的基础上，不拖泥带水，不浪费时间。 自降身段是拉近上下级关系的有效方法，但不是把手伸进别人的私人空间里。 别人拍马屁是喜欢，但自升身段是纯属自恋。 管理是要管在实处的，不是流于表象的，如果是演出来的管理，不如选择不浪费时间，至少不会疏远与下属间的关系。 饼可以画，但是既然画了，就最好要做到，如果做不到，不如重新定一个小一点的可行目标。虽然可能给不了一个长久的未来，至少要证明现阶段的正确性。 谨言慎行，每一句“随便”说出来的话都会把下属“随便”记住。口碑对于管理者也很重要。要学会多放下，多夸赞。 “这个人有思想”应该是别人给自己的评价，不能是自评出来的。 新想法的提出是要经过可行性论证的，不是每个新想法都百分百可行，不是每个新宪法都一定要落地，要选择性的使用这些想法。经过一段时间的沉淀之后冒出来的新想法是清爽可口的盐汽水；源源不断冒出来的新想法是在炉子上烧开105读的蒸馏水。

公式 行列式 $|A| = a_{i1}A_{i1}+a_{i2}A_{i2}+…+a_{in}A_{in}(按行展开)$ $\quad \ = a_{1j}A_{1j}+a_{2j}A_{2j}+…+a_{nj}A_{nj}(按行展开)$ 特别的 （1）上、下三角行列式：主对角元素的乘积 $$ \left|\begin{matrix} & a_{12} & & \cdots & a_{1n} \\ & & a_{22} & \cdots &a_{2n} \\ & & & \ddots & \vdots \\ & & & &a_{nn}\end{matrix}\right|=\left|\begin{matrix}a_{11} & & & \\a_{21} & a_{22} & & \\\vdots & & \ddots & \\a_{n1} & a_{n2} & \cdots &a_{nn}\end{matrix}\right|=\left|\begin{matrix}a_{11} & & & \\ & a_{22} & & \\ & & \ddots & \\ & & &a_{nn}a_{11}\end{matrix}\right| $$...

问题描述 现在，在我国来看，无论大中小三种企业，均喜欢使用软件工程过程中的“敏捷模型”。 使用了“敏捷模型”的企业，大多的软件流程如下： 产品经理产出原型 架构师/主管开始拆分模块并分配至开发人员 产品经理开始补文档 这种方法虽然开发速度快，但是实际上，整个开发团队对于需求的理解是模糊的。 这种流程，在需求确认的时候，无法拿出一份符合软件行业规范的文档，仅仅以原型作为展示，来与客户、开发、测试等人员进行沟通。 实际上，纵观软件工程的发展史，我们就会发现，一切回到了最初的起点：软件危机。 仅使用原型来与客户进行需求确认，导致客户确认的需求比较模糊 架构/主管按照原型进行模块划分，导致软件整体架构是按照当前需求最优的，后期需求一旦变更，就会导致大面积的代码变更 模块虽不会对开发人员产生模糊，但是由于需求实际上并不是“确认”的，开发人员将可能产出错误的软件实现。 将对测试人员的工作产生巨大的影响，比如，测试人员认为有问题，但是开发人员认为没问题，产品经理也坚持没问题/下一版再说。 缺少文档、需求模糊、更改耗时耗力、一再拖拉，传说中的软件危机就这样再一次出现了。 如何避免和改善： 一日没有《需求分析说明书》，开发人员和测试人员就一日不应工作。

软件的定义 根据《软件工程》的规定， 软件 = 文档 + 数据 + 程序 我们能了解到，程序只是软件的一部分。 我们也可以获得软件的定义： 软件是采用了适当的算法与数据结构，并拥有完备的软件描述信息的一套指令的集合。 软件工程的关注点 我们都知道，（一套高质量的）程序是软件工程的最终目标，但是，程序并不是软件工程的关注点，文档与过程才是。 软件过程的开始 当项目立项后，可行性分析认为**“可行”**时，就正式的进入了软件工程过程。 （在这里，我不将可行性分析阶段算入软件工程过程，因为若可行性分析的结果是“不可行”，那么软件将不会存在） 软件过程的核心文档 《需求分析说明书》将成为了软件的第一个部分。它是软件工程过程中，最重要，也是最容易出现问题的部分。 当进入了需求分析阶段时，以最普遍的W模型来看，意味着测试工程师可以开始工作了，也即整个软件团队的成员都需要开始工作了。《需求分析说明书》就像一块凝结核，软件会在这个“凝结核”的基础上逐渐生长，慢慢成为坚固的“晶体结构”。 程序与软件的对比 我们再反观程序。程序就不一样了，在程序中，一定要有可运行的计算机代码，如果没有可运行的计算机代码，那么程序只能叫做算法，或是PDL。相比较于软件的“晶体结构”，程序就是一盘”散沙”，虽然掺点水可以做成沙堡，但是非常脆弱。 广义化的软件 那么站在软件工程过程上来说，我们就可以这样广义化描述： 当文档开始进入了软件工程过程时，即可被称之为软件。 在这种描述下，软件可以（在软件过程中）脱离程序而独立存在，也可以结合程序达到最终目标，但软件绝对不等价于程序。

软件工程师 程序员/码农 学历要求 本科及以上 专科及以上 工作 内容 设计并完善软件系统， 保障软件代码的高可重用性 写代码，能运行就行 职位 设计者 实施者 软件工程 注重软件工程流程 无 框架语言要求 低 高 软技能要求（代码洁癖、 计算机原理、算法等） 高 低 文档能力 高 低 工作中的关注点 人机交互 功能正确 团队精神与协作能力 高 中 需求理解能力 高 低 模块化思维能力 高 中 数学与建模能力 高 低 测试能力 高 低 工作量 中 高 从事工作技术含量 高 低 英语 高 低 进度与质量把控 高 低 自我驱动力 高 低 工作交付时完成的任务 需求文档 软件代码 软件设计书 单元测试 集成测试 系统测试 UI测试 交付说明书 软件使用说明书...

一、古典概型 摸球问题 一把抓（无序）： 组合 逐个取（有序）： 不放回： $n\Omega$ 要逐渐减小 放回【独立】：$n\Omega$不变 抽签摸奖与次序无关：若a个中奖球，b个不中奖球，前n-1次不明确，那么第n次中奖的的概率即$\frac{a}{a+b}$ 分房问题 指定 （不用选） 恰 （需要选） 人数要求 取样问题 含与不含 或与且 最大与最小 二、几何概型 长度、面积、体积的比值 三、事件的运算 包含、相等、和、积、差、互不相容、对立 $P(A-B)=P(A\bar{B})=P(A)-P(AB)$ 互不相容 ：$AB=\phi$ 对立 ：$AB=\phi$ 且 $A+B=\Omega$ ( P(AB)=P($\bar{A}\bar{B}$) ) 互不相容 $\overset{\nrightarrow}{\leftarrow}$ 对立 事件关系 $\overset{\nleftarrow}{\rightarrow}$ 概率关系 概率等式关系 $P(AB)\overset{独立}{=}P(A)P(B)$ P($A_先B_后$) $\overset{乘}{=}$ P(A) P(B|A) P(AB) $\overset{加}{=}$ P(A) + P(B) -P(A+B) P(AB) $\overset{减}{=}$ P(A) - P(A$\bar{B}$) = P(B) - P($\bar{A}$B) P(AB) $\overset{对立}{=}$ 1 - P($\overline{AB}$) = 1 - P($\bar{A} \bigcup \bar{B}$) 四、概率不等式关系 0 $\leq$ P(A) $\leq$ 1 A$\subset$B $\Longrightarrow$ P(A) $\leq$ P(B) P(B|A) > P(AB) AB $\subseteq$ A $\Longrightarrow$ P(AB) $\leq$ P(A)...