假的做不做都可以： 找出根本区别再进行选择
真的完全做不做都一样：绝对不做！

依次辩驳一下前面发言：
1. 下一任维护者眼里就是坨便便
说明你从没看过好代码，所以任何你看不懂的代码你都觉得是坨便便，这只是你个人的问题，并不是普遍情况，好的代码很多，就像艺术品，可惜你没见过或者见到了也认不出。
好的代码并不是说设计模式用的多，代码行数少，而是它精准的满足了需求，不多不少，也不会因为炫技或者盲目满足某些设计规范而增加代码复杂度。

2. 给多少钱干多少事
这很好解答，你应该找愿意为你能力买单的工作，而不是有多少钱干多少事，别告诉我你的能力已经没人能出的起对应价格了，也许你应该重新自我评估。

3. 很多来源于需求不明确
需求从来都是不断变化的呀，变化也是需求的一部分。这是我们本来就应该努力做好的工作。

4. 这东西是我继续负责的话代码质量写好一点
这和外地人在街上吐痰拉屎有什么区别？不是我家我就糟蹋，我就没素质，因为环境好了我也无法享受到成果？这是一种严重的误解。
人生从来就是过程而不是结果，就像你吐了一口痰，走几步你就会踩到一坨屎，因为前面一个人也是和你一样想的。
另一点误解就是，你其实很难选择写出“好代码”，你只能在写出“符合我水平代码”和“糟糕的代码”之间选择。

5. 老板懂的话代码质量就写高一点
老兄，你该换工作了，如果老板甚至都不知道你的工作成果的质量水平，凭什么认为他会给出合适的待遇呢？
如果他给多了而不是给少了，那么说明他连基础的市场买卖都没搞懂，项目也不会在市场上脱颖而出，简而言之就是没有未来。
另一方面讲，如果给多了，为什么你没有点感恩的心态，努力将事情做好，匡扶汉室于危难？而是一边拿着有愧的待遇，一边还做着不负责任的事情？

6. 个人追求可以自己搞点开源项目
工作对于大部分人来说就是人生中最重要的事情，如果可以，最好将全部的精力和时间投入其中。
除非你已经摸到了职业生涯的天花板，哦~ 抱歉，我不小心摸到了你的痛处。

7. 评估时间内完成任务放第一位
这是正确的，但用一个正确的观点来论证另一个问题是不合逻辑的。
在保证完成任务的前提下，剩余的空间才是讨论项目完成质量的空间。

---

最后，我很痛心，看到这么多负面的关于项目质量的发言，使我对这个行业的未来感到担忧，也对你们可能被 AI 或者其他什么东西取代而失去赖以糊口的工作产生担忧。
我希望行业中能出现更多的独立思考和发言，更多的对于技术的热爱和对于工作的责任感。
少一些负面情绪，多一些积极的态度，这样我们的行业才会有更好的未来。
赶日超美，加油！希望我们行业的后辈不再说出那句“国外的软件更发达”，就像我们现在已经不再说“国外的汽车更好”一样。

@BadFox 赞同零信任的方案，使用零信任架构后，就没有内网的概念了，所有设备在一个虚拟网络中，并且所有的流量都是加密的。
我用的零信任架构有本地发现和点对点连接，内网外网访问，和直接用局域网 IP 访问没有什么能感觉到的速度差异。

@810244966 系统备份导致的，每次备份会清除无障碍授权

截图：Win 键+Shift+S
P2P 文件同步：SyncTrayzor
虚拟机：VirtualBox
命令行：Git Bash

名字是微信，交个朋友

黑产：各位说得对，SSL 真是毒瘤
希望我们和各位一起齐心协力推动互联网安全倒退，回到那个幸福的年代。
和菜鸡程序员比拼 JS 混淆加密
轻松一点直接返回假页面绕过 js 加密钓鱼用户账号密码
真是怀念啊，想不到各位和我们想到一块去了，SSL 真是毒瘤，各位加油，抹黑它，抵制它！

最危险的就是你了，如果你和公司闹掰了，你就会用这个漏洞去报复公司

@element90 因为第一点，服务器必须持有固定的密码 MD5 ，而实际上，服务器一般储存密码哈希，这个密码哈希是随机加盐的，同一个密码每次计算出来都是不一样的，这样可以完全防止服务端密码泄露后可能产生的撞库攻击。
如果为了在传输环境增加一点点毫无用处的密码泄露风险，而导致在数据库要储存几乎等同明文密码，我觉得得不偿失

sign = HASH(username + timestamp + MD5(password) )。

POST Login：{ username, timestamp , sign }

服务端怎么验证 sign ？需要服务器持有 MD5(password) 是吧？

风险点 1：服务器持有固定的 md5

风险点 2：登陆后得到的 token 或 sessionId ，仍然可以被利用。

风险点 3：后续请求没有整体签名和加密，仍然可以被监听和篡改。

最重要的，这个方法没有办法阻止中间人返回钓鱼页面或者注入恶意 JS 代码，中间人可以篡改登陆页面响应，注入一段键盘监听的 JS 脚本，或者干脆返回整个假的页面诱使用户输入密码。

评论区看下来，go 、java 、php 、python 互相替代打得不可开交

50W*24 小时也才 0.8 度电，一天就 6 毛钱左右，计较什么啊

我觉得你需要 github copliot ，这样就不用敲很多代码了，也不用敲很多符号了

你好，chatGPT 为您解答

要搭建一个 AI 识别的后台，您需要以下技术栈：

计算机视觉技术：包括图像处理、特征提取、目标检测、图像分类等方面的技术。

机器学习和深度学习技术：包括数据预处理、模型选择和训练、模型评估和调优等方面的技术。

后端开发技术：包括数据库设计、API 接口开发、数据管理和存储等方面的技术。

前端开发技术：包括用户界面设计、交互设计、页面开发等方面的技术。

对于您提到的监控识别车辆的平台，可以考虑使用开源的计算机视觉框架，如 OpenCV 、TensorFlow 、PyTorch 等，来进行图像处理和机器学习的开发。同时，您需要使用 Web 开发框架，如 Flask 、Django 等来实现后端 API 的接口开发，以及数据库的设计和管理。对于前端页面的开发，您可以选择 React 、Vue 等框架进行开发。

以下是一些可以参考的书籍和开源项目：

《 Python 计算机视觉编程》（ Programming Computer Vision with Python ）：介绍如何使用 Python 和 OpenCV 进行计算机视觉开发。

《 Python 深度学习》（ Deep Learning with Python ）：介绍如何使用 Python 和 Keras 等框架进行深度学习的开发。

开源项目：YOLOv5 、Faster R-CNN 等目标检测算法。

开源项目：Django 、Flask 等 Web 框架。

开源项目：React 、Vue 等前端框架。

希望这些信息能够帮助到您。

它们和《流畅的 Python 》在什么方面相似？

这些书和《流畅的 Python 》在很多方面都相似，比如它们都是深入剖析一门编程语言的权威指南，都对语言的底层原理进行了详细的讲解，同时又包含了实用的代码示例和最佳实践。

它们也都涵盖了语言的方方面面，从语法基础到高级特性、从应用开发到性能优化等，都有所介绍。它们都是适合初学者和有一定经验的开发者阅读的，可以帮助读者提升对语言的理解和掌握。

另外，这些书都是被业内公认的经典之作，受到了广泛的好评和推荐，成为了对应领域的标杆教材。

如果你已经熟悉 JavaScript 基础知识，那么我会推荐你阅读《 JavaScript 高级程序设计》（第 3 版）(英文原名: Professional JavaScript for Web Developers, 3rd Edition)，这本书由 Nicholas C. Zakas 所著，已成为 JavaScript 领域的经典之作。

《 JavaScript 高级程序设计》详尽地讲述了 JavaScript 的方方面面，从语言基础、DOM 操作、事件处理、Ajax 技术等常用技术，到面向对象、函数式编程、模块化开发、性能优化等进阶技术，无所不包。它不仅涵盖了语言本身的知识，还介绍了开发 Web 应用所需的关键技术，是一本循序渐进、结构清晰、内容丰富的权威指南。

如果你对 JavaScript 框架和库更感兴趣，那么可以考虑阅读《 JavaScript 权威指南》（英文原名: JavaScript: The Definitive Guide ）。这本书由 David Flanagan 所著，也是 JavaScript 领域的经典之作，它介绍了各种 JavaScript 库和框架的详细使用方法，例如 jQuery 、Angular 、React 、Vue 等，适合需要深入学习这些框架和库的读者。

ChatGPT 为您解答

Q1: 国内加班文化是如何形成
1. 程序员工资高，那就需要从别的方面找补回来，而程序员们也默认了这一点，别看某些人嘴硬得跟鸭子一样，但是你让他别写代码了去送外卖你看他去不去
2. 压榨从来不是因为工作量大，就像商品的售价不是因成本而决定，是否加班只看博弈，而不是工作量多不多
3. 社会就像海水不断冲刷的沙滩，每一粒沙子都会被放到应该放的地方，行业不会存在人员过多或者过少的现象，人少钱多的行业，自然会涌入大量新的从业者，人多钱少亦然

Q2: 最终的受益者是谁
没有产生收益何谈受益者？加班并不会增加收益，就像电影院所有人都站着并不会获得更好的观影体验，所以这叫内卷。

声明
我是一个一线城市的普通程序员

我们假设有 A 和 B 两个用户，他们对一个现有空白 a.txt 的编辑操作，按照时间顺序是：
A：写入 1
B：写入 2
A：写入 3
B：写入 4
一共 4 次操作，我们假设服务端会在任意时间接收到这 4 次更新（因为客户端离线编辑，联网后上传，所以顺序是不固定的）
我们假设服务器先收到第 4 个操作，那么服务端直接将 4 写入 a.txt
接着，第 3 个操作来了，我们用 3 覆盖掉了 4 就是丢了最新数据，造成了事故

所以，每次要不要更新，就是要带上更新前的 hash ，让各方达成共识，如果第三个的操作描述是：将 2 改成 3 。那么服务端在收到这条信息的时候就会检查现在是不是 2 ，不是 3 的话，“将 2 改成 3” 这个操作就会被拒绝

客户端视角-》云端视角：
1：新增文件 -》 无：创建；有，相同：忽略；有，不同：覆盖
2：更新文件（上版本 hash+更新内容）-》如果上版本 hash 等于云端现有内容，那么是正常的从 1 到 2 的更新，通过。如果上版本 hash 不等于云端现有内容，说明客户端在此次更新前，对于该文件与云端持有不同版本，那么就要形成冲突差异文件并提示用户选择。