当你不知道怎么开始实现眼前的代码时，你需要考虑的就是两件事，一件是你需要什么样的数据结构，另外一件是你要怎么使用这个数据结构--也就是算法。
需要什么样的数据结构这件事在现今的大多数业务系统中几乎已经可以等价于你需要什么样的对象去表达你的业务概念，小到一个对象的设计，达到非常大的系统领域设计，这方面著作非常丰富更有完整的理论体系可以指导整个设计进程，比如DDD。
如果让AI去写程序，这一点提供足够的训练集，找出一个合适的模型，这一点看上去十分有实现的可能，虽然可能需要归纳的模型会非常的多，但毕竟还算收敛。理论上最理想的情况是每个行业的行业协会去规范一个业务体系模型，当然现实不现实这事，但毕竟是个努力的方向。
比较麻烦的是算法， 其实我更习惯把这一部分换个通俗的说法---脑筋急转弯。我经常和别人说我之所以喜欢写代码，更多的是喜欢做脑筋急转弯，程序 = 数据结构 + 脑筋急转弯。
面试中遇到过很多程序员说他们就写业务代码了，感觉没什么发展，所以想换工作，这种其实就是属于写代码不走脑子的，到哪都不会有太大变化，这种程度的代码AI未必写不出来。
重点是怎么写好代码，在写代码的时候要根据当前的情况推论出最适合的解决方案，要秉持每一行代码都是一个设计的理念去写，而这种时候问题就来了，AI更多是对已有方案的统计来辅助产生结论，可脑筋急转弯这种事一般会比较跳跃，虽然万事万物都是有联系的，跳跃也是有据可循的，但是很多时候这种跳跃跨越了太多领域范围，比如神经网络算法，明明是用来分解整合数据的，它却去模拟大脑，那这时候你就要了解生物学了，而即使最强大的计算机其复杂程度也远不如一个虫子的大脑。
另外一点，关于程序员年龄上限的问题，我一直保持着一个观点，除了天赋异禀（事实上我还真的遇到过），绝大多数程序员不过而立之年都只能算是能写程序而已，而立之后，程序员对程序的看法可能会有很明显的不同，因为代码也是创作，创作会包含很多人生的积累，世界观价值观这个扯远了，但是回顾写过的代码，无不是在各种场景下做各种平衡甚至妥协，平衡的因素有时候会包含工期，团队的技术组成，人员性格，配合的默契程度这些不太直观的因素统合起来决定怎么做才能完成项目。当然AI似乎倒是不太需要考虑沟通什么的，然而脑筋急转弯终究是绕不过去的，要解决跳跃性的联想，就需要各种看似毫不相干领域的数据来训练，光是庞大的量对技术的要求就不得了，而且这个模型谁来规划，即使世界知名的软件工程宗师。不过当然，那种人的境界咱推测不了，总之算法我想说的就这些。
至于机器理解需求的问题，这是个伪命题，因为能真正理解需求的程序员也不容易见到，所以才有敏捷这回事产生，而用敏捷去推动项目似乎AI更合适，因为它更不容易被迷惑，不会被次重要的目标而忽略了核心目标，不会因为某些词语有歧义而导致理解的问题，至少不会因为请假担心迭代周期。这方面不好讨论，反正目前人做的项目我也没见过需求就真的没理解偏差的。
而且，当年的嫦娥估计也没想到后来还会有人登月，看起来现在看AI做项目比当时看登月的可能性可高多了。不过无论什么技术目前也只是辅助人做决策，至少模型的修正什么的，反正我觉得至少有生之年还不至于担心被机器抢了饭碗吧。当然，未来的事，谁知道呢？
文/昵称：draculav
微信公众号：Github
/3 
