刚转职几个月
公司是在做人事相关的系统
看前人留下来的专案看的头很痛
不知道各位开发时会这样吗？
1.超多class 每个出来的资料都要用一个class去接
2.串接API
就是主专案写一个class然后透过这个去调用API去抓资料回来之后再放到主专案的class
去调用。
3.专案下分超多方案
这个我不太会解释
就是我连DB的可能会写成一个方案
然后要接的Model再写成另一个方案
每次要看要连哪一个跟要用什么接都还要看在哪一个方案底下，然后每一个又有交叉参考
各位前辈这样算是正常的吗？

假如专案有10多年，乱很正常。

切很细不奇怪，但依赖关系混乱就是问题

交叉参考是互相依赖吗？其他都正常

等哪天你看到一个class几万行，你就会希望他切开了

后续维护 切很正常 因为去改旧code很容易出问题

方案看重复使用率 太少的话我是不会开啦

很正常啊 你这都还没碰到微服务咧

不然你觉得怎么做比较好0.0

看来是你的问题

了解一下MVC可能有用？

你建议怎么写？有更好的写法当然更好

你太菜

java对吧 在业界很常见 这就是orm啊 应付很整齐的需求用 但复杂的还是要写sql 个人更喜欢字典字典和纯struct oop是有点走火入魔了java强制类 但部分还是可以写fp但java的字典就那鸟样 写起来太不爽

请问这边指的方案的英文是什么？

应该是方案底下很多专案吧？

方案跟专案 应该是 visual studio 的 solution 跟 project但原PO说专案下有很多方案 是否刚好相反?

你上网看一下开源 比较一下就知道了

觉得很正常，听叙述很像分层式架构

看来起像是切得比较细 分层式架构的样子遇过数据库字段 程式参数 函式之类都用中文的就很别扭

陨石开发法

OOP code长到最后 都会变成意大利面珍惜生命 远离 oop

pop写的跟意大利面一样长是人的问题不是oop的问题

变意大利面就是封装没做好又相互依赖

嗯..菜味很重

问就是陨石

陨石开发

是太菜看得头痛 还是code太菜看得头痛？

要不要了解一下分层？

你的问题

真的菜

正常 这叫多层架构？

就orm，至于架构部分要看他偶合性如何吧，如果切成很多层耦合性还很高就烂code 反之的话就你太菜

1. 其实是许多编译式语言高效的原因之一，所以这个答案也很看你写什么语言

每个class切分不同功能是good practice吧？