观后感

[cflw]

在网上偶然看到此库，观看代码后写下此观后感。

1. 开发者明显不懂网络，或者说对网络的理解只停留在企业网这一级，对运营商级别的网络完全不懂。大部分操作只是看一看信息，还有一些简单配置，没有复杂配置。

2. 把网络设备的所有操作塞进一个类中不累么。

3. 文件名只写型号不写品牌不怕存在不同品牌相同型号的情况吗？

4. 同型号不同系统版本的命令可能不一样，只有型号没有版本会翻车的。

5. 该升到Python3了。

6. 开发者们先去考个CCIE或HCIE再来写吧。没考虑到网络设备的所有功能，没做好设计就直接写了，完全没扩展性啊。

[headkarl]

感谢细心查阅代码并给出意见，在这里对这几条意见作出回应：

第1、6点确实是开发者的软肋，原子功能过少也一直是Forward的短板，原因如下：
在企业内部，forward之上还有两种封装形态，一种是网络微服务模块，另一个是网络业务运维模块，其实高级的运维场景都在这两种形态中实现，开发人员也是CCIE级别，但并没有开源；而forward受限于人力和测试机器不足，所以目前只能专注于底层通道的实现，提供通用的excute和command函数供上层封装，开发者是运维研发，更关注通性需求。目前上层的业务实现也正在逐渐拆分通用方法下沉到forward中，很高兴您能看到这个问题。

第3、4点是我在关注同类型开源模块的过程中也意识到了，不过拆分版本带来工作量非常大而收效较少（目前forward的应用场景基本集中在命令行模式，在我们能进行的测试范围内，版本差异对命令影响基本可忽略），后面会计划采取更科学的类库命名方式，同时也欢迎大家贡献代码。

第5点关于python3的问题，当前版本已经是兼容状态。

最后关于第2点，根据设备型号封装属性和方法到类中，并且建立继承，这是forward的设计理念，目前也暂时没有产生功能重复开发的情况，如果有一些好的设计理念，欢迎提出共同探讨。

最后再次感谢您拿出时间浏览代码并写下观后感，我们会正视其中的问题并作出改进。

[cflw]

把所有操作塞到一个类中是你们的设计理念么。。。那以后你们怎么处理复杂配置？比如配路由啊配访问控制列表啊，或者配个不联网的新设备啊，也都塞到一个类吗？

我不知道forward上层长什么样，我猜应该是一些可以大批量操作，但是又不够灵活的代码。

我曾经在知乎上发表一篇文章《用python编写控制网络设备的自动化脚本1：框架设计》，还有相应实现https://github.com/cflw/cflw_py ，可以给你们参考一下。

为了解决设备类过于庞大的问题，我设计了很多的模式接口，把具体操作放到不同模式中。比如全局配置模式可以改设备名，接口配置模式可以改ip地址。把不同品牌不同型号同一个模式的通用操作提取出来成为模式接口，具体实现写成模式类，可以有效减少设备类的规模，使用过程也更接近网络设备的实际配置过程。

同时，对于同型号不同版本的设备而言，只需要针对命令不同的模式重新写个模式类，这样子把拆分版本产生的工作量从一个设备类缩小到一个模式类。

同时，还可以根据不同模式的差异来组织代码结构，把模式不同、功能类似的模式放到“品牌_模式.py”文件。比如访问控制列表有很多种类型，根据不同类型写不同的模式类之后，放到同一个文件中。这些功能类似的模式还可以继续提取出重复代码，提高代码重用性。

我的代码风格很奔放的，我的这个坑因为设计过于复杂，变成填不完的大坑，希望你们看了我的代码之后不要笑_(:з」∠)_
我只想写个脚本，而你们想写个工具写个平台，你们的坑比我的坑还大。也希望你们看了我的代码之后不要脑袋发热把你们的项目砍了。

[headkarl]

看了一下你发来的链接，先聊一下设计问题，其实写出forward之后也见过不少模块和实现，也在各种现场和群里聊过网络运维的实现，对于底层模块（也就是通道封装、设备型号差异屏蔽、原子函数封装），基本大家都是大同小异的：

你的三层结构（连接，设备，模式）也分别对应于forward（utils，devClass，userScript），区别在于后两层孰多孰少，forward更倾向于完善底层的通道封装，专注于屏蔽连接协议、减少用户选择和学习成本（目标用户是网络工程师，仅需要入门级别python知识），再加上人手的问题，所以forward重点封装基础层，用户仅需要选择设备型号，之后使用excute和command即可构建出任何自己需要的场景。
结合上一点，所以较为复杂的实现目前不会在forward这里实现（这里复杂的定义会随着时间和业务需求改变，我们也在逐渐拆分下沉），一方面还是人手和测试机型的问题，另一方面是上层用户有足够的能力和意愿自己去做业务封装，只要forward用起来足够简单和轻量，不需要花时间学习理解，那就够了。你也说了，坑很大，所以不同职责的人分工做好自己的工作即可。
上层的业务形态，目前我在用户群体中大概见过三种，各有适应场景，除了前文提到的高级python封装（你代码中一些复杂逻辑，模式切换等，业务逻辑）和网络微服务（资源管理、配置抓取、策略映射管理、网段管理等），还有一个用ansible结合forward的场景实现，也能解决特定场景问题，相信未来还会有更多有趣的应用形式会出现。
至于把所有操作放到一个类里，个人认为面向对象编程就是为了解决这个问题，某个型号设备的属性和方法归属到这个型号类中没有什么问题，通过连接协议-厂家-型号的类继承链也不会产生代码重发开发的问题，也符合网络运维工程师的认知习惯，关键在于，这不是用户关心的地方。

最后再说点，感谢您对forward提出的看法和意见，其中一些确实是我们可以做的更好的地方，这个工具的主创人员基本已经各奔东西，不在一起工作，但是forward仍然在使用和扩展，也适用到了不同的环境中，百家争鸣，开枝散叶。