不知道楼主说的项目文档具体是哪种呢？
API 文档，能够描述清楚请求响应的参数即可；楼主说的可能是 系统设计、业务逻辑文档。

写这类专业性文档，有几点要注意的：
1. 描述清楚上下文。需要用些篇幅来介绍背景、上下文，专业术语。写的时候要代入读者，设身处地思考 TA 能不能看懂。
2. 逻辑清晰。最好列个大纲，不要想到哪写到哪。多用 1 ，2 ，3 描述步骤或者阐述观点。
3. 图文并茂。文字难以描述的，务必带上图。

有兴趣可以看看我的博客。https://foamzou.com 。
若楼主有博客也可以贴出来，我们一起学习交流。

electron 跨平台，有 web 开发基础的话，上手很快，开发效率也高。
原生 swiftUI ，会流畅那么一些，颜色和 UI 适配方案做得不错。遇到问题的话，解决方案没有 OC 那么多。但 swift 写起来比 OC 舒服。
原生 OC ，毕竟这么多年了，该有的方案都有。但 OC 语法很别扭。

祝大家还有我，我的家人朋友，新的一年身体健康，万事顺意。

第二排第三个。谢谢楼主，祝你和女票长长久久。
[email protected]

我安卓，tasker + webhook

ifconfig 可以看看 i/o 流量，先确认自己侧是不是真实消耗了

很不错。等会下班追剧去

@lindenYou
在技术设计评审环节需要有人把关，如果后端没有人懂这个或者后端 leader 也不想管，要么他换人，要么你跑路。

楼主你好，我有几个问题。这个 JD 招的是全栈吗？其中后端语言栈是否只有 node.js ？
工作中对英文的听说能力是什么要求呢

很多边界问题 没有唯一的准则。大多根据
1. 谁受益谁来做
2. 两边都能做的情况下，衡量 ROI ，很多情况下需要有话语权的人判断和拍板
3. 如果你水平足够，代入到领导的视角，如果你是领导，你会让谁来做？此时你会脱离自身利益，看问题看得清楚些

回到你的具体问题
1. 数据结构：前后端应当维护一个资源结构并达成共识。后端返回共识的结构即可。后面 UI 有变动导致的 数据渲染（表示）层变动，前端来处理就好。即，不考虑 UI 具体结构，只从资源关系上定义好数据结构。

2. 用户输入验证：
- 前端：应当最大限度把不合法的请求拦截掉，避免对服务端发出无用请求，从用户体验来看，也会更好。但一些重逻辑的判断，可以透传给后端判断，避免前后端不好维护这类重逻辑。
- 后端：必须要判断。永远不要相信用户的输入时第一原则。微服务中的内部服务间的“前后端” 则看具体设计和取舍了

3. 并发和防刷
- 前端：要做。考虑的是用户体验 和 对后端压力的缓冲。
- 后端：看具体需求决定，有些无关痛痒的需求就没必要加锁了，前端做了就行。涉及金钱或者会影响需求的正常实现的，那就必须要做了，否则就是 bug 了。

看到大家都喷楼主的理解和表达能力，我就放心了。看到 6L 我都惊呆了，指鹿为马的能力太强了

第一个，谢谢楼主
[email protected]

恭喜。
扩展坞：绿联啦。不管是什么拓展坞其实都不太推荐接电源，mac 品控不太好，怕出问题。
希望充电+显示器，那么买那种 typeC 带充电的显示器就不错，看你预算了

256GB 差不多够了，移动硬盘建议装占用空间的文件即可，软件不建议装里边，不论数据传输还是便捷性都不好。

其他建议可以参考我这篇 blog https://foamzou.com/2020/05/24/mac-started-guide/

@smilenceX #19 抱歉，在 macOS 主题下，预设大家都知道这类相关缩写。
指的是 Magic Mouse

只有我推荐 mm 吗

我的才 149 。算了

@xiqishow #5
事实上，应当由程序来做这个事情，而不是让用户承担这个风险。

例如可以这样： https://askubuntu.com/questions/408611/how-to-remove-or-delete-single-cron-job-using-linux-command