如何避免项目越来越乱

2020-12-10 11:09:20 +08:00
 lagoon

之前呆过某家互联网公司,需求总是拍脑门(没有经过思考和设计)+明天就要,日积月累,后台越来越乱。( ps.不是产品设计人员的错。领导明天就要,产品能设计一周吗?)
导致后台动不动就炸,改点什么,异常困难。

最后公司不说死在这上面,但发展也深受拖累就是了。

后来渐渐发现,项目无法摆脱这种糟糕的情况。

基本上的死循环是:

1 、第一个项目往往是新团队。领导也没底,不放心给超长时间把第一版做好。都希望尽快先出点成果,好交代,也好考察员工能力,万一做不出来也好调整。(明明第一版是最重要的基础)
于是第一版总是混乱赶工。这种混乱不单是技术混乱,而是从需求,到开发,到测试的整体赶工混乱。

2 、混乱的第一版完成之后,基础已经歪了。但这时候,其实可能是获得表扬的。超出预期达到了 xx 目标。
这时候,需要大重构而不是修 bug 式的小重构。 这时,“第一版+大重构”的时间,远远大于“好好做第一版”的时间。
显然不可能。

3 、迭代开始了.....

4 、项目质量越来越差.....


这个死循环不知道怎么破。

对于领导来说,新员工新团队,怎么可能放心给半年以上的时间去做一个东西呢?万一做不出来怎么办?

很无奈。

9462 次点击
所在节点    程序员
89 条回复
lairdnote
2020-12-10 11:10:50 +08:00
最好做减法
kop1989
2020-12-10 11:13:39 +08:00
这就是代码腐败。
随着业务和需求的改变,你在之前做的“精妙设计”逐渐都会变成 ifelse 。
然后就是选择:继续往上堆还是重构。
人力资源不够富足的一般公司会选择让老员工继续往上堆。

直到整个系统变成一个黑盒。
然后推倒从来。(这时候恰巧会出现一些新的系统设计概念,比如 saas,比如云)
onikage
2020-12-10 11:15:35 +08:00
根本问题就是领导瞎指挥, 明天就要是病根.
kop1989
2020-12-10 11:17:10 +08:00
所以减缓代码腐败的前提,就是足够的人力资源。
保证对于程序的每个修改和完善都是基于充分考虑和设计的。
但这明显对于多数公司不现实,性价比也太低。

所以你看即便是 google,淘宝这种体量的产品,也都是在不断的推倒重来。
只不过是通过一些软件工程上的流程优化来尽量让替代产品平稳推进。让普通使用者无法察觉罢了。
lagoon
2020-12-10 11:26:39 +08:00
@kop1989
好吧,看来是无法绕过的问题了。
hdbzsgm
2020-12-10 11:29:40 +08:00
严格 code review 而且要人工做。 我自己的感觉是 如果想永远保持项目代码干净整洁 最好招两个大佬 专职做 cr
coderluan
2020-12-10 11:32:46 +08:00
可以绕过的, 参考这个项目:

https://github.com/kelseyhightower/nocode
caixiaomao
2020-12-10 11:39:33 +08:00
需求文档没有 规划设计没有 全凭领导一张嘴 没法子 越做越乱 越做越烂
lyz1990
2020-12-10 11:43:21 +08:00
无所谓啊,代码能跑就行。(手动狗头
yule111222
2020-12-10 11:46:16 +08:00
领域驱动设计可解,前提是大家都玩,领导认同。起步比较难而且慢,起来后会很爽的
SuperMild
2020-12-10 11:49:20 +08:00
很简单,加钱即可。项目越来越乱都是老板想省钱造成的后果,加人、给时间、请专家,没什么项目是搞不整齐的。

不加人、加班、赶工期…… 没什么项目是搞不乱的。
zjsxwc
2020-12-10 11:50:00 +08:00
以前有个人老是碰到领导乱提需求,
然后每次有需求时,他就引入购买三方服务,于是三方服务预算越来越大,
然后项目就被卡在财务哪里了,



hantsy
2020-12-10 12:10:54 +08:00
对于开发,需要持续改进。

1 。正确的使用 Git 是第一步,必须使用 Branch 提交,一切项目的产出(包含文档,可以是 MD
,Asccidoc,最终输出 PDF,Doc 等)都要 Git 版本化。
2 。 代码写测试,做 CI 集成,借助云平台检测质量,等。

公司管理层面,就没话了,100 个公司有 200 个不同的做法。
ruokw
2020-12-10 12:42:25 +08:00
deadline 就在那 做得好也在,做的不好也在
rodrick
2020-12-10 12:58:48 +08:00
@hantsy 这个是相对标准的流程了,估计按照楼主说法,文档那步就死了
xuanbg
2020-12-10 13:01:28 +08:00
我只能说基础设施很重要。基础设施齐全,写点 crud 的业务代码费事吗?一点都不费事。

为什么我推荐大家搞微服务,不要怕难,也不要怕麻烦,有机会就要搞。因为你一套微服务搞完,基础设施就攒出来了。而这套基础设施,你随便到哪都能用。
hantsy
2020-12-10 13:07:06 +08:00
@zjsxwc 有些老板贪图一些小便宜。

项目的基础设施,我是建议全部能用商业全部购买商业版本,Github 有付费的( Team 等一些管理只有付费的才有),CircleCI 有付费的,Code Climate 等。国外的很多云服务模式做得很好,开源项目可以免费体验大部分功能(一些只有付费才开放)。

自己用开源的,一套自动化流程配置下来,累死人了,效果不可能达到商业服务。而且需要大量的时间和人力,这个成本下来远远超过购买商业服务 10 倍。
fengpan567
2020-12-10 13:52:00 +08:00
针对这种明天就要,下周就要的,估计需求也是一句话,你觉得开发能做成什么样?能用就行!
sogwsc
2020-12-10 13:54:30 +08:00
我们倒不是明天就要
一个项目几个月 会花很多时间去定计划 计划非常细
然后各项都在延期
截止时间又不变
等到测试阶段 已经来不及了
然后开始发补丁
killy
2020-12-10 13:57:08 +08:00
@coderluan 这项目代码整洁的有点离谱.

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/734046

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX