虽然细节未能详尽，但我们大致介绍了插件的开发，发布，文档编写。这里提出一些开发过程中的注意事项。
如果是自己用则可以无需过多花费精力，但希望其他用户可以使用自己的插件，那么用户友好性是非常重要的，这包括：
-
合理的功能组织
将功能合理的划分，并用合适的标题展示。
-
合理的交互方式
如插件的参数暴露能具有一定通用性但又不至于杂乱，工具的使用方式符合使用习惯。
-
言简意赅的文档
如果有精力，最好为插件编写操作手册，有必要可以图文并茂。
-
尽可能优化的性能体验
当然这一点是永无止境的，并且主要取决于算法，固然越快越好，等待总是糟糕的。
ImagePy将开发者友好性放在与用户友好性等同的地位，因为开发者与用户本是一个教学相长的群体，并且两者之间界线模糊，可以互相转化，这里介绍几个ImagePy的开发理念。
-
ImagePy不是算法库，只是连接器
ImagePy不做算法，只提供必要的展示与交互，致力于让算法开发者用最少的代码将算法进行配置，整合到ImagePy，将算法转化为工具，给其他人甚至是非程序员使用。
-
尽可能隔离UI
UI对于科研程序员总是不愉快的，ImagePy尽最大努力隔绝UI，多数的配置功能都可以通过
para，view的配置来完成参数对话框的生成，而tool也抽象为mouse_down,mouse_up,mouse_move,mouse_wheel四个接口实现。而一些定制化很强的功能，不得不借助widget，只有这时才需要开发者自己编写UI相关的代码。 -
以算法本身为核心
ImagePy的图像数据基于
Numpy，表格数据基于Pandas，矢量数据基于Shapely，这些都是通用数据结构，相当于Python科学计算的标准，ImagePy作为算法连通器，固然只能支持，而不能干涉算法的编写。因而开发者切不可将核心算法在run函数中实现，这样其他开发者将无法使用，开源的意义就大打折扣。算法，UI，事件混合，这导致ImageJ1的算法代码无法被其他开发者调用，不得不大量使用IJ.run(...)，或许ImageJ2正在极力改变这种情况，而这在ImagePy中是不被允许的用法。我们推荐的方法是1）如果你的插件只是实现很简单的数据操作，只有几行代码，那么OK，可以在run中实现。
2）如果你的算法相对复杂，那么最好将它写在一个单独的文件，并且这个模块中不要引用任何与ImagePy相关的模块，只基于
Numpy，Pandas等标准科学计算库，这样以便他人可以拷贝出去，并且import使用。3）如果你的算法意义重大，通用性很强，那么务必创建一个独立的算法项目，上传
pypi，在插件项目中以引用的方式来使用。 -
关于宏和headless
相比ImageJ，ImagePy的宏实现的功能非常有限，只支持已有功能流程化调用，无法用宏实现逻辑，这其实与ImagePy的设计理念紧密相关，只要开发者都能做到以算法本身为核心，让ImagePy充当纯粹的连接器，那么任何的算法调用，可以用Python简单的调用。Python已经如此简单强大，为什么还要另外学习一种晦涩而不通用的宏呢？同样，ImagePy也不会支持
headless，因为一切功能以算法本身为核心，而ImagePy只提供交互，那么在headless情况下，ImagePy还有什么意义？又有什么非要借助ImagePy的呢？如果一切功能都可以以库的形式提供，那么开发者为什么希望编写headless代码，而不是纯粹的python代码？
相比ImageJ，ImagePy还只是一个孩子，框架和功能都还不够完善，但优势是，我们可以自由把控，即时调整，而不需要考虑背在身上的强大且庞大的插件体系。作为插件开发者，如果在插件开发过程中遇到任何困难，请随时与我们联系，尤其是当你觉得一个插件开发的很复杂时，那么很可能是因为我们的框架缺乏某方面的支持，我们可以随时讨论，在插件开发的同时，共同完善主框架。让ImagePy更好的实现连接器的价值，为用户和开发者服务。
ImagePy是 www.forum.image.sc 的合作伙伴，任何研发，使用方面的问题可以在里面进行讨论。