作为一个最近组团接了好几个项目的人，我也有些经验了，大概半年陆陆续续弄了 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. 为了试一试新技术新架构，体验体验，就这么简单。

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

@jinsongzhao 我们刚毕业基本都是学.net 的，但实际上工作中也做了很多 java 的活，其实 java 做个什么系统啥的也行，毕竟 web 那一套是相通的，所以接到 java 其实也做。.net 生态圈怎么说呢，基本的应用都有，什么大数据框架就几乎没有了，就算有一般可能人家也还是会去用 java 的成熟的。但是接个私活，没什么多高端的东西，基本碰不到.net 生态没有的的东西，其实还有很多本地企业都用的.net ，也信任.net ，而且二三线城市，说句难听的，找个会 linux 服务器的运维都没有

存在缓存里，每隔多少秒输出到 ui，或者每满多少兆输出到 ui，或者多种策略结合着来

@clrss 南孚的 65w 插头多个 usb 口，我用那玩意接的 magicbook，还行

私活这玩意，我感觉是要看个人剩余时间是否富余，以及个人心态的。有时候你只是想赚点零花钱，并且时间富余，可以接一下的，但是一定要甄别客户质量，要么少赚钱，求个省心省力。要么费点力，但是钱要多。

以前我也排斥私活，太累了。但后来工作比较清闲，闲的每天刷帖，你说接不接？所以我现在尝试找几个好友搞了个公众号一起接线下。一个人做项目累？好，大家一起来，你帮帮我，我帮帮你，钱分一分，不要嫌多嫌少，赚点零花钱，不美吗。

其实不想做广告的，但希望可以给广大同胞扩充下思路，可以参考下我们自己搞的公众号文章：
https://mp.weixin.qq.com/s/n82qBALe9BcpS1Vg2d2nYw
https://mp.weixin.qq.com/s/xj82b8GzKzofOfmmWxH7lQ

开发很多时候不只是跟技术做斗争，而是在和人做都在，很多防御性变成思路，有一部分是为了，出 bug 时，便于扯皮

技术角度来讲是不需要的，但是不怎么信任客户端，前端知道自己做了验证，但是作为后端没法确认前端是否做了验证，又或者是有输入性 bug ？另外，也不会给服务器什么压力，多几个字节？本来也没几个人会一直改密码，恶意攻击就是另一回事了，少几个字节人家也能攻击。

感谢大家的建议

练习写作文，学习写作文的技巧

大龄程序员经验，要稳定的话选 1 吧，人事机制完善的公司，过的还是挺舒服的。

创业公司的话，刚开始起步缺人可能会关心一下你，什么原始股啦，高薪啦，一旦公司起飞，大概率会用各种花里胡哨的方式淘汰掉之前认为“不怎么行的”员工，然后花钱招各种大厂出来的员工。如果你是赌徒心理，或者感觉自身实力比较强，可以选创业公司搏一搏，只是要注意不管什么什么 O 多牛逼，大部分创业公司撑不过 3 年。

话是这么说，但是年轻人嘛，想试就多试试，我当年也是这里折腾到那里，不折腾哪里来成长，哪里来抗坑能力。