杂谈：一个程序员应该怎么成长？
昨天记录了一下面向对象的看法的话题，感觉好像有点抽象了，回想当初刚出来工作的时候，连面向对象的例子都没有接触过，虽然大学的时候学过“面向对象C++编程”，可以，那课程是一般人能学得会的吗？
对于刚1-5年的程序员，往往都是跟着项目组开展工作，而且都是完成最低端的代码工作，这个是毕竟之路。一般老员工也不会说自己的经验和技巧，不是不愿意，有时候到了一定程度，觉得那些都是理所当然的事情。例如用户提需求，也就能提出一些常做的工作需求，涉及到与他人沟通部分，基本上就略过了，这个一个人都常规思维方式。新来的程序员问多了，显得自己很笨，不问又什么都不知道，只能按照自己的模式来写代码，结果同样的一段代码，可能可以制造出不少bug,出来，或者性能严重低下。例如我这里就出现一些很低级的问题：
foreach(var item in list)
{
var id = item.EmployeeID;
var rEmp = dalEmp.GetEntity(t=>t.ID == id);
//其他处理代码
}
//其实改一下，效果就好多了
var empIdList = list.Select(t=>t.EmployeeID).Distinct().ToList();
var rEmp = dalEmp.GetList(t=>empIdList.Contains(t.ID));
if(!rEmp)
return rEmp.ToError();
foreach(var item in list)
{
var emp = rEmp.Value.FirstOrEmpty(t=>t.ID == item.EmployeeID);
if(emp == null)
{
//处理代码
}
else
{
//其他处理代码
}
}两段代码的效果是一样的，但是从性能来讲第二段明显更优。别看这么简单的代码，我是看过几次了。
程序员在完成需求的同时，要充分考虑代码的性能和容错，这两点很关键。例如，EntityFramework的linq2db是非常好用的方法，但是这对性能来说，只要一个不注意，就会带来严重的问题。
var list =
(
from hdr in db.SaleHdr
join emp in db.Employee on hdr.EmployeeID = emp.ID
join dtl in db.SaleDtl on hdr.Formno = dtl.Formno
join part in db.PartInfo on dtl.Code = part.ID
where hdr.CreateDate >= '2023-01-01' && hdr.CreateDate < '2014-01-01'
)
上述查询，part表的数据是比较多的，如果这里还要关联bom的话，那查询将会更加慢。可以针对这样的查询，拆分出多个查询来，分步查询，先查询hdr，带出hdr.EmployeeID和dtl.Code，然后分两次分别查询part和emp，这样即使数据量很大，也会非常快。当然在这里举例可能有点不准确，在实际业务开发中，这样的表关联查询，远远比这个例子复杂，越复杂就越需要去优化，不要怕写多一点代码，用不同方法去尝试，是一个很好的学习方法。
程序员除了需要积累编码经验外，还须要 积累组件的应用，例如MQ、Redis等，积累一些服务应用，如SSO，OAuth等，这些都是比较常见的；技术上，dotnet core和framework还是有很大差别的，但如果从逻辑实现来说，那没有差别。我开发的框架，已经把webapi的sso,oauth都已经封装好，另外对于各种常用的中间件也都封装好，api的route也都设定好了，设置IOC和AOP都是封装好的，对于程序员来说，都是透明的，也不需要去了解，是的，不需要了解！程序员在这样的环境下，成长是很困难的，但是往往程序员就是需要在这样的环境下成长。
企业要的是能干活的人，而不是来学习的人，学习是个人行为，说白了，和公司没有关系，但是在培养人才方面，却又需要个人的学习态度和能力，这是个很矛盾的事情。在这样的环境下，程序员就需要自己抓紧一切机会和时间来提升自己，从基础理论、基础技术技巧、业务逻辑分析、扩展性思维等等方面都要全面提升，这里不是一句话，是一个坚持的过程。
在小学到高中，老师是强制学习的，上大学后，很大程度是要自觉自主学习，出来工作就更加需要自主性更强了，甚至连个“老师”都没有，面对的就是一堆需求，不断赶工！这个时候就需要有学习途径，例如论坛博客、git之类的代码库等，多看看他人写的代码，多看看他人做的设计，从用户交互到业务实现全方位的了解一下，吸收好的经验和技巧，然后在实际工作中不断的验证和尝试。
以上是从个人角度来看程序员的成长。从企业角度，很简单的一个规则，就是要创造价值！交付-交付-交付。企业提供的平台不是教育机构，是商业行为。面试时候，面试官主要是了解应聘人员的技能技巧和经验，能为企业做什么，能多久适应工作环境和节奏。一般的IT企业很少有系统化的培训机会，除非大型企业。面向对象其实也和岗位设置理论一致，我一直在想，招什么人就干什么活，一来就能干活的人最好。例如一般写业务的程序员，公司为什么要去要求程序员什么都会？公司的开发框架都把这些技术封装好了，程序员直接用就好了。例如在微服务中常用的MQ，以RabbitMQ为例，一般要创建一个channel,然后需要定义Exchange和Queue,这些定义收发端还要有约定，如果是分两个程序员分别实现发和收，那么就需要沟通数据结构。如果框架封装好了这些，是不是一切变得简单了？例如：
//发送MQ消息的代码,用AOP方法发送消息
[MQPublish]
public RValue Insert(Employee emp)
{
var rIns = dal.Insert(emp);
return rIns;
//如果rIns.success == true,则执行MQ发送
//发送的appId 是当前微服务配置中定义好的,basic
//发送的resource就是API的资源名称employee
//发送的方法名称就是insert
//发送的数据是rIns.Value.ToJson()
}
//在其他微服务中，接收MQ消息的代码
[MQConsume("basic","employee","insert")]
public RValue mqInsert(Employee emp)
{
//这里处理收到的emp对象
//如果返回错误，自动记录错误日志，并向系统模块报告
} 参考：微服务下，实现数据变更通知
框架已经定义好通讯的数据结构，两个程序员完全不需要沟通，这些都是默认规则，另外程序员也不需要知道mq是怎么实现的，连mq相关的对象都不会出现。
在数据库应用中，往往需要发起事务，框架用AOP技术解决事务和分布式事务
[Autowire]
IDALSaleHdr dalhdr;
[Autowire]
IDALSaleDtl daldtl;
[Transaction]
public RValue Save(SaleHdr hdr,List dtls)
{
//保存一组表单的代码
} 参考：微服务中的分布式事务
标签[Transaction]自动实现了事务的发起，进入Save方法前，先判断当前状态是否存在事务，如果没有则创建，如果有则引用；方法执行完成后，提交或者回滚是根据RValue
上述两个例子，已经把一些复杂的过程封装起来，程序员是接触不到核心代码的，这样也就大大增加了程序员的学习难度，但是却能保证项目的一致性和稳定性。
看别人的代码，走自己的路。千万不要认为别人封装好了用就行，多想想为什么。[Autowire]、[Transaction]这样的标签，在dotnet中没有现成的，我也是参考java学来的，这样的标注确实方便,代码重用性也高了。其实实现难度也不大，愿意去尝试就可以了。
我写代码积累的经验告诉我，不要刻意去培养程序员，培养好了，可能跑了，过去几年就遇到很多次这样的糟心事。用外面培养好的最实在，只要改变一下编码规则就好了。怎么有过河拆桥的感觉，我也是这么被欺负过来的，呵呵。我个人只要求程序员有业务逻辑能力即可，什么面向对象、什么技术要求，都不重要，这样的程序员成本低，效率高，关键是到最后，要跳槽都难。有点不地道了。
一个程序员成长到一定程度，要么往架构方向发展，要么走项目管理，要么走售前或实施，有本事的，自己当老板去，这需要资源。更甚者直接转行。一般本科毕业23岁左右，在30岁以前是不是可以做好规划。
说回来，看看自己，好像啥也不是，写代码，感觉也就这样，没有什么特别的长处；需求分析，能看出点门道，好像又理不清；做运维，感觉自己不是这个料；做架构，好像差点火候；其实就是想偷懒，为少写一行代码而努力！对用户，为少敲一次键盘而努力！然后，就整了个框架出来，一开始就是培训使用注意事项，带一两个微服务开发，完事后就这样了。我个人的技术成长是比较慢的，主要是靠看文档慢慢学习，心累。从汇编、c++、asp、delphi、vb.net、c#一步步学，学一样丢一样，现在汇编那是铁定搞不会了，c++也是跟张三丰学了，dotnet core过程中，也整了一下spring boot，也是一知半解。其实我还挺热爱写代码的，总弄一些小工具玩玩，或者练练手，这样的积累平时看不出来，一旦用到可能就能减少很多工作量，当然，这个过程也写了很多傻X的代码，自己回头看也觉得自己是个小可爱。
先分享到这里吧，哪位大佬收小弟的，求带！