@zhshh
2021-03-12T01:16:15.000000Z
字数 1817
阅读 568
@zhshh
整理了一下我之前说的一些有点“理念”的东西...这个词可能用“哲学”更好（？）就是长期写代码形成的一些经验和思考方式。先书面落实一下， 要不我有的时候都说不出来为什么我这么想..但是就是这么想的...
在国内搞面向国内的用户的开发，首先考虑审核这个门槛
1.1. 考虑是否可以过审
比如域名需要备案，个人站不存在用户产出内容等等，一般如果打算发布都会先考虑这点。
1.2. 能不增加的非必要创作功能不增加
文字还好，但是也尽量少一些。尤其是图片和视频尽量不要加。而且图片视频如果走服务器，带宽流量成本高，如果走CDN/COS/OSS，开发成本高（需要另外配置对象存储、CDN等等）而且图像视频审核也得人工或者付费接口。
当程序化的成本和收益不是正相关的。前期基础设施成本高收益低，但是在有了基础设施之后，实现初步和进一步的程序化较为顺利，但是此时始终要有人工参与。而从高度程序化（需要人辅助）到最终的全自动化（程序化）的成本要高得多
这个我之前单独解释了。再举个例子，不考虑用户的自觉性的话，比如一个书店，从纯人工登记+归还到电子登记、扫码租还这步所需要的成本，要比去掉最后一个图书管理员，变成一个完善的全自动化书店简单得多
进一步的，如果开发程度达不到，就是要在自动化/人工达到一个平衡，而不是一味的追求程序化。
一个项目的开发进度不是线性的，先缓后快再缓（前期基础设施，后期修BUG、做适配）
一切东西搞一个自增 id（我在数据库设计结构的一个理念，虽然未必正确）
如果生产力不足，增加新功能的时候优先考虑从现有功能能否延伸出来。（有一点迭代开发的思想）
这个我也经常提到了。尤其是生产力不足，尽量尝试一点点增加拓宽领域，而不是贸然进入一个无关方向。
不要相信用户
6.1. 不要相信用户的水平很高
做的时候要想到如果是没有接触过类似软件/面向对象为家长、老人的时候怎么办，界面是否友好（除非你确定目标就是年轻群体或者特定群体）
6.2. 不要相信用户的水平很低
关键操作进行鉴权，且全部放到后端。secret/token 等不应该下发的内容不下发。（忘了在哪见到的一句话，你应该认为你的客户都是一群黑客）
6.3. 不要相信用户很聪明
处理各种奇怪的问题和输入情况、边界情况（也可能是一个很聪明的黑客在尝试各种溢出）
大一时候的C语言大作业，XX管理系统，在
输入你要进行的功能（0~9）这种界面上输入一个字母，我用这种方法搞崩了几乎 100% 的程序
———— 我认识的一个同学
只相信合法来源
这个指的是数据和信息。暂时没想到合适的例子（emm其实和6、9有点类似）
前端也能运算
非重要的内容（尤其是运算量大的展示性内容），可以有后端发送计算原始数据前端计算，或者是数据进行缓存
前端透明公开（和6、8有点类似）
在一个 web 项目内，理论上用户是可以拿到前端的全部代码的，也能完全的自定义和服务器交互内容。
因此在对于用户的信任上要有所保留，另外就是重要的 secret/token 不要下发。比如一些字段可以进行服务器签名校验、或者采用客户端存储 hash 服务器存储 map 的形式。将数据存在服务器上而非下放。（分别参考 python Flask 的 session 和 PHP 的 session 的实现。）
重写未必会比改 BUG 麻烦，而且改 BUG 不保证不会引入新 BUG
尤其是在边学新技术边写 demo 的过程中，很可能你想方设法得到的某个功能，过两天发现有接口。或者是一些因为反复修改已经乱到难以维护的情况的代码。直接用最新学的东西重新写一下这样要比在同一份上面改好很多。
即使是普通的项目，因为写到一半发现不好进行，需要更换思路或者较大的变动，可能重写也要比强行转变好得多（具体根据情况进行衡量）
有一种平衡树的数据结构叫做
替罪羊树，其理念就是，如果维持不了平衡就拍扁重构。
合作项目除了合作之外，还需要 1. 接口文档 2. 明确分工 3. 版本控制（有了2以后，3才会顺利进行）
可以搞压力测试，但是也需要考虑一下是否有必要真的做到那种性能
大一的时候的一个弹幕系统的经验，当时已经做到了 100+条/秒 不丢包，200+条/秒 丢失小于5%（具体记不太准了.反正压测从几十一直优化到二百多条且表现满意才结束）然后实际应用发现，最快的时候也就一秒七八条，平均 1秒两条
然后后来做项目，都会先拿普通技术实现（能满足一个基本的用户量需求即可，且代码成本小于较优化的代码，除非开发过程就觉得真的太慢），然后等上线后根据实际情况再进行优化。