349820
一些实用的函数, 从前自己明明写过了的. 没有及时整理和索引.. 现在写到了觉得细节都是记不清晰的, 而且查一遍也挺麻烦的. JS 还有蛋疼的前段后端不通用的麻烦. 觉得有些沮丧了. 凡事做一遍都不成的.. 不知道有没有好的方案可以指点下的, 我比较希望所有问题只解决一次.
一些实用的函数, 从前自己明明写过了的. 没有及时整理和索引.. 现在写到了觉得细节都是记不清晰的, 而且查一遍也挺麻烦的. JS 还有蛋疼的前段后端不通用的麻烦. 觉得有些沮丧了. 凡事做一遍都不成的.. 不知道有没有好的方案可以指点下的, 我比较希望所有问题只解决一次.
模块化,组件化,弱依赖,开源,所有代码都交积在一起是不科学的。
我其实挺想把代码都按 CommonJS 1.0 的规范写起来放在 Github 上做一个类库, 但是浏览器端环境太复杂, 这个想法没能实现.. 只能操心
从交互上来说,这就是你的一个痛点。 所谓痛点,就是让人感觉头疼难以解决或者现有阶段需要花费大量资源解决的问题。 一般人都会有惰性心理,因此对于痛点都会采用鸵鸟算法加以规避或者寻求他人帮助。 这个问题给了你一个痛点,因此痛点往往成为解决需求的关键,针对你这个痛点,你甚至可以基于此扩展为一种新型的应用。 例如对于函数主体可以用textarea来包裹: 在没有加任何的注释的时候,这是一个最纯粹的函数,但时间过了很久,我们并不知道当初这个函数是用来做什么的,因此我们可以给这个纯粹的函数体加上一些标签、主体等字段加以标识。 标识可以多种多样,根据你今后的需求,就功能简单来说,可以有: 1.方法名称,虽然方法名称可以根据函数名获得,但是如果有个中文的方法名称加以简单抽象的说明也是比较可观的。 2.方法说明,当然是对方法的详细说明 3.参数、返回值,这个不用说,很简单 4.依赖,有时候这个函数可能依赖其他库或者模块的内容,加以标识以免出问题 但就以上标识来说,用来进行函数寻址倒是可以了,如果内容扩展的过多,修改过多也会遇到一个麻烦,就是修改了2个月后来发现还是1个月前的东西比较好,ok,其中就可能要涉及代码版本。有时候我觉得写在代码里面的注释写多了会变得很长,我们就可以使用代码分行以及外区域注释…… 也就是随着需求越多,要富化的内容也会越多,都是依据需求(痛点)来扩展的。 以上也就是随便和你聊聊,我也是遇到过这样的问题,因为惰性心理所以没有去具体实现而已。 我个人的开发是维护我2个自己写的模块就ok了,其他的函数库基本都是网上去搜,对于简单的函数库会去看下源码,如果觉得写的有问题或者自己的思路更好会重写,但不会备份。 不知道你有什么想法一起交流下