从Picviewer CE+ - 全方位折腾在线图片继续讨论：
用户觉得蛮小的点，可能在开发的时候投入的成本却是很可观的。
各位开发者出来讲讲类似的情况吧，也给用户们增加一个了解的渠道。
我先来。最近在写移动端的阅读模式嘛，正在弄菜单部分，每添加一个元素就要同步考虑到元素的移除；每增加一个触发事件，就要在合适的地方加上事件移除的操作。这东西要是画成流程图啥的能墨迹的像渔网。
为什么这样做呢？其实主要是强迫症。好处是更好的释放内存等资源，但现在大内存，也都不是很在乎。然后也没人一个页面看很久，反复切换阅读模式（这种情况发生的概率挺低的），所以就算有内存泄漏也无所谓。
复杂度提升了几个等级，而用户无感。
如果看不懂上面讲的，那么打个比方：
每在书桌上放一份文件，就在待办事项里添加上收起这份文件的待办，各种文具的取用也一样。为的就是能够保持书桌的整洁，不至于因为堆放东西太多而崩溃（东西放不下散落一地）。但显然这种情况发生的概率比较小。而且每完成一项工作，整个办公室都会被清空重置……
6 个赞
功能性代码半小时，UI半个月 
2 个赞
想放弃（bushi
我也来举一个（甚至都不到开发）的例子吧
客户有一台linux的工作站 他们在桌面环境下把文件整理的井井有条 唯一的问题是他们会用中文的文件名 并且里面还会有空格和符号……
3 个赞
所以，无代码和低代码最终也取代不了程序员
你这个看起来更像是 Dispose 操作的设计性问题……良好的代码结构应该是可以避免这些的
对我个人来说，开发时最痛苦的点，一个是设计 UI，另一个是编写实际意义不大的业务逻辑……感觉自己的一部分生命都浪费在写又臭又长的业务逻辑上了（
举手同意，大多业务逻辑编写都是体力劳动，既磨练不了技术，完成后也没有成就感。
一个软件如果公开发布, 那就不仅仅为自己服务.
既然要服务大众, 持续的(精力,时间,金钱)投入肯定是必不可少的.
当然, 你可以根据价值取向, 选择开源/免费/共享/收费等等.
我个人觉得, 每一次选择都会有对应的权利和义务.
比如说你要收费, 就必然会有人会破解, 那么就必然为此付出加密,防破解的精力. 从而获得更多的正版化收益.
但是不论哪一种, 通常都是正向激励.
关键在于你的价值观和你的选择是否契合.
比如我作为一个懒人, 通常极少选择收费, 就在于, 我不想把精力和对资源的消耗放在hack对抗上.
但是你要说开源, 显然也不符合我的价值取向. 毕竟有些公司下线太低.
写一通实现功能，然后回过头来再优化一通（是笨蛋无疑了
从一个简单功能的软件加功能，加成屎山，重构一通，变成一个有一堆bug的看上去漂亮的新屎山。中间又加了新功能，还进退不得
你……把监控给我拆了！
如果是脚本语言优化的空间还挺少的，大多数脚本语言指针释放都做不到，全靠解释器管理孤岛。所以说屎山有点过分，因为要写成金山基本不可能，脚本语言代码优劣标准还是得看算法实现。但站在巨人肩膀上也有好处，这样就不用自己去维护执行环境了。
js 给元素绑定事件，然后删除元素，事件依然存在，而因为存在对元素的引用，所以元素也存在。这样似乎并不能被内存回收机制回收（？），然后我强迫症就犯了
我觉得吧，如果只是纯业务端的软件，尤其是流程和效率类的，不要太追求结构也优美，守着能跑就行，中短期不崩溃为底线就好。没有哪个软件寿命能超过三五年还不重构的，既然如此，基本上写的代码都是要进垃圾桶的。既然如此，不需要太耗费精力。用来自我提升当然可以，但还是满足用户需求和提升响应时间为第一要义。
我有十个表，大多数维度都是一样的，按说应该根据范式结构化，但那样做会造成结构复杂，对应的查询界面也都是一样的代码，按说应该代码也进行抽象。但我都没这么干，因为用户针对不同的表的查询要求都不一样，干脆直接每个表一套数据对应一套代码，反正不需要推广，也没打算做扩展，需要调整需求的时候，复制代码就好了。
以上都是针对项目的，产品的另说。
这不是没啥压力就边写边学，自我磨练，自我提升嘛。而且从 c 语言入门，对于数据类型和内存管理就会相对敏感
写代码，整理代码；写注释，整理注释；写文档，整理文档……
看一眼大佬们，嗷，那代码简练干净的，羡慕
写了一上午，代码没动，光写注释了……
不写注释会连自己都看不懂的啊，所以注释比代码还多（