02能看懂代码,就是自己写不出来,怎么

怕什么真理无穷

进一步有近一步的欢喜

先抛一个观点

很多人的建议是：多敲！！！多敲！！！多敲！！！

多敲那是必须的，就比如你想要学会游泳，肯定要下水，如果永远不下水，再给你多么高端的技巧和方法，那都是麻绳提豆腐——没什么卵用。

但是仅仅多敲就够了吗？

多敲一定是建立在多思考，多总结的基础上，否则多敲只会让你提高打字的效率，仅此而已。

回答原文标题：能看懂代码，就是自己写不出来，很可能这只是你认为的“懂了”，并不是真正的懂了。

就像听了很多道理，依然过不好这一生一样，你以为的懂了是真的懂了么。

下面简单分析一下：

01.细节能懂，但是整体不懂

每个编程语言的语法是有限的，如果是常用语法的话更是没多少了，一个项目中，随便拿出几行代码你可能知道是什么意思，但是并不能说：你能看懂每一行代码，就能看懂整个项目。你可能还需要知道：

项目是做什么用的？项目用到了哪些框架和组件？代码是如何分层的？

项目分成了几个模块？每个模块的作用是什么？模块和模块之间是如何配合工作的？

细节上，至少要了解方法的作用？哪些地方可能调了这个方法？如果修改方法的逻辑，是否会对项目其他功能造成影响？

如果是业务相关的项目，对数据结构的了解，也是非常有必要的。

02.代码能懂，但是业务不懂

如果是业务相关的项目，脱离了业务去看代码是不切实际的。

业务流程是怎么样的？系统在整个业务流程中处于什么位置？上下游系统都有哪些？是如何交互的？

业务模块都有哪些？流程是怎么样子的？如果有前端页面的话，需要按照前端--后端--数据库这个完整的流程去学习。

代码上有些看起来不合理的地方，也需要结合业务场景来看；反过来也一样，代码看起来写的很好，但是业务流程不一定对。

03.看的懂，写不出来怎么办

很多外行人，甚至程序员新手，会认为写代码最重要的是“写”，其实想比写重要的多，所以如果你写不出来代码的话，先反思一下自己是不是拿到需求之后就直接动手写代码了？

个人认为，在正式敲代码之前，你还需要：

新功能还是对老功能的修改？

如果是新功能的话，你需要从项目整体考虑这个功能；

如果是老功能完善的话，需要对这个功能有充分的了解，本次修改涉及哪些代码？对原有流程有哪些改变和影响？

新增一个方法前，先确认有没有现成的方法可以复用？修改一个方法之前，先确认会不会对其他功能造成影响？

如果代码分了多层，需要确认在哪一层进行修改，不要破坏项目原有的结构；

甚至变量、方法起名，你也需要遵守代码规范，看看项目其他的变量、方法起名是遵照的什么规范。

总结

总之，要想写出好代码，不仅要了解细节也要了解整体，不仅要了解技术也要了解业务，写之前要多想，设计要充分。