杂项

这篇文章总结了网络编程常见名词汇总，是博主自己的理解，如果和你的有出入，一切以你为准，博主欢迎交流。

SMART 可以指导我们置顶目标，评估目标的合理性，符合 SMART 原则的目标一般都是务实的，如果你也在苦恼于置顶目标、拆解目标不妨试试。

所谓 SMART 原则，即：

1. 目标必须是具体的（Specific）

2. 目标必须是可以衡量的（Measurable）

3. 目标必须是可以达到的（Attainable）

4. 目标必须和其他目标具有相关性（Relevant）

5. 目标必须具有明确的截止期限（Time-based）

SMART 原则一 S(Specific)——明确性 　　所谓明确就是要用具体的语言清楚地说明要达成的行为标准。明确的目标几乎是所有成功团队的一致特点。很多团队不成功的重要原因之一就因为目标定的模棱两可,或没有将目标有效的传达给相关成员。

SMART 原则二 M(Measurable)——衡量性 　　衡量性就是指目标应该是明确的,而不是模糊的。应该有一组明确的数据,作为衡量是否达成目标的依据。

SMART 原则三 A(Attainable)——可实现性 　　目标是要可以让执行人实现、达到的,如果上司利用一些行政手段,利用权利性的影响力一厢情愿地把自己所制定的目标强压给下属,下属典型的反映是一种心理和行为上的抗拒:我可以接受,但是否完成这个目标,有没有最终的把握,这个可不好说。一旦有一天这个目标真完成不了的时候,下属有一百个理由可以推卸责任:你看我早就说了,这个目标肯定完成不了,但你坚持要压给我。

SMART 原则四 R(Relevant)——相关性 　　目标的相关性是指实现此目标与其他目标的关联情况。如果实现了这个目标,但对其他的目标完全不相关,或者相关度很低,那这个目标即使被达到了,意义也不是很大。

SMART 原则五 T(Time-based)——时限性 　　目标特性的时限性就是指目标是有时间限制的。例如,我将在 2005 年 5 月 31 日之前完成某事。5 月 31 日就是一个确定的时间限制。没有时间限制的目标没有办法考核,或带来考核的不公。上下级之间对目标轻重缓急的认识程度不同,上司着急,但下面不知道。到头来上司可以暴跳如雷,而下属觉得委屈。这种没有明确的时间限定的方式也会带来考核的不公正,伤害工作关系,伤害下属的工作热情。

一、项目相关

1.1 项目总结内容要求

在每个项目总结项目开始前每个人要统计自己的问题。

统计方式:

• 遇到的问题有哪些?
• 已经解决多少？还未解决的剩多少？

1.2 技术解决方案

做项目的时候，每个人都需要出技术解决方案，特别的如果项目小或学长说不出则不用写。

技术解决方案内容：

1. 描述需求、实现
2. 设计思路（字段、输入、输出）
3. 上下游依赖
4. 风险点

组内成员关注自己业务技术问题即可，成员写时遇到困难负责人做过项目的有义务带新同学写技术解决方案；组长整理并完善本组技术解决方案；总负责人负责项目核心技术解决方案。

截止到昨天晚上十点多我们的项目主要功能的开发算法完成, 占整个项目的 80%, 后期需要确定科研管理系统教师数据的导入方式, 待老师测试通过后部署算是整个项目的结束. 在这次项目中我是担任整个团队的负责人, 并未过多的参与到编码中, 这次开发整体来说还是比较顺利的, 没有遇到特别难的技术点和业务逻辑. 我之前从未担任过项目项目负责人, 这次算是过了把瘾吧. 在我担任负责人的这段时间我并未觉得比在开发中轻松, 在开发中我主要关注的是自己的业务和技术点, 而站在项目负责人的角度则要对整个项目进行把控, 而不仅仅是业务和技术点. 目前项目进入收尾性 bug 修复, 开发的脚步放慢, 待和院里老师交接后继续进行开发, 之后的工作不会多了. 今天抽空把开发中遇到的问题以及感受总结一下.

---

以上的内容引自陈浩的开发时间估计这篇博客. 在项目开发中有一定的参考意义, 如果是工期较短的小项目, 没有必要花费这么长的时间.

项目评估的合理与否直接体现了项目负责人的能力, 往往有能力的能根据团队人员情况和项目情况安排出合理的时间.

合理评估开发时间, 项目负责人需要注意的几点:

• 对团队人员情况有较详细的了解
• 对项目有一定的把握能力
• 对项目风险点有一定预见与把控能力
• 注意项目之外的因素

之前学习 git 是在廖雪峰老师的网站上，廖雪峰老师的 Git 教程也是非常不错的，举的例子很生动。

作为一个合格的开发人员，熟练使用 Git 是必要的。

现在多人开发项目没有一个合作开发的工具是不行的，在 Git 诞生之前 SVN 很流行，它属于一种集中式的开发写作工具，而 Git 是一种分布式的代码管理工具，二者各有优缺点，SVN 集中式管理使代码相对来说比较安全，但是当用户数量上来后服务器带宽和处理压力也就上来了，所多人在 SVN 系统上合作开发对服务器要求较高些，在 Git 这边，每一个都可以独立工作，每一个都是主仓库的一个副本，即使主仓库被破坏代码也不会造成过大损失。

还回到 Git 教程，看了 Git 官网的教程，突然觉得廖老师的 Git 教程不香了。

这是时我在学习编程时候写的一些 demo 程序或者帮别人写的 java 的程序设计作业，有需要的可以拿去参考一下。我已经把系统的介绍和运行截图放在了每个项目里。

Github Repo：https://github.com/elltor/demo-program

这个项目是我校在疫情期间管理人员出入的系统，为我校保卫处、教职工和来访我校人员所使用，项目开发一段时间了，最近在统测，也快交付了。

前台是基于微信公众号开发的，后端和后台是基于 eladmin 进行二次开发；这次我负责后台，基于 Vue 进行开发，整个开发过程算是比较顺的，遇到问题找小桑和腾飞学长问一下很快就解决了；这次项目跟在学 Vue 时的感受有很大不同，通过 eladmin 后台我对 Vue 的模块化开发、封装、路由、状态管理有了更多认识。

刚接触 eladmin 后台的时候觉得有点难，这个后台框架封装的比较厉害（做了很多封装），尤其是它全局 mixin 的 crud 封装，不过，不得不说，这样做极大的减少了重复的代码，是很好的代码抽离！这是在平时学习 Vue 接触不到了。

这次项目中引入了 Echart 图表，学了一上午算是成功让其在项目里显示了出来，简单封装了一个组件，方便之后再次使用。

对整个项目后台环境了解后其他的就很容易了，这次项目并不算难。

项目中出现的问题：

1. 测试的时候大家比较急，测试太乱
2. 前台开发过程心态不好，导致后期开发缓慢

对于出现的问题，最根本的原因是缺乏沟通，其次是对所用技术把握，因此导致开发缓慢，最终致测试出现较多问题。总结，沟通是协作的基础，尤其是高效沟通；对应用的技术熟练且有深入理解是高效开发的必要条件。

在钉钉小程序中页面由 js、json、acss 文件组成，其中 js 用来存放小程序的逻辑代码，json 用来存放小程序的公共设置，acss 用来存放页面的样式。

在页面中可以放置 page、component、template 等组件。