oracle小哥
能看懂代碼，就是自己寫不出來，很可能這只是你認為的“懂了”，並不是真正的懂了。
01. 細節能懂，但是整體不懂
每個編程語言的語法是有限的，如果是常用語法的話更是沒多少了，一個項目中，隨便拿出幾行代碼你可能知道是什麼意思，但是並不能說：你能看懂每一行代碼，就能看懂整個項目。你可能還需要知道：
項目是做什麼用的？項目用到了哪些框架和組件？代碼是如何分層的？
項目分成了幾個模塊？每個模塊的作用是什麼？模塊和模塊之間是如何配合工作的？
細節上，至少要了解方法的作用？哪些地方可能調了這個方法？如果修改方法的邏輯，是否會對項目其他功能造成影響？
如果是業務相關的項目，對數據結構的瞭解，也是非常有必要的。
02. 代碼能懂，但是業務不懂
如果是業務相關的項目，脫離了業務去看代碼是不切實際的。
業務流程是怎麼樣的？系統在整個業務流程中處於什麼位置？上下游系統都有哪些？是如何交互的？
業務模塊都有哪些？流程是怎麼樣子的？如果有前端頁面的話，需要按照前端--後端--數據庫這個完整的流程去學習。
代碼上有些看起來不合理的地方，也需要結合業務場景來看；反過來也一樣，代碼看起來寫的很好，但是業務流程不一定對。
03. 看的懂，寫不出來怎麼辦
很多外行人，甚至程序員新手，會認為寫代碼最重要的是“寫”，其實想比寫重要的多，所以如果你寫不出來代碼的話，先反思一下自己是不是拿到需求之後就直接動手寫代碼了？
個人認為，在正式敲代碼之前，你還需要：
新功能還是對老功能的修改？
如果是新功能的話，你需要從項目整體考慮這個功能；
如果是老功能完善的話，需要對這個功能有充分的瞭解，本次修改涉及哪些代碼？對原有流程有哪些改變和影響？
新增一個方法前，先確認有沒有現成的方法可以複用？修改一個方法之前，先確認會不會對其他功能造成影響？
如果代碼分了多層，需要確認在哪一層進行修改，不要破壞項目原有的結構；
甚至變量、方法起名，你也需要遵守代碼規範，看看項目其他的變量、方法起名是遵照的什麼規範。
總之，要想寫出好代碼，不僅要了解細節也要了解整體，不僅要了解技術也要了解業務，寫之前要多想，設計要充分。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
