昨晚七点面试到十点，技术和业务上谈得很透彻了，现在就等下周人资的答复和对接。薪酬也是互相考量的大因素吧，这个谈不拢，前面都白谈了。
说实话一开始想出来求职，并没有想那么多，只想出来透透气，看看外面的世界是什么样的了，自已是否还跟着上时代，能不能捡捡漏。
随着对求职网站的职业和公司的分析，自已也在逐步思索，我目前能做什么，想要得到什么。
一种比较平稳的是无缝对接，某家公司TeamLeader离职，需要人填补，技术栈和业务都比较对口，熟悉两三月后转正就能干活。这种好处是交接平滑，压力和风险较小。但如果仅是这样，为什么我要折腾来折腾去，无非还是同样的职位同样的生活，而且新团队到底是什么样的，能不能融合得好，还是个未知数。
另种是以写代码为生，走软件开发工程师路线。我倒是挺喜欢能安静不受打扰地专敲代码，一个个模块弄出来比较有成就感，成果也比较清晰。但自已的薪资拿三分之二甚至一半出来都可以招个不错的年轻人，也能干同样的活，会有公司要我专写增删改查和业务逻辑代码吗。
最后就是架构师路线，自已对技术栈的广度应该还是凑合的，从设计开发到测试到数据再到运维监控，均有所涉猎。但深度远不够，很多东西所其然不知其所以然，也没在正式项目中用过，公司如果把架构交付给我，等于要当小白鼠，能不能得到这份机会，也是不好说。
自已总结了一下，这几年都有哪些想做而没能做成的事，未来能不能逐个做到，也不在自已能力掌握范围内了。
设计：没接触过专业美工出设计稿和产品经理画原型图，都是听市场或客户口头描述，然后脑补，在白板上画画就可以开工了，做个初版来演示，大家看着没大问题就先上线，边用边改。这种好处是敏捷，上线快，但缺点就是设计和理解不足，随着使用反馈和需求的变更，越改越复杂，最后想重构也改不动了，牵一发而动全身，又有一定客户体量正用着。只能等着2.0版的重来，但基本没机会重新开发2.0版。
开发：开发框架都是公司固定的，做项目是没问题，但很多底层不支持，自已想改造，又没专门的时间和精力。需要一个团队来打磨，也需要公司从组织架构上考虑和领导的支持，因为这种架构团队，不像做业务的项目组，不能直接看出业绩增长和价值。
比如很多用户个性化的定制，都是底层硬编码在代码里判断客户的，这家客户的表单要多几个填写字段，那家客户导出的报表要长成另外的样子，甚至业务的逻辑和流程也都不一样。如果能从底层都做成字典，那只要客服甚至客户自已，去勾选配置就好了。
比如因为要用到一些控件，不得不强制客户用IE，但现在很多厂商也逐步支持WebKit了，没有去专门对接控件厂商，以升级控件架构。
比如很多客户服务器还是WIN2003的，只能支持.net 4.0，想用4.5以上语法甚至core，都不支持。需要客户重装服务器，要有专门运维组去跟进，必须所有客户都切换升级才行，不然只要有一家客户的服务器没升级，都不能抛弃4.0转到4.5或core。
比如前端框架，为了公司整体平台风格的统一，各业务系统一直是统一的旧UI框架，想引进layui、easyui、angular等，又无法在大项目中推广使用。
比如日志，目前日志是每个控制器里去写，好处是数据记录完善（可以记录修改前、修改后），缺点是要求开发人员都要复制几行日志代码。如果在拦截器那处理得好的话，应该能以AOP的方式全局处理。
而且日志都集中在MVC控制器，其实JS和SQL存储过程也会有各种异常和报错，目前没有相应日志体系，都只能靠猜和测试环境上跟踪，按理都可以有个日志体系。
比如代码自动生成，公司有几个T4模板，可以生成一些实体类和仓储等，但对于新加一张表的增删改查，没有用自动生成。一些重复有规律的代码，每次也是复制粘贴。
比如接口，项目中没有用到任何接口，这样就导致因开发人员习惯不同，对增删改查的写法不一样（比如删除用Delete还是Remove，或保存是一个Save方法还是分成Insert和Update），传的参数也不尽相同，风格不统一。
比如微服务，拆分服务是潮流，但具体要怎么拆，也要看业务场景，目前接触过的项目都是一体化，没有拆分出来。
测试：目前没有专业测试团队，靠开发人员自测。一方面测试深度不够，另方面没有引入自动化测试。有见过Selenium，但没具体用过。另外没写单元测试习惯，如果前后端没分离，又没有Selenium，那就只能人工在界面上去点。如果是前后端分离，倒还好，验证接口API返回数据格式即可。
版本：有要求团队每月发布一个版本号，升级后客户会弹个窗看到升级内容。但大家都没坚持，我也算了。版本没有管理，一方面不知道版本经历的变化，增加了哪些模块，另方面不方便回归，有问题没法回到上个版本（最多在服务器上升级前复制一个文件夹，有问题就切换文件夹）
数据：因很多历史数据问题，以及业务逻辑代码的Bug，经常需要上远程服务器直接在生产环境UPDATE数据。风险超级大，一方面容易手抖更新错（甚至漏加条件全表更新。。。），另方面不可能全由大佬处理，还是要交给客服或实施同事上远程，客户资料容易泄露，数据容易出错，不可控因素太多。
一些表有冗余字段，因代码不完善，经常有更新不全的情况，SQL每晚可以跑些任务，从核心基础表更新到冗余的各表字段。并且不能更新完就算了，这是在掩盖错误，要先查出有哪些不一致的，先记录日志，再更新，并在第二天派人去排查为什么数据会不一致。
数据经常要和第三方对接，特别是政府部门要上报各种数据。缺乏一个统一的数据出口，各个报表自写自的逻辑，都按开发人员自已对业务的理解来出数据，容易口径不一致，客户面对同样时间段的各种数据，经常对不起来，到底哪个才是准的，没人说得清楚。
大数据：数据掌握在手上，怎么产生经济效益。一方面是做数据可视化，把报表展示得更加美观。另方面是做预警，精确推送数据或统计分析给客户手机上。
运维监控：服务器上的性能波动，没有专人管理，也缺乏专业工具。IIS、SQL服务时不时卡死，目前都是人工上去重启下服务，用户体验不佳，也容易造成正在操作的数据中断和丢失。如并发量大，消息队列和缓存应能减缓服务器压力，但没碰过能用上的场景。
SQL性能，也没专门监控，项目的瓶颈经常是在SQL，一段SQL语句没写好，卡个几十秒都很正常。常见大表的常用字段是有加索引，但索引不能解决所有问题。
升级系统，能在晚上当然是最好，但白天也经常需要升级。对于.net这种编译型，如果在有大量操作时替换DLL，会造成卡顿甚至数据丢失。这个有想过用Nginx转流量来达到逐个升级，但没在正式项目中用起来。