论糟糕的开发体验

[tsja]

1. 开发频繁被人打断： 被叫去开会、处理其他问题。

2. 低效的结果反馈： 修改一次代码，需要等数分钟编译 or 部署，若结果有问题还要重新修改。

3. 重复性的工作劳动： 懂得都懂

4. 复杂的沟通成本： 自己的工作在别人的工作基础上，但对方说不明白问题。

还有人什么 v 友们可以补充

[wonderfulcxm]

深有同感，不过我 1 的情况现在少了。

[c3de3f21]

我草，直接报我身份证好了

[importmeta]

糟糕的工作环境, 无隔断大平层写字楼, 空气不清新, 食物的气味, 二手烟混杂

[m1nm13]

@importmeta 二手烟+1

[aikilan]

本质是人类总想在混沌系统中追求秩序，求而不得带来的失控感，使人焦躁难安。

[iSteven]

请把监控从我身边撤走，谢谢 😂

[maichael]

老板/运营/产品是个 SB

[cloudfstrife]

往屎山上堆屎，真的感觉心累。

[mouyase]

补充几个我已经在站内吐槽过的。

数据结构和接口字段设计混乱，无法理解并且没有文档
明确的数据/逻辑错误，另一端按错误的逻辑适配，服务端不改并且要求你也按错误的逻辑适配
结构修改/删除不同步信息，导致生产环境上线后模块崩溃

[neptuno]

再加一个刚装修完的办公室

[sngxx]

联调上下游挂掉

[LavaC]

我们的开发组组长每次跟 SE 对话都能吵半天，旁听就能听出来他们在鸡同鸭讲，从关键的 X 问题聊到 Y 问题和 Z 问题，在 Z 问题决出胜负后才有会回到 X 问题上。虽然项目紧急的话看着只能干着急，不过当戏看还挺乐的。

[levelworm]

2 可能还真的可以想办法搭建一个不用远程部署的本地测试环境。

[uni]

面向对象，设计模式满天飞，根本找不到副作用的影响范围
不写类型
文档看不懂，报错看不懂

[Promtheus]

频繁打断是最烦的，写了这么多年代码还是不能习惯写代码的时候中断去处理其他问题。。

[abc1310054026]

抽象的产品经理口头描述的需求

[lovelyxiaod]

我来补充: 内网开发(限制联网或者虚拟机极其糟糕的性能体验)

[tsja]

@lovelyxiaod 同感, 我上一家公司甚至 npm 和 maven 仓库也都部署在公司本地

[corcre]

@lovelyxiaod 内网开发, 但是数据库分布在 4 个不同的服务器, "我不管, 我就要取这些数据, 领导要求的"

[McZoden]

1. 开会不带耳机，功放
2. 哼歌不自知
3. 劣质青轴

[Ackvincent]

放宽心态就好,很多时候都是在摸鱼,混工时.不需要太认真.

[fffq]

二手烟 +1

[zld150]

@McZoden 是在说我么，达尔优 168😂

[2funny]

卡死的开发机

[McZoden]

@zld150 优尔达不错了

[fenglangjuxu]

第二条 深有感触 修改一行代码 编译发布 需要好久 这个时候不由得想起了世界最好的语言 php 可以直接修改调试 哈哈哈

[Hopetree]

只要是工作上的，无论是程序员还是其他行业，都是这样，除非是写自己的东西，这就好比工作跟爱好一样，虽然都是以开发的形式实现的，但是体验是完全不同的

[XueXianqi]

1. 开发过程中，需求不断变更 or PRD 写得不够详细，需要不断确认需求
2. 前端通用组件不兼容，要求后端改请求体/响应体结构
3. 测试直接 @开发，直接甩一张图，没有描述问题的详细信息
4. 时间倒排，直接给发布的 DeadLine

[qingshui33]

这 4 点我全都占了，每天都在崩溃的边缘

[wolfie]

4 +1 。
接触过好多程序开发，连问题都描述不清楚，上来就讲自己一堆细节问题。

[jeesk]

1. 频繁打断， 自己排查问题， 搞得正上头，突然叫走， 这功能和我有鸡把关系
2. 忍了，
3. 帮别人擦屁股， 很多时候就是 1-2 个月的代码， 然后突然告诉你的功能不能用了， 然后自己又得在分支里面不断构建。 最坑的是，构建还是跨平台的代码，pc 端 4 个平台。 慢成狗，公司测试机器就是一坨屎。

[jeesk]

还有一个开发体验问题， 如果自己手里有两个项目并且有依赖性，并且项目里面各种子模块，还有一个项目偶尔搞一下，


最后你发现， 并行开发，mastet ，加两个开发分支， 最后就是好几种结果。 还有一个偶尔搞一搞， 也是分支开发，里面各种子模块， 一天下来，头是晕的， 什么鸡把代码整洁都是扯淡。


不行你试一试同时开 2 个 as studio ，2 个 golang ，2 个 vs code ，还要开各种命令行， 每天下来人都麻了。

[speedmancs]

2：这样不是正好可以摸鱼一会吗

[speedmancs]

2：尽量写单元测试，这样新功能的 bug 可以及早发现并且可以在本地测出来，能减少来回部署测试的次数，提高效率
我们是 20 多个 repo, 有测试集群，容器化部署，每次修改一下代码编译加部署大概十几分钟，其实也还好，测试环境下尽可能打开 log ，这样也能在测试时及早发现问题。另外我们每个代码合入都有 code review,一般也是几次迭代就能提交，一两天之内。

[speedmancs]

我工作 20 余年了，很多类似问题也遇到过，有一次我遇到的项目，很小的改动，提交后编译和跑所有 test 需要 17 个小时。。。。后来实在撑不住就跑路了