即刻App年轻人的同好社区
下载
提问：作为一个后端，你是更喜欢用ORM还是手写SQL语句来管理表结构？
【使用ORM】
好处：免写SQL，可以搭配迁移工具实现类似Git的版本管理，随时升降级或回退
坏处：过程黑箱化，复杂的结构可能无法处理
【手写SQL】
好处：掌控一切
坏处：繁琐，版本管理成问题（可能有工具我不知道，麻烦告诉我）
【使用ORM】
好处：免写SQL，可以搭配迁移工具实现类似Git的版本管理，随时升降级或回退
坏处：过程黑箱化，复杂的结构可能无法处理
【手写SQL】
好处：掌控一切
坏处：繁琐，版本管理成问题（可能有工具我不知道，麻烦告诉我）
5 40
我发现对于小公司或初创公司来说开源其实是一把双刃剑，以为把开源的东西拿过来换套皮就摇身一变成自研。这对于老板而言可以拿出去骗钱骗投资，但对开发来说不一定是好事，因为有不少潜藏的坑等着你去踩，也就是俗称的“二开”。
首先是定制化问题。拿到别人的开源项目代码总得要去熟悉，甚至还要去理清当中的依赖、调用链、逻辑等等才敢说自己可以“尝试”去改了，但凡未洞悉全貌直接就上手没改一改这，又改一改那，很快就会碰到“诶，为什么刚才明明能跑，现在又跑不了了，我明明也没改什么东西”的局面。
其次就是上游的开源项目不更新或者闭源的问题、以及频繁更新和自己需求代码冲突的问题。本身就依赖的人家的开源项目来改，那么有一天人家不更新了或者直接不开源商业版本的功能时，团队是否有能力hold住并能自己去复制并实现想要的功能？又或者上游频繁更新，Fork的部分本身就加了满足自身需要的功能代码或业务逻辑代码，此时不仅得花时间去合并，甚至与上游代码产生冲突（或者严重冲突）时该如何去解决，还是就此分道扬镳，以后只在自己Fork的部分继续前行？
还有就是领导觉得我们既然有这么多所谓的“自研”产品了，突然灵光一闪想着能不能想着把这些产品集成到一块串起来用，比如A项目的某个页面模块专门嵌个B项目，C项目和D项目页面又放到B项目页面的某个按钮上作为弹窗。本身不同的项目就自己有着自己的一套技术栈，加上其他鉴权认证逻辑那就更为复杂了，尤其是前端项目那么多的技术栈和框架甚至还得跨框架组件通信，不同页面之间的鉴权问题在没有统一的中心认证情况下就够开发喝一壶，而这就是我正在经历的，我也搞不定，只能是重定向跳转折中处理。
我发现我大部分工作时间都花在了二开项目上，反而是在新的项目上最少。因为新开的项目没有任何技术负担，不用做任何代码逻辑上的适配，只需要针对需求功能拆解、实现、然后测试提交上线就完事了，而二开项目所花的时间至少是新项目或真·自研的一倍甚至更多！
首先是定制化问题。拿到别人的开源项目代码总得要去熟悉，甚至还要去理清当中的依赖、调用链、逻辑等等才敢说自己可以“尝试”去改了，但凡未洞悉全貌直接就上手没改一改这，又改一改那，很快就会碰到“诶，为什么刚才明明能跑，现在又跑不了了，我明明也没改什么东西”的局面。
其次就是上游的开源项目不更新或者闭源的问题、以及频繁更新和自己需求代码冲突的问题。本身就依赖的人家的开源项目来改，那么有一天人家不更新了或者直接不开源商业版本的功能时，团队是否有能力hold住并能自己去复制并实现想要的功能？又或者上游频繁更新，Fork的部分本身就加了满足自身需要的功能代码或业务逻辑代码，此时不仅得花时间去合并，甚至与上游代码产生冲突（或者严重冲突）时该如何去解决，还是就此分道扬镳，以后只在自己Fork的部分继续前行？
还有就是领导觉得我们既然有这么多所谓的“自研”产品了，突然灵光一闪想着能不能想着把这些产品集成到一块串起来用，比如A项目的某个页面模块专门嵌个B项目，C项目和D项目页面又放到B项目页面的某个按钮上作为弹窗。本身不同的项目就自己有着自己的一套技术栈，加上其他鉴权认证逻辑那就更为复杂了，尤其是前端项目那么多的技术栈和框架甚至还得跨框架组件通信，不同页面之间的鉴权问题在没有统一的中心认证情况下就够开发喝一壶，而这就是我正在经历的，我也搞不定，只能是重定向跳转折中处理。
我发现我大部分工作时间都花在了二开项目上，反而是在新的项目上最少。因为新开的项目没有任何技术负担，不用做任何代码逻辑上的适配，只需要针对需求功能拆解、实现、然后测试提交上线就完事了，而二开项目所花的时间至少是新项目或真·自研的一倍甚至更多！
8 20
来深圳一段时间对比在上海待了七年，深圳留给我一个独特的印象是：1500-2500区间的预算都可以让你实现洗澡拉屎自由，因为可以直接租到带独卫的房子。
而这个区间在上海大部分都是合租，想要独卫可能就还得要加个几百块钱。
而这个区间在上海大部分都是合租，想要独卫可能就还得要加个几百块钱。
1 20
我的第一次副业实践成绩就是最终稿费加知识付费分成给我带来了 15w 的额外收入，尽管这比不上大厂一年的总包，也比不上知名 App 或产品的 ARR，但这对于当时工作才 3 年多的我来说完全是一笔巨款，那时我并没有所谓的方法论，完全只是自己尝试着去做然后而得到的一次“认知奖励”。
我相信有不少人时刻都想着自己独立开发产品、SaaS 又或是开拓自己的副业；但在没有能够打造自己的独立产品或实现盈利前，先健健脑拓宽思路也是不错的选择。从去年到现在我阅读了三本能改善我对“副业”认知的书籍，我多希望在我摸着石头过河时能够早点读到，这样我的认知奖励也许还能更多。
三本书的风格都很类似，你可以把它们每一章当做是闲时、通勤甚至是厕所读物，章节之间内容独立没有关联，哪怕读不完也没关系，完全不会让你有任何阅读负担：
《软技能：代码之外的生存指南》
这本书是我强烈推荐给所有刚有想要探索副业或第二收入或「睡后」收入的朋友们首选，尤其是已经正在尝试去实践或开拓自己的除工作主业之外的第二事业的朋友们。
书名就已经开门见山地表明这是一本告诉你除了代码之外你还能通过哪些方式来开拓个人的第二事业，比如推特上常见的搭建个人博客、构建社区并树立个人品牌等等，可以说我做副业时实践得到的总结其实这本书早就已经写明了。
我的个人经验：即便可能一时半会你还没有独立作品又或者没有摸索一条挣外快的渠道，但对于程序员来说给开源项目贡献 PR（哪怕是翻译）、定时输出自己知识见解等都表明你已经在路上。
《重来：更为简单有效的商业思维》
这本书的作者之一便是家喻户晓的 Ruby on Rails 框架创始人以及 37 signals 公司 CTO 的 DHH，当中的内容都是从打造 37 signals 旗下产品而总结得到的经验，这对于想要打造自己独立开发产品或 build in public 的个体而言无疑是非常有借鉴意义，在这本书中你能看到不少围绕产品而延伸的观点和经验，包括产品迭代、目标用户、营销等，这也是很多技术人（包括我自己）所欠缺的经验，因为一旦我们想要脱离公司成为独立个体并创造技术产品或服务，那么绝对不会是技术优先。比起使用什么编程语音、框架、数据库等问题，诸如你的用户是谁？如何让产品具备更好的 UX？从什么渠道让别人知道或使用你的产品？等问题可能才是第一顺位。
我的个人经验：我的付费栏目在前期是由官方平台替我推广，高度地曝光量才会产生高额的流量，所以我当时能做的就是在推广之前将内容打磨好，剩下的交给平台和读者。在流量当道的时代“酒香也怕巷子深”，在对自己产品有信心的前提下，尽可能利用好所有自媒体平台，不论是赞誉还是诘责，都有可能将流量转换成实实在在的收入。
《创造：用非传统方式做有价值的事》
这本书的作者为 iPod 之父以及 Nest Labs（后被 Google 收购）创始人，列出了从个人成长与职业规划再到打造产品、创业甚至成为 CEO 经营公司等完整的心路历程，故事性的叙述风格和直截了当的表达方式让我花了四天时间从头到尾认认真真地把整本书给看完。不论你是目前身处初入职场、精英大拿还是独自单干阶段，这本书的观点都常看常新。
我相信有不少人时刻都想着自己独立开发产品、SaaS 又或是开拓自己的副业；但在没有能够打造自己的独立产品或实现盈利前，先健健脑拓宽思路也是不错的选择。从去年到现在我阅读了三本能改善我对“副业”认知的书籍，我多希望在我摸着石头过河时能够早点读到，这样我的认知奖励也许还能更多。
三本书的风格都很类似，你可以把它们每一章当做是闲时、通勤甚至是厕所读物，章节之间内容独立没有关联，哪怕读不完也没关系，完全不会让你有任何阅读负担：
《软技能：代码之外的生存指南》
这本书是我强烈推荐给所有刚有想要探索副业或第二收入或「睡后」收入的朋友们首选，尤其是已经正在尝试去实践或开拓自己的除工作主业之外的第二事业的朋友们。
书名就已经开门见山地表明这是一本告诉你除了代码之外你还能通过哪些方式来开拓个人的第二事业，比如推特上常见的搭建个人博客、构建社区并树立个人品牌等等，可以说我做副业时实践得到的总结其实这本书早就已经写明了。
我的个人经验：即便可能一时半会你还没有独立作品又或者没有摸索一条挣外快的渠道，但对于程序员来说给开源项目贡献 PR（哪怕是翻译）、定时输出自己知识见解等都表明你已经在路上。
《重来：更为简单有效的商业思维》
这本书的作者之一便是家喻户晓的 Ruby on Rails 框架创始人以及 37 signals 公司 CTO 的 DHH，当中的内容都是从打造 37 signals 旗下产品而总结得到的经验，这对于想要打造自己独立开发产品或 build in public 的个体而言无疑是非常有借鉴意义，在这本书中你能看到不少围绕产品而延伸的观点和经验，包括产品迭代、目标用户、营销等，这也是很多技术人（包括我自己）所欠缺的经验，因为一旦我们想要脱离公司成为独立个体并创造技术产品或服务，那么绝对不会是技术优先。比起使用什么编程语音、框架、数据库等问题，诸如你的用户是谁？如何让产品具备更好的 UX？从什么渠道让别人知道或使用你的产品？等问题可能才是第一顺位。
我的个人经验：我的付费栏目在前期是由官方平台替我推广，高度地曝光量才会产生高额的流量，所以我当时能做的就是在推广之前将内容打磨好，剩下的交给平台和读者。在流量当道的时代“酒香也怕巷子深”，在对自己产品有信心的前提下，尽可能利用好所有自媒体平台，不论是赞誉还是诘责，都有可能将流量转换成实实在在的收入。
《创造：用非传统方式做有价值的事》
这本书的作者为 iPod 之父以及 Nest Labs（后被 Google 收购）创始人，列出了从个人成长与职业规划再到打造产品、创业甚至成为 CEO 经营公司等完整的心路历程，故事性的叙述风格和直截了当的表达方式让我花了四天时间从头到尾认认真真地把整本书给看完。不论你是目前身处初入职场、精英大拿还是独自单干阶段，这本书的观点都常看常新。
10 04
这是我见到内容质量最好的 Django 入门教程，相比于 Django 官方的入门项目来说，该教程更适合跟我一样先了解理论再实操的朋友，概念循序渐进、内容不拖泥带水，篇幅适中不会有读不完的压力。新手学完后再去实操 Django 官方的 Polls 项目会更好。属于是新手入门、老鸟温习必备之良品。
🔗：www.mattlayman.com
🔗：www.mattlayman.com
2 00
在新公司待了快将近四个月，说说几个对于小公司或者小团队开发来说能够提高效率早点下班的事情：
1. 搭建CI/CD流程越早越好。不论是用的GitHub Action 还是自建Gitlab或者Jenkins，早点把流水线加入到开发过程中可以省下不少部署、配置环境等所需要的工作量，这样搭配像k8s这样的集群容器可以做到合并代码后自动部署和上线
2. 引入Code Review和开发规范越早越好。一方面不论协作同事的水平怎么样，最起码大家能够遵循统一规范，如代码规范和分支提交合并规范等，减少屎山和分支错乱的问题；另一方面，Code Review 至少能在代码合并前检查看看是否存在什么问题，免得又重新返工和回退代码，毕竟三个臭皮匠顶个诸葛亮
3. 引入代码质量工具链越早越好。这里的工具链其实就指Formatter、Linter之类的东西，虽然可能项目都还没写起来，就花一大堆时间引入在配置工具链上会被人诟病，但这对于协作来说大有裨益。比如像Python动态语言，如果每个人都不写类型注解，一旦犯错排查起来就会十分头疼，即使加了类型注解就算错了代码一样可以跑起来，所以这时候就要引入pyright或者mypy之类的静态类型检查工具，避免在代码上线时出问题。所以我的做法是把工具链引入到git commit hook上（当然也可以放到CI中，但我更喜欢在每次推送代码前就发现问题然后修改，而不是推送代码后为了修CI而再提交一次）
4. 接入日志和告警通知越早越好。这通常是对于后端接口来说，毕竟大多数时候报错都是在后端接口部分。在微服务和容器化大行其道的时代，提早把日志工具配好，尤其是使用结构化日志记录方便，避免加了负载均衡和起多个节点后日志来源过多无法定位的问题；同时，即便小团队没有专门的资源做监控，也应该至少配一个企业微信或飞书机器人做告警通知，方便第一时间发现是什么问题。不管是日志记录还是通知都应该携带请求上下文，以便快速定位
5. 尽可能选择相对新的技术栈。可能有人对Java8和mysql5.7这些旧东西有别样的情怀，但在小公司里领导基本上不会太在意你的技术栈是什么，只要你能根据业务需要把东西做出来就好。所以尽可能选择相对新的技术栈在享受到新特性的同时能够面向未来，而不是明明没有历史包袱非要自己背一个。所以像我都直接Python3.10或者Python3.11（考虑到社区可能没有完全适配Python3.12）、Node20+、Vue3、PostgreSQL 16等起步
1. 搭建CI/CD流程越早越好。不论是用的GitHub Action 还是自建Gitlab或者Jenkins，早点把流水线加入到开发过程中可以省下不少部署、配置环境等所需要的工作量，这样搭配像k8s这样的集群容器可以做到合并代码后自动部署和上线
2. 引入Code Review和开发规范越早越好。一方面不论协作同事的水平怎么样，最起码大家能够遵循统一规范，如代码规范和分支提交合并规范等，减少屎山和分支错乱的问题；另一方面，Code Review 至少能在代码合并前检查看看是否存在什么问题，免得又重新返工和回退代码，毕竟三个臭皮匠顶个诸葛亮
3. 引入代码质量工具链越早越好。这里的工具链其实就指Formatter、Linter之类的东西，虽然可能项目都还没写起来，就花一大堆时间引入在配置工具链上会被人诟病，但这对于协作来说大有裨益。比如像Python动态语言，如果每个人都不写类型注解，一旦犯错排查起来就会十分头疼，即使加了类型注解就算错了代码一样可以跑起来，所以这时候就要引入pyright或者mypy之类的静态类型检查工具，避免在代码上线时出问题。所以我的做法是把工具链引入到git commit hook上（当然也可以放到CI中，但我更喜欢在每次推送代码前就发现问题然后修改，而不是推送代码后为了修CI而再提交一次）
4. 接入日志和告警通知越早越好。这通常是对于后端接口来说，毕竟大多数时候报错都是在后端接口部分。在微服务和容器化大行其道的时代，提早把日志工具配好，尤其是使用结构化日志记录方便，避免加了负载均衡和起多个节点后日志来源过多无法定位的问题；同时，即便小团队没有专门的资源做监控，也应该至少配一个企业微信或飞书机器人做告警通知，方便第一时间发现是什么问题。不管是日志记录还是通知都应该携带请求上下文，以便快速定位
5. 尽可能选择相对新的技术栈。可能有人对Java8和mysql5.7这些旧东西有别样的情怀，但在小公司里领导基本上不会太在意你的技术栈是什么，只要你能根据业务需要把东西做出来就好。所以尽可能选择相对新的技术栈在享受到新特性的同时能够面向未来，而不是明明没有历史包袱非要自己背一个。所以像我都直接Python3.10或者Python3.11（考虑到社区可能没有完全适配Python3.12）、Node20+、Vue3、PostgreSQL 16等起步
117 1123
如果时间能够倒退，我会告诉自己：
1. 不要陷入语言/框架/工具链孰优孰劣的漩涡，而是尽可能地了解别人是把生意做起来的，即业务逻辑；
2. 不要把时间浪费在试图说服别人上，观点不一致很正常，不必分高下；
3. 不要既要又要，世界变化很快，什么都学只会害了自己，唯一能做的就是在正确的方向上行动
1. 不要陷入语言/框架/工具链孰优孰劣的漩涡，而是尽可能地了解别人是把生意做起来的，即业务逻辑；
2. 不要把时间浪费在试图说服别人上，观点不一致很正常，不必分高下；
3. 不要既要又要，世界变化很快，什么都学只会害了自己，唯一能做的就是在正确的方向上行动
4 10
