刚入职的时候做过一个社交系统，想着将来数据量会很大，就做了分库分表。扩展性是大了，但因为是按id分的表，导致不少需求不容易实现，比如按标题搜索等。要么拒绝需求，要么再搭一套转用于搜索的系统。结果在用户量不大的时候，就把系统弄得比较复杂，迭代慢。而实际上在数据量不到预设的十万分之一的时候，该产品就因为种种原因下线了

前公司开发负责人，不知道是不是为了显示开发能力牛，做了一个资讯系统，一个人用了Go、PHP、java 3种语言+rabbitMQ+ES+mongoDB等，安装所需要软件花了2小时，我心里那个郁闷…而且经常挂……
因为Go是复制其他项目模版，写shell监控，发现相关进程挂了用start居然报错，起不来！非要手工打start😂😂我心里想，你写出来爽了，想过我们运维的感受吗？！😂😂

关于淘宝，我看的是<企业it架构转型之道>。以上其实阐述了架构设计的三原则。适用优于业内领先，演变好过贪大求全，简单优于复杂。负责的项目花了三个月重构了，由原负责人操刀做的。主要是将业务梳理提高可读性。但大佬说了要灵活应用设计模式。然后就牵强使用设计模式，原有业务代码全部复制，原负责人做完后主流程常规场景能过。但各种业务块都有缺漏。所以今年来一负责，bug层出不穷，找个问题要兼看新老两个服务的日志。看部分遗传的业务代码，原本历史遗传就杂乱得很，现在迁移加套设计可读性反而更差了。

能否详细说明一下什么叫到有好的问题的地方去，很想知道这个问题的答案。

做一个淘宝那样的，客户指的是业务类似，但用户量多少，需要多少并发数，搜索性能等如何都是需要跟客户沟通后才能决定技术选型的。现实中我们的有些系统已经满足了业务需求，就没有必要为了追求技术复杂度而去拆分了，只有面向问题技术选型才会有成效。

程序员提高自身技术水平最好的方法是“找到一个有好问题的地方”，在问题中锻炼技术应该是最行之有效的方法

头份工作里有个印象比较深的，过度使用多线程技术追求并发，还弄了个所谓框架，却经常把主线程搞挂，后来一查发现，所谓框架净在主线程里玩并发了😂

BAT的开发人员占据了技术推广的高地，耳濡目染后，让开发“企业内部应用”的人员也从开发“互联网应用”的角度思考了

用简单技术解决问题，直到问题变复杂。

五万块，一定要做啊，花一个月去谈需求，花三天去开发。

我们的环境，是用一个vpc 连实验室的server，通过这个server建立ssh隧道连硬件设备，我真的不明白为什么这么弄，硬件设备每次又不能多人一起用，而且硬件设备本身就连很多其他设备够复杂的了，又加了个隧道整的每个操作都要先建隧道，不但使环境变得复杂，还带来了隧道关的不干净后面建立不起来等其他问题。而且我一直觉得隧道很脆弱容易中断，虽然中断的问题倒没有碰到。真的神烦

老师，那又有个问题，就是我们如何在解决眼前问题和规划未来方向之间平衡呢？如果只关注当下问题，而不为未来留余地，会不会给自己的未来挖坑呢？这中间的度需要如何把握呢？

有时候在其位才谋其政。技术需要不断学习，但是实际生产环境一定要跟着业务的情况而量体裁衣，不要喧宾夺主。

业务驱动系统改进，不要过度设计，技术应遵循合适原则。

苦啊，最近十十五

找到一个有好问题的地方，👍