这是一个创建于 823 天前的主题，其中的信息可能已经有所发展或是发生改变。
工作四五年了，最近做一些需求时，老觉得代码无从下手。实现方案是有的，但是如何组织代码，恰如其分地分层，封装，抽象代码这块还是经常纠结。
也看过一些设计模式，但是真正能结合到实际的很少。
看别人需求写的代码，又觉得别人好厉害，分层得当，保留了扩展性，但是如果让我从 0 开始写我是想不到这些的。
所以想请教下各位大佬，大家是怎么提高自己编写代码能力的？是否有相关的书籍 / 教程 / 经验 可以分享呀？
想突破下，不想经常纠结怎样写代码才比较顺畅了...
也看过一些设计模式，但是真正能结合到实际的很少。
看别人需求写的代码，又觉得别人好厉害，分层得当，保留了扩展性，但是如果让我从 0 开始写我是想不到这些的。
所以想请教下各位大佬，大家是怎么提高自己编写代码能力的？是否有相关的书籍 / 教程 / 经验 可以分享呀？
想突破下，不想经常纠结怎样写代码才比较顺畅了...
第 1 条附言 2023-07-12 13:15:27 +08:00
多谢大家的建议，目前打算看看 相关书籍 《代码大全》 《重构》 《代码整洁之道》 《架构整洁之道》，以及刷刷 leetcode
 | 1 chendy 2023-07-12 09:50:10 +08:00 多看多写，量堆起来了能力也就上去了 给自己的代码加注释，看看能不能解释明白 尝试调整自己代码的结构，看看有没有优化空间 |
 | 2 utfs8889 2023-07-12 09:55:07 +08:00 赞同楼上的，感觉是看得多，但是练得少了 把代码量提升上去就好 |
 | 3 miaotaizi 2023-07-12 09:57:52 +08:00  1 比起写代码的能力, 还不如去提高 沟通能力, 需求分析能力 拓展性啥的, 清晰的业务逻辑面前一文不值 |
 | 5 lasuar 2023-07-12 09:59:26 +08:00 你既然看过了别人的好代码，为什么不尝试把其中好的模式用到自己的日常工作呢；对于设计模式，你看了也得用熟悉语言写出每个模式的 demo 呀，只有写过了才会产生记忆，才会在需要的时候记起来并且用上。 |
 | 6 qloog 2023-07-12 09:59:53 +08:00 可以多看一些优秀的开源项目，学习下里面的分层设计以及为什么这么设计的原因。 |
 | 7 version 2023-07-12 10:06:32 +08:00 在如今 ai 的加持下..怎么写业务逻辑代码.已经是很简单的事情. 微服务细分业务场景才是趋势.... 整个框架基础代码可以搞设计模式... 具体业务实现..怎么方便怎么来..如果能调教 ai 写部分业务代码.那是最好的.也是未来趋势. 以前你是农民工..现在要往包工头发展才是主要路线..怎么去整合各种开源框架.服务.第三方 api..这样的经验才是重要的 以前追求精益求精.我这个墙体堆砌很平整.完美.不断精益求精...最终只会砌墙 但是后面发现..ai 加持下..机器人都砌墙都比你牛逼便宜了.. ai 下.编程语言基本没差别.也别纠结哪个语言好.哪个性能给力... 最终出货时间..出货成本.出货工期.才是未来趋势..现在还没到卷成本的时候..如果未来工作不好找的时候.编程就和搞硬件一样..拼命的抠成本. |
 | 8 WngShhng 2023-07-12 10:09:33 +08:00 这种情况，看下《代码大全》呗 |
 | 9 ZGame 2023-07-12 10:15:27 +08:00 我觉得从可视化角度去抽象代码有奇效。比入假设，controller 层弄成可视化的话，会怎么做，保留哪些信息。以此类推 |
 | 10 devilweime 2023-07-12 10:21:07 +08:00 分层才是关键，看下 DDD ，该用什么设计模式直接问 chatgpt ，回答的大差不差 |
 | 11 b4115Z4mRAz9P8EA 2023-07-12 10:22:28 +08:00 写一个程序，例如后台管理系统，不停的升级功能，会遇到一些需求重复去写，这时候你就会想如何简化这些重复劳动，这时候就会理解设计模式了。 |
 | 12 air8712 2023-07-12 10:36:04 +08:00 《重构》 《代码大全》 《编写可读代码的艺术》 《计算机程序的构造和解释》 |
 | 13 Leviathann 2023-07-12 10:42:47 +08:00 DDD |
 | 14 idolud 2023-07-12 10:44:04 +08:00 面向 chatgpt 编程 |
 | 15 FallenTy 2023-07-12 10:52:43 +08:00 代码量不够，写多了自然会感觉一些地方不对劲 |
 | 16 veike 2023-07-12 11:02:51 +08:00 via Android 要具备抽象思想，学会如何构建模型，不管是整个系统还是系统的实现细节都要尽量减少耦合，提高内聚性。 不管是设计模式，还是做系统设计，还是做服务架构，都是围绕解耦展开的，解耦是为了后期更容易的扩展。 |
 | 17 ifulikeweirdo 2023-07-12 11:16:23 +08:00 刚开始可以，先把代码写出来，写的过程中就会发现有些代码可以抽取出来公共使用，有些代码可以适当留个可扩展的地方，代码写多了就有感觉了 |
 | 18 zeal7s 2023-07-12 11:20:26 +08:00 [除了 ECS ，还有什么游戏架构 - Bob Nystrom] https://www.bilibili.com/video/BV1Ch411A7vS/?share_source=copy_web&vd_source=786686888e54210f1b5e731efcb6ec33 视频不长，但是直击要点，对于优化代码结构非常有帮助，演讲者是《游戏编程模式》的作者 |
 | 19 HunSiKing 2023-07-12 11:32:38 +08:00 我现在都是给 GPT 打辅助了. 它写完 , 我再改改 |
 | 20 yule111222 2023-07-12 11:43:33 +08:00 很多人说多看多写，其实是需要先学习理论，不然看了也是自己瞎领悟，不知道什么是好代码和好代码的设计原则。 推荐《代码整洁之道》《重构》《架构整洁之道》 设计模式没多少用了，很多都落伍了，完全不需要用 |
 | 21 KratosOmega 2023-07-12 11:43:35 +08:00 @WngShhng +1 总之还是多学多写吧。 我学生时期练 OJ 题，然后看了一些书，工作后除了自己的业务也会学习一些开源框架。 简单的业务没必要分层啥的，做好抽象与代码复用。稍微复杂一些的业务，可以先根据 [业务分块] 来抽象，比如登录注册业务，可能根据你的需求就可以分成 [验证码] 与 [普通接口请求] 两块。 然后随着业务越来越复杂，也要注意重构，原先的 [小的业务分块] ，可能会越来越大，这时候就需要拆分。 |
 | 22 shinelamla OP @utfs8889 练也得要知道怎么样写才更合理吧？现在感觉就是需求是能做，但是读起来难受，扩展性也不够 |
| 23 shinelamla OP @yule111222 好的我去看看 |
| 24 shinelamla OP @air8712 感谢推荐 |
| 25 shinelamla OP @FallenTy 只是知道不对劲，但是应该怎么改，我经常就是在纠结这个，不知道怎么改才是好的，无从下手 |
| 26 shinelamla OP @veike 低耦合高内聚，这个道理明白。但是要怎么做到信手拈来，「要具备抽象思想，学会如何构建模型」大佬的这些能力是怎么提升的？可否分享下~ |
 | 27 blacktail 2023-07-12 14:16:59 +08:00 都是工程能力，就是多写多练。 |
 | 28 BinaryDH 2023-07-12 14:26:08 +08:00 - 工程架构 - 学习代码如何合理分文件 - 学习代码如何合理分包 - 学习代码如何合理分工程 - 多利用面向对象的思想，以及一些设计模式作为辅助，做适当的抽象 - 封装 - 继承 - 多态 - 多看看成熟的开源代码 - ... |
 | 29 humpy 2023-07-12 14:47:03 +08:00 via iPhone 说真的，找一个自己会用到的开源项目，不用特别知名的那些，给它贡献代码（自己使用过程中一定会有某些痛点，去实现这些 feature ）。 书的话，代码整洁之道是一定要看的。我再另外推荐一本书，UML 和模式应用，我看这本书最大的收获是，知道了各种方法、函数应该放在什么地方。 |
 | 30 BreakInto 2023-07-12 14:52:49 +08:00 我觉得初学者很重要的是了解需求，针对需求写需求用例，根据需求分层 |
 | 31 yjxjn 2023-07-12 15:31:57 +08:00 1.无从下手原因在于不知道整套业务流如何运行。 2.对于代码的组织，我一般是这么干的。隔几个月再去根据业务知识看看这个代码这么写合理不？效率高不高？是不是可以封装成一个类，一个方法等等，切记，在自己极度确信不会改出 bug 的前提下，再去改代码。。。否则不要动~ 3.楼上说看书，其实我觉得不可取，原因在于你都不知道如何下手，按照书中的条条框框，会阻碍你初期编程的。 记住：先跑起来再优化。。 |
| 32 miaotaizi 2023-07-12 16:47:07 +08:00 一个清晰的需求 可以省去你 近千行代码 |
 | 33 SharkRazor 2023-07-12 17:28:53 +08:00 review ，一个月后再看一个月前的代码进行重构思考，甚至可以久一点半年，你回头看自己的代码就会感觉当年怎么这么写一坨屎然后就知道怎么写会更好了 |
 | 34 shinyruo2020 2023-07-12 22:54:56 +08:00 推荐《重构》和《从重构到模式》 |
 | 35 ruoxie 2023-07-13 00:43:38 +08:00 via iPhone 屎山糊的不够多 |
 | 36 crazyTanuki 2023-07-13 01:41:12 +08:00 1 从来不看书籍设计模式,都是通过不断重构自己的代码,根据自己的第一直觉,觉得怎样易维护就怎么写,慢慢把自己的代码技术迭代上去 |
 | 37 iorilu 2023-07-13 16:00:07 +08:00 也没啥好方法 无非是多练多写， 这是前提 第二是基于一个项目或产品， 不断优化， 有目的的那种 不要到处造重复轮子， 没意义 你做好一个项目或产品， 可以获得远远造 100 个轮子的价值 |
Select Language