每个人的身体基础都是不一样的。作息一样的话，有的人 40 开始某个地方出毛病，有的人要 50 岁才出毛病。作息不一样的话，那个本来 50 岁才出毛病的，作一作，35 岁就出毛病了。

就大部分人来说，经常不过度运动和一点不运动的人，就体态、精神来看，还是挺好分辨的。通过运动+饮食控制一下体脂，血糖、血压、心肺功能，潜移默化的就走路轻盈，肌肉不容易扭伤，骨头不容易摔伤，吃东西不用担心，体态好看起来更自信，总结起来就是精力更旺。你要说这些东西有什么用？还真不好说，可能下一秒就被玛莎拉蒂撞了。可是这样活着的时候更舒服不是？人是很适应环境的，你说高血压，每天要带着药瓶，吃东西要担心这个少吃那个少吃，正常人想想这不是很麻烦吗，下半辈子都要这么生活，人生完蛋了。但是你要是真这样了，过个 3 个月习惯了，这高血压也不就是这样嘛？是不是？

所以，科学运动肯定是有好处的，但不运动确实也不一定要死要活的。你在不在意这运动带来的好处，每个人都不一样。

经常健身的人有优越感，也正常。长得漂亮也会有优越感，有钱也会有优越感，只要比别人优秀都可能会有优越感，很正常。如果你觉得身体好不算优秀，没什么好优越的，那你何必在意别人有优越感呢对吧~

运动也跟写代码一样要不断学习的，不是上来就劈里啪啦一顿跑，一顿跳，弄受伤了反而怪运动不好，也没有必要，只能怪自己对事物缺乏尊重，缺乏敬畏。

看大家提到小公司，说下我的经历吧，说不定可以给你参考。我也刚满 30，现在小公司打工 3 年多了，做企业端的，公司从倒卖设备到现在也有自己的全套软件和平台了，销售额也是一年比一年高，发展还可以。但是工资还是按照标准发的，老板也聊过说以后愿意按饼分多一点，现在发展期希望更多钱投在发展上。至于未来怎样，我也不知道，人性和经济环境这种东西谁也不知道，分析起来头头是道，结果一个疫情、一个政策就能给你咔嚓来一下。

同时为了拓展收入，也为了试试其他可能性，我联系了一些玩的好的同学，大概 5 、6 个，组了一个名义上的团队利用业余时间接外包，因为大家都是不加班的，也想赚点零花钱。从一开始接几千块的小单子赚信任，现在稳定了客户也有比较大的项目，好的时候月收入比工资还高，就是不是一直有单子，同时稍微大一点的项目就需要好的项目经理投入极大的精力，一个不小心就积木倒塌，不说尾款没了，搞不好预付款还要还回去，虽然没有发生过这种情况，但我在这过程中一直战战兢兢的。

这时候我觉得这玩意根本不能全职做，一个人接不了大单，招人接大单一个不好很容易就资金流歇菜了，也有可能在某个单子中被客户相中飞黄腾达，但这个几率跟赌博差不多，我不愿去赌。毕竟我业余搞，还有本职收入，难伺候就慢慢伺候，拖得时间久一点而已，钱早到晚到问题不大。现在也不知道怎么办，只能走一步看一步。

停车系统门禁安防行业，公司只有我一个技术，兼任 CTO(狗头)、程序员、技术支持，双休不加班，工资一年到手 15w，近两年私活收入每年 3-10w 不等，看心情。干私活跟 996 没差别，只是干不干有个选择。
知乎上那个《在只有一个程序员的公司做开发是什么样的体验？》最高赞就是我。。。

作为一个最近组团接了好几个项目的人，我也有些经验了，大概半年陆陆续续弄了 10w，虽然不是我一个赚，可以给你参考一下。报价这个是看情况的。要看项目的来源。

如果项目来源是散客，不是某个软件公司，可能做完这一单就结束了，客户也没有其他的项目了。那么按照大概工期月份*月薪粗略报就行了，能接受就接受，不能接受也不要妥协，干脆不做。

如果项目来源是某个软件外包公司，朋友介绍转包的。那么就可以想法盯一盯了。对于这种项目，如果你做好这一单，那下次人家可能还是会找你，是个稳定的外快来源，毕竟人家是外包公司，有源源不断的项目。那么这类项目，其实人家转包的时候已经有项目预算了，如果你跟前同事熟的话，你让他你问问看，交个底。如果你跟前同事不熟，那就一起吃个饭增进增进感情，顺便让他去问问，交个底。一般做软件外包的找人做预算都是比较合适的，人家是懂市场价格的。得知人家的预算之后呢，如果你能差不多能接受，那就报一个稍微低一点的价，比如对方预算 4w，你往 3w5 以上 4w 一下报，留一点空间送送人情，几千块对于几万也没啥用，这一单做好了，不管人情送到谁头上，送出去的人情总有下一单的回报的，如果没有呢，就当瞎了眼了。

其实接外包第二类客户是非常好的，在做项目过程中也可以跟项目负责人打好关系，留个好印象，下回就可能直接找你了，也不跟你客气了。我有个客户前两次报价我给留了一点余地，等第三个项目直接就告诉我预算多少多少，做的话直接给我这么多，也不问我报价了，人家的预算是符合市场价格的，基本我都能接受，但是第一单会亏一点。同时呢，由于人家是外包公司，需求什么的不用你去烦，人家都列的清清楚楚，有文档，有原型，会议沟通能清楚说出细节，更细的负责人甚至开发计划都安排得清清楚楚。有了稳定的客户，以后散客你可以直接拒绝了。

我笑了，别人给了建议又不听，一个劲得在那杠，就是来找认同的。你都有自己的想法了，还问什么问。还报警没有用，报警是为了劝你父母的大哥，不是报警非要抓坏人的。你看这想法这么幼稚，换谁的父母估计都不肯信你的话，但是警察一来说不准就信了，怎么一点不会换位思考呢。

google 搜索 .net ini
或者 github 搜索 awesome-dotnet, 项目页进去按 ctrl-f 搜 ini

我是 1，3 结合着来的，
关于 1，我不是手动对两个 object 赋值，而是用了相应 mapper 库，c#的话用 AuthMapper 。
但是 1 不能解决返回指定字段，一开始我是让前端参数指定需要的字段，动态得只返回相应字段。后来觉得没有必要，而是根据业务情况，拆分成不同接口，这样语义化比较清晰。基础 get 接口返回一般性的基础字段，最多十几个把。其他字段可能只是具体的某一项业务用到，根据业务语义拆分接口，使用不同的 dto 。
另外补充一句，对于一个对象或者分页类几十条数据，10 个字段和 50 个字段在 http 上的性能损耗几乎可以忽略。对于一次返回几百几千条数据的可以单独优化，没必要在框架上做抽象。

好巧，我也想问来着

菜不是罪，菜了不努力去改进，还把它归结为工资低不高兴努力，这叫自己放弃自己。

菜了，也努力了，但是还是做不好，只能说是你不适合做这个。

根据我的观察，有的人呢，不管给多少时间，写的代码就像楼主例子那样的一坨屎。有的人呢，不管给多少时间，随手写出来的代码都是干干净净的。这个就是程序员之间的能力差异，不用找那么多借口。

作为管理人员，碰到楼主所说这种例子，如果时间紧，我不会介意他们这么做。

如果时间很充裕，不好意思，下次汇报我会直接说这个人不行，建议不要涨工资或者少涨点意思意思。我绝对不会这么说：哎呀，他只是工资少才会这样，多给他涨点工资写的代码就很厉害了，不可能的，工资多少他都是这种水平。你有高水平，我会想办法给你高工资，而不是我给你高工资，你就会有高水平，有些人不要搞反了，别动不动就什么精神股东，你不行就是不行。也不要说什么优化会有 bug，怕后期优化有 bug，那你代码出厂就是优化好的不行吗，我觉得遍历 id 读 10 次 db 改成读 1 次 db，这样优化一下还能改出 bug 都不自测的人那实在太水了？别优化有 bug 了，有些人不优化都能有一堆 bug，我还见过拿非全局变量来做全局锁的人呢。

睁大眼睛，看好前提，时间很充裕。

list，set，map, dictionary 之类就不说了到处都用，其他用的最多的还是队列，用来做消息处理、任务处理、循环任务之类的场景还是蛮多的。其次是树，什么菜单、组织架构。图，几年 crud 生涯只用过 2 次还是 3 次，基本都用映射表来做的

有同学提到 DDD，其实微服务应该就是领域模型在架构层次的拆分，我看现在网上的博客，很多都是在同一个项目里搞代码层级的划分。甚至有些人在某一个单独的微服务里面还在搞 ddd 划分，我觉得没有意义

很巧，之前我在一家公司就是搞得你说的这种模式，主要有两个几个原因：

1. 人多，项目大，合作开发，我们大概有 15 个人搞一个系统的 crud 后端，为了抢时间。但是这么多人搞同一个项目，哪怕你代码分支管理的再好，也很有各种合并啊，冲突啊，而且人员水平层次不齐，很难管好所有人都按照标准执行，浪费很多精力，干脆分开来。我们大概分了什么通用服务，人事服务，工作流服务，产品服务，订单服务等等，3 人一组，水平差的开发简单的服务，水平高一点的开发难一点的服务。开发时先定接口标准，这样有业务耦合时不用等其他人。

2. 各个服务请求量不等，像人事服务这种基本没什么量，用差一点的服务器，像产品服务请求量就相对比较大，用好一点配置的服务器，遇到性能优化什么的，代码、架构改起来不会影响其他服务，部署万一出问题也不会影响其他服务，万一宕机，这个服务不能用了，但人事那边业务也会正常展开。

3. 为了试一试新技术新架构，体验体验，就这么简单。

我的理解是，不要为了用微服务而去用微服务，而是因为单体服务对这个项目，在当前这个时间点，有这样那样问题，才要去考虑用微服务。如果你很难说出现在用单体应用有什么问题，那我不推荐用微服务。