写代码，到底应该是自己去适应代码，还是让代码反过来适应你？

[tool2dx]

很多开发平台都有固定的框架体系，一般情况下，只能自己去适应代码。

但是随着项目代码膨胀，函数太多了后，由于架构体系都是别人的，按照别人思维继续修改，就变得有点繁琐。

我在想，是不是一开始思路就错了。写稍微大一点的项目，应该一开始，就让代码来适配自己的开发思路，这样等代码库变大后，才会有足够能力去 hold 住，不至于变成屎山，没人想接手。

[newaccount]

一套框架说到底就是一套 convention
这套东西就是为了遵守的人可以快速上手而定义的
不适应就换框架，别改来改去，免得贻害后人

[tool2dx]

@newaccount 人的思维模式有固定惯性。当用着自己熟悉的框架，就算几年前写的代码，也比较容易排错和添加新功能。

用别人设计的框架，光维护就很累了，更别说加新功能。

总是有一种上限被卡住的感觉（错觉）。真想用一把锤子敲所有钉子。

[newaccount]

@tool2dx #2 框架的意义不是让“你”方便维护，而是让后人方便接手
来个新人就得跟他介绍三五天体系结构，这么弄个十几二十次放谁心态都崩
这时候框架站出来，熟悉的直接上手，不熟悉的自己去看框架文档，不至于把老人折腾进去

[InDom]

如果你能 Hold 的住, 那自然就听你的, 新来的你培训去.

如果你 Hold 不住, 那你最好老老实实听框架的.

你到底是真能 Hold 的住, 还是你以为你能 Hold 的住?

你能 Hold 的住代码, 你能 Hold 的住所有同事么?

[tool2dx]

@newaccount
@InDom

为了向下兼容同事，把自己开发能力给限制住，感觉挺不值的。

[newaccount]

@tool2dx #5 牛逼的代码不是只有你才能写的出来的，而是所有人一眼就能看得懂的
真•大道至简
每次看到都能浑身一颤

[sagaxu]

一个项目 10 个开发，每个都有自己的思路，按谁的思路走？是选一个大家最能接受最熟悉的框架，还是选一个最适合项目需求的框架？总要有所取舍。

框架或者代码风格，从来都不是导致屎山的元凶。“临时搞一下”，“复制粘贴”，“多写几个 if-else”，不愿意花时间，或者说时间不充足就会有很多凑合着用的代码，然后就渐渐失控了，因为有了先例，便会在先例的基础上再次降低要求。

会不会变成屎山，取决于有没有强力执行的 review 机制，代码优雅程度是不是 KPI 的一部分。

[min]

一个人 hold 的住的框架？ 你确定有？
有又怎么样，如果是小规模的框架，分分钟给你推翻了

[weiqk]

想兼容同事的别做梦了，只好让同事来兼容自己

[tool2dx]

@sagaxu 你说到点子上了，别人写的框架，自己确实不太愿意花太多时间。反正代码和人，有一个能跑就行了。

自己写的框架，心态就不一样了，总会琢磨还有什么能改进的地方。

[kakki]

人马合一

[IvanLi127]

只要业务没大毛病，应该让代码适应业务场景，自己再去适应代码。

目标是优雅地实现业务需求，前期框架选错了肯定难受，真就新门类选不到就得自己写了，当然写出来也是得符合业务和同事的认知。

[jackmod]

@tool2dx #5 兼容同事不算什么，重要的是向下兼容 3 个月后的自己🐶

[FengMubai]

编译器看得懂就行

[c3de3f21]

虽然不想说但是心里第一个答案是：以人为本吧大概。毕竟代码/项目于个体（我这种普通码农）的一生来说不是非常重要。

[Tywin]

能适应 money 的就是好代码

[chendy]

看实际情况
比如说临时性的开发，别人咋写我咋写
比如说要长期折磨的项目，定一些简单的规矩大家别差太多

[huzhizhao]

不能只考虑自己啊。也要考虑同事
毕竟大型项目不是一个人就能做完的

[yb2313]

很简单，殴打同事直到他们适应你的代码

[000sitereg]

哪个都不适应，我擅长屎上雕花。