未分類
2020 年 12 月 30 日

如何避免项目越来越乱

如何避免项目越来越乱

資深大佬 : lagoon 21

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

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

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

基本上的死循环是：

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

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

3 、迭代开始了…..

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

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

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

很无奈。

大佬有話說 (89)

  • 資深大佬 : lairdnote

    最好做减法

  • 資深大佬 : kop1989

    这就是代码腐败。
    随着业务和需求的改变，你在之前做的“精妙设计”逐渐都会变成 ifelse 。
    然后就是选择：继续往上堆还是重构。
    人力资源不够富足的一般公司会选择让老员工继续往上堆。

    直到整个系统变成一个黑盒。
    然后推倒从来。（这时候恰巧会出现一些新的系统设计概念，比如 saas，比如云）

  • 資深大佬 : onikage

    根本问题就是领导瞎指挥, 明天就要是病根.

  • 資深大佬 : kop1989

    所以减缓代码腐败的前提，就是足够的人力资源。
    保证对于程序的每个修改和完善都是基于充分考虑和设计的。
    但这明显对于多数公司不现实，性价比也太低。

    所以你看即便是 google，淘宝这种体量的产品，也都是在不断的推倒重来。
    只不过是通过一些软件工程上的流程优化来尽量让替代产品平稳推进。让普通使用者无法察觉罢了。

  • 主 資深大佬 : lagoon

    @kop1989
    好吧，看来是无法绕过的问题了。

  • 資深大佬 : hdbzsgm

    严格 code review 而且要人工做。 我自己的感觉是 如果想永远保持项目代码干净整洁 最好招两个大佬 专职做 cr

  • 資深大佬 : coderluan

    可以绕过的, 参考这个项目:

    https://github.com/kelseyhightower/nocode

  • 資深大佬 : caixiaomao

    需求文档没有 规划设计没有 全凭领导一张嘴 没法子 越做越乱 越做越烂 如何避免项目越来越乱

  • 資深大佬 : lyz1990

    无所谓啊，代码能跑就行。（手动狗头

  • 資深大佬 : yule111222

    领域驱动设计可解，前提是大家都玩，领导认同。起步比较难而且慢，起来后会很爽的

  • 資深大佬 : SuperMild

    很简单，加钱即可。项目越来越乱都是老板想省钱造成的后果，加人、给时间、请专家，没什么项目是搞不整齐的。

    不加人、加班、赶工期…… 没什么项目是搞不乱的。

  • 資深大佬 : zjsxwc

    以前有个人老是碰到领导乱提需求，
    然后每次有需求时，他就引入购买三方服务，于是三方服务预算越来越大，
    然后项目就被卡在财务哪里了，

    逃

  • 資深大佬 : hantsy

    对于开发，需要持续改进。

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

    公司管理层面，就没话了，100 个公司有 200 个不同的做法。

  • 資深大佬 : ruokw

    deadline 就在那 做得好也在，做的不好也在

  • 資深大佬 : rodrick

    @hantsy 这个是相对标准的流程了，估计按照主说法，文档那步就死了

  • 資深大佬 : xuanbg

    我只能说基础设施很重要。基础设施齐全，写点 crud 的业务代码费事吗？一点都不费事。

    为什么我推荐大家搞微服务，不要怕难，也不要怕麻烦，有机会就要搞。因为你一套微服务搞完，基础设施就攒出来了。而这套基础设施，你随便到哪都能用。

  • 資深大佬 : hantsy

    @zjsxwc 有些老板贪图一些小便宜。

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

    自己用开源的，一套自动化流程配置下来，累死人了，效果不可能达到商业服务。而且需要大量的时间和人力，这个成本下来远远超过购买商业服务 10 倍。

  • 資深大佬 : fengpan567

    针对这种明天就要，下周就要的，估计需求也是一句话，你觉得开发能做成什么样？能用就行！

  • 資深大佬 : sogwsc

    我们倒不是明天就要
    一个项目几个月 会花很多时间去定计划 计划非常细
    然后各项都在延期
    截止时间又不变
    等到测试阶段 已经来不及了
    然后开始发补丁

  • 資深大佬 : killy

    @coderluan 这项目代码整洁的有点离谱.

  • 資深大佬 : ericgui

    离职，找一个新工作，涨薪 50%+

  • 資深大佬 : mapoor

    “设计系统的架构受制于产生这些设计的组织的沟通结构。”
    ——M. Conway

    什么样的公司结构就会产生什么样的系统，根本原因就是没有任何规则能约束领导的嘴。

  • 資深大佬 : ghostsf

    做更多减法
    不断调整优化代码

  • 資深大佬 : ericgui

    @mapoor 是，本质还是管理层的问题，码农能做的事有限

  • 資深大佬 : Jinxxxx

    依业务看除非是 2B 公司且公司有钱，有耐心有要求愿意慢慢打磨。不然以国内 2C 的环境，慢慢把第一版产品打磨出来可能市场早就没了，所以第一版往往都是赶工做完推向市场抢占用户。这是业务决定的，毕竟没有业务谁都没饭吃。
    你要是真的想摆脱这类情况，可以看一些做 2B 做得比较好的公司，这种情况不说完全没有，但起码会好一些。

  • 資深大佬 : hbolive

    主你说的这种情况是普遍存在的。
    就拿京东来说，当年最开始就是 asp 做的，那时候的情况估计也是类似你描述的，一天一小改三天一大改。。但强哥能忽悠来投资啊，可以支撑后来的重构。。

  • 資深大佬 : fwee

    第一步就有问题，需求多时间少必然越来越乱，应该直接砍需求只做 MVP 。不过根本原因还是领导不行，只能换公司了。

  • 資深大佬 : 2379920898

    我见过。非要 1 个月就上线的。。说是怕失去市场。。但是往往这种老板都是无经验的，都做不起来。。我也见过好几个月出项目的老板。。人家对市场也不着急。。但是项目上线之后慢慢也运营起来了。。给你个角度去思考。你不如先考量领导的经验能力上来思考。。一般比较急上线的都是创业经验很少的领导。。。

  • 資深大佬 : tikazyq

    删库走人

  • 資深大佬 : kingzeus

    找个靠谱的团队很重要

  • 資深大佬 : arthas2234

    定时重构，剔除掉一些冗余的功能，我现在就在做这个事

  • 資深大佬 : manami

    不要用框架

  • 資深大佬 : wanguorui123

    没有代码规范、代码审核，很难做到代码的可维护性，大多数公司要求能跑就行了，也没有什么规范和审核之内的。
    很多细枝末节的东西还得靠精细化管理和团队自律，不然早晚都会乱写的。

  • 資深大佬 : MonoBiao

    代码重构专员

  • 資深大佬 : Otho

    靠管理和自律的事儿，又不算 KPI 啥的，那基本无可避免。

  • 資深大佬 : stleee0n

    熵增过程是一个自发的由有序向无序发展的过程

  • 資深大佬 : charlie21

    这有什么值得苦恼的？

  • 資深大佬 : baiyi

    《 Clean Architecture 》开篇就讲了这个问题

    “研发团队必须从长远的利益出发与其他部门抗争，软件的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分。如果忽视软件架构的价值，系统将变得越来越难以维护，成本也会越来越高。终会有一天，系统将变得再也无法修改。”

  • 資深大佬 : azcvcza

    想啥呢，代码质量又不算 KPI，能用多少 if else 就用多少 if else，没人会知道哪天来的新需求，就把之前重构过的给打乱了。还是去面向 B 端的企业好点，至少不像 C 端这样需求多变

  • 資深大佬 : conanjun

    纯粹个人看法：这个问题其实不仅仅在代码领域出现，其他领域也有。例如：刚刚发布的新显卡爆出频繁黑屏事件，刚刚发售的新手机爆出屏幕问题事件、电池事件，刚刚发售的游戏因为 bug 多获得各种差评，等等。 如今即使是国际大厂也避免不了出现这种问题。 我觉得问题就在于当今社会真是一个快节奏社会。一个产品想存活就要尽量压缩成本，尤其是时间成本。比别人慢一步就会失去很多市场。

  • 資深大佬 : wysnylc

    @kop1989 #2 还有新语言

  • 資深大佬 : OHyn

    做 C 端，就是抓用户需求。
    第一版摊大饼粗糙点没事，第二版还抓不到方向，继续摊大饼，基本就废了，该砍的功能要砍。
    之前我做的的一个项目，某个流程大改版了，领导还要求保留之前的流程，做到后台配置即可切换，并且“明天就要”，好吧。。。

  • 資深大佬 : ytmsdy

    0：需求响应不能太及时，很多需求仔细想一想其实是伪需求。一个字，拖，拖个两三天估计领导都忘了这事情了。
    1：做减法，砍功能，把常年不用的功能和代码下线。

  • 資深大佬 : XiLemon

    感觉这个问题无解

  • 資深大佬 : hhyyd

    通病了站在小公司的角度，快速迭代，赶着能用就行。等融到资了，有钱了，撤了整个团队，重新去重构，这个成本也是可以接受的。

  • 資深大佬 : mebtte

    多人项目没办法, 反正我自己的项目看不顺眼就重构, 开发起来真爽

  • 資深大佬 : tabris17

    @arthas2234 醒醒，重构不计入 KPI

  • 資深大佬 : djong

    @coderluan 可以+1

  • 資深大佬 : deletemyself

    深有体会，想要的太多做的太赶注定是最终会有问题的

  • 資深大佬 : StephenHe

    微服务吧，烂一个总比全烂的好

  • 資深大佬 : MaxFang

    这种问题目前也遇到一些，也很困扰，暂时感觉无解。
    暂时的做法是在自己可控的范围内，将相对稳定的模块单独维护或做系统，那些日常改动或临时急需求的模块，就写上去放在那吧。
    实在是没有做详细设计和技术方案的精力了，因为第一版的需求，可能上线使用一段时间后，就会做大改版。可能和业务有关，目前是做供应链相关的，具体的一些操作模式无法直接复制，都是快速试错加迭代。
    等一些大的模块相对固定了，再抽象模型来重构。

  • 資深大佬 : stevenkang

    其实很简单，如 #12 说的那样，能购买第三方服务的，就提出需要购买第三方服务才能做这个功能，哪怕花费的钱很少都没关系。

    时间久了，以后加功能就是：哦，这个功能基础版不支持，需要升级高级版啥的，加钱吧。。。

  • 資深大佬 : taogen

    时间、成本和质量只能选择两个。

    时间少、成本低 yes ！

  • 資深大佬 : anthow

    最近深有体会，之前一个项目要得很急，然后第一版的设计和编码都很拉胯。最近想重构，真的无从下手。

  • 資深大佬 : laminux29

    这个问题本质上是工程管理问题，你可以去翻翻几百年以来的城市规划、大建设、地铁新建、航母潜艇建造等书籍，都会有关于这个问题的描述。

    结论很一致：无解。

    大家的办法是：

    1.没钱时，对现有的东西，忍受混乱，修修补补，甚至容忍因此造成的事故。

    2.有钱后，报废或爆破旧东西，砸钱造新的东西。

  • 資深大佬 : jones2000

    小作坊的开发都这样, 没事不关管, 打补丁的开发就可以, 哪个有问题就改哪里, 千万不要重构, 文档,测试用例都没有的,老代码过几个月就看不懂了, 重构很有可能改出 bug 出来的.
    等项目成了, 有钱了, 挖一个技术团队重构.

  • 資深大佬 : SjwNo1

    我现在的做法是：保证我自己的代码符合规范，其他人我不 care （ code review 又不计入 kpi…）

  • 資深大佬 : liudengchn

    自扫门前雪，休管他人瓦上霜，把自己的代码尽最大可能的精雕细琢即可

  • 資深大佬 : laike9m

    自下而上是推不动的，唯一解决方案：跳槽去一家重视项目架构和代码质量的公司。

  • 資深大佬 : lishen226

    1 、顶住压力，延期交付。
    2 、辞职。

  • 資深大佬 : ychost

    把自己那份代码搞好，别人代码看不惯不要动，最多写个 adpater 包装一下

  • 資深大佬 : wupher

    时时勤拂拭 勿使惹尘埃

  • 資深大佬 : byte10

    @yule111222 领域驱动设计，一般人搞不了， 太难了，想的东西 比写的东西多

  • 資深大佬 : forYou

    几乎所有的初创团队都有这个问题

  • 資深大佬 : xingguang

    看看人月神话就懂了，所有这些都是无法避免的。除非找到外科手术团队模式的开发团队。

  • 資深大佬 : dany813

    没事就小范围重构吧，小步快走

  • 資深大佬 : jsnjfz

    趁早走人，公司迟早要完，只顾需求实现不管底层基础的并且说不通的都是垃圾。反正亏的不是你的钱，功能明天就要，钱明天就亏

  • 資深大佬 : Terry05

    歪个，大家有没有好用的 code review 工具

  • 資深大佬 : halk

    @Terry05 gitlab 等自带的就挺好用
    关键是人和流程，不是工具

  • 資深大佬 : jsjgjbzhang

    基于时间和成本考虑，一切都不是问题

  • 資深大佬 : 1534853288

    @hhyyd 有道理

  • 資深大佬 : micean

    一个卡车公司的销售做不出业绩，往往会从自己身上找原因
    一个互联网公司的市场做不出业绩，往往会从产品上找原因
    机器产出是固定，而人力产出却是弹性的，所以脑力密集行业就是一个天生压榨自己的行业
    所以需要一个懂得做市场的人才和一个懂得管项目的人才，有长远的规划，才能破这个局
    而不是一周做个玩意儿，挨个问“您要不要？”

  • 資深大佬 : th00000

    当然可以避免, 怎么做, 参考大型开源项目的做法
    你见过 JDK 推倒重来的吗
    你见过 Linux 推倒重来的吗
    人家是怎么保证项目代码质量的,
    无非就是严格的代码质量约束, 严格的 code review

  • 資深大佬 : Mithril

    @th00000 当你占领市场以后当然可以对需求说不，体量没那么大的话自然是用户要啥你就得改出来啥。
    你看.NET Core 对 Apple M1 支持的晚点都有人喷不积极，这还是体量相当大的开源项目了。

  • 資深大佬 : new123

    当有一天 bug 修改的进度和修复进度，远远超出领导的忍受阈值时，领导会问你如何改进，这时候重构才有它的意义。

  • 資深大佬 : yule111222

    @byte10 也没那么难，就算不用 DDD，需求一样要分析的，面向对象设计一样要做的，这只是提供了一套方法论教你怎么更好的做

  • 資深大佬 : charlie21

    @Mithril
    Surface Pro X 是 ARM 架构，微软的优先级是 先让 自家 SDK 支持 自家的 ARM 设备、再让 自家 SDK 支持别家的 ARM 设备。所以 喷吧 随便喷，有人理算微软输

  • 資深大佬 : byte10

    @yule111222 不难的话，全世界都用 DDD 了，面向对象编程 本来就难以理解，构建模型一般小朋友 不好理解。还是面向过程写的快，清晰。所以 DDD 才流行不起来。不过最近微服务把它 整热了一遍，未来还得凉。起不来的。

  • 資深大佬 : zypy333

    我觉得看技术 leader,选择什么样的架构,怎么安排开发计划,如何砍掉不必要的需求,如何保证代码规范的执行

  • 資深大佬 : taowen

    可以参考一下 https://github.com/taowen/modularization-examples

  • 資深大佬 : brezp

    @taowen 看了 , 感觉不错

  • 資深大佬 : mazai

    深有感触，当一个项目太过复杂以后，且没有文档与项目规范，不管是定位问题，还是改 bug，或是添加新功能，都困难无比

  • 資深大佬 : hzw94

    和我们团队的目前状况差不多

  • 資深大佬 : tesguest123

    两种方式，一，跑路。二，开新坑。业务一多不可避免。加个 if 下班完事。

  • 資深大佬 : wunonglin

    建议参考 https://github.com/kelseyhightower/nocode

  • 資深大佬 : leven87

    所以说码农连建筑工人都不如，建筑都是按照图纸作业，严格规范。代码想改哪都可以，天马行空

  • 資深大佬 : pkupyx

    重构。太烂就重写 v2 。

  • 資深大佬 : mamahaha

    既然是短时间内做完的项目，那整个推翻重做也没啥可惜的，做个参考就完了，何必做基础。
    不花大力气重做证明公司通过实测不太看好这个项目，暂时不赔钱就留着养人，等赔钱了就放弃。

  • 資深大佬 : nieboqiang

    你别把写代码当成一个神圣的事情，任何产品，系统都是有寿命的，过个几年就要准备重构了。

    只要保证这几年内能用就行了，你修补的手艺再好，也不能解决业务性的问题，不能创造价值，有时候 ifelse 是最具有成本意义的写法。

    任何事情都是有成本的，你做的又不是框架，只是提供服务而已，不需要考虑兼容性，大胆的写，然后大胆的重构就好了。