搜索
  • 遇到对文档要求极高的领导该怎么办？
  • 发布于 2个月前
  • 300 热度
    13 评论
核心矛盾: 工资待遇很不错

写代码前要求我先把文档写出来,详实程度要求每个 service 中将会有哪些方法,共有私有。开会的时间占到了工作时间的 50%左右。领导是写代码出身,但每次开会和其他交流中都透露出对"写代码为低级工作,确定业务为高级工作"的看法，我不否认他的某些想法,目前也会尽力完成他想要的东西,只是怕很多矛盾后面会越来越尖锐 最近和其他同事一起下班才知道部门其他同事也对他颇有微词,我进来时替换的这个岗位原来的开发就是被骂跑的。


大家如果遇到这种领导该怎么办？

用户评论
  • 回忆经典
  • 你领导没错，代码只是低级工作，你甚至可以交给刚毕业的大学生写，但实现设计并不是谁都能做好。等你写代码的时候更多考虑的是语法和语言特性，不会有太多思考逻辑的时间，这也是为什么要在开会和写文档的时候多思考，想好了再动手。
  • 2024/5/29 18:13:00 [ 0 ] [ 0 ] 回复
  • 王晶
  • 工资待遇很不错就够了，毕竟他这个问题又不是什么十恶不赦的问题，只是有点吃屎，而且你为啥非要按照他的流程走，不能自己先写一部分然后用 AI 搞定文档自己再删删改改吗，我倒是认为你们老板的想法没啥大问题，确定业务就是很重要，毕竟你再花里胡哨的业务，只要是正常的基本都有人实现过了，代码层面都有可参考的东西，毕竟码农就是...
  • 2024/5/29 18:11:00 [ 0 ] [ 0 ] 回复
  • 卧龙生
  • 先设计再编码！这是锻炼从小工到大师的第一步，大师首先要做到的是胸有成竹，所谓心道手到，先心到然后做到手到，然后大师成。
    我就是这么训练自己和 chatgpt 的。先自己写伪代码，注释，然后将写代码变为填空。当我发现自己设计出错了，那么往往就又学到了。
  • 2024/5/29 18:01:00 [ 0 ] [ 0 ] 回复
  • CEBBCt
  • 私有方法是不可能在设计阶段就确定的。甚至公有接口也往往不能在设计阶段就能完全确定。在设计阶段纠结过多末枝细节是会降低生产力的。当然，我有一个巧妙的方法，相信你也想到了。你先偷偷把代码写出来，然后作为设计提交上去。至于领导分配的写代码的时间，你可以去摸鱼，也可以提前去预测他下一阶段的设计。
  • 2024/5/29 17:48:00 [ 0 ] [ 0 ] 回复
  • Scys
  • 业务驱动型项目是这样的。日企项目的文档才是详细到令人震惊，连方法内的代码也会在文档中以伪代码的形式描述出来。
  • 2024/5/29 17:44:00 [ 0 ] [ 0 ] 回复
  • Storm
  • 还行吧，我这边 SB 公司，写个周报老板甚至会挑你标点符号用的不够“标准”，比如分段数字序号后面必须用顿号，分段结束后必须用分号之类的，标点符号不能让他满意他就让你重写。
  • 2024/5/29 17:42:00 [ 0 ] [ 0 ] 回复
  • DuXing
  • 哦，这不就是日式开发吗
    有幸看过某大型企业招标的代码要求，注释覆盖率 100%
    怎么说呢
    const six = 6 //66666666
  • 2024/5/29 17:41:00 [ 0 ] [ 0 ] 回复
  • BruceLe
  • "写代码为低级工作,确定业务为高级工作" 这句话没毛病。 业务代码最不值钱了，其包含的业务知识才值钱。
  • 2024/5/29 17:40:00 [ 0 ] [ 0 ] 回复
  • pckillers
  • 给时间照做就行了。开始阶段，我觉得写文档和写代码都是一种设计结构的方法，写出来才能发现问题，逐步修改。这是管理者只愿意看图流程图之类的文档而已，没心思看代码。 除非是成熟项目，不然一次成型的概率太低了，最后还不是都要改。
  • 2024/5/29 17:39:00 [ 0 ] [ 0 ] 回复
  • Dock
  • 经历过这么多年，很赞同“写代码为低级工作,确定业务为高级工作”这句话。代码实现，随便找个两三年工作经验的，基本上都可以胜任（普通功能需求，无高深逻辑算法，不犟）。但是如果找一个对业务很熟悉，一聊就明白的，很难，码农在一个公司长久的优势基本上就是业务理解了吧...个人偏见，不喜随便喷。
  • 2024/5/29 17:38:00 [ 0 ] [ 0 ] 回复
  • Jeff
  • 和你有类似经历，之前老板也是对文档要求很高，语句通不通顺都有要求，画图要求都很高，一个文档能改十几遍，确实难受，但确实也有提升，这种情况确实会导致下面员工离职率不低，只能说好好沟通面向老板输出吧，保证写文档时间够和薪资不错就行了。
  • 2024/5/29 17:37:00 [ 0 ] [ 0 ] 回复
  • Fayer
  • 有一说一，没太大问题...写业务代码就是低级工作，根据业务进行设计才是高级工作，只会写业务代码屁用没有。先写文档还是先写代码就是个风格、习惯的问题，各有优劣。但是在当下，先写一份设计清晰、描述详细的文档，是可以让 AI 快速解决代码的问题的，只要你的文档足够明确，AI 生成的代码跟你直接写的没区别，甚至可能更好，而且在整理思路上还会更优于边写代码边改。
  • 2024/5/29 17:26:00 [ 0 ] [ 0 ] 回复
  • 守一座空城
  • 他的看法在大部分公司都是对的，毕竟造火箭的公司不多，CURD 能不能卖钱还是要靠业务。要是我的话，就想想怎么从代码提取出文档。要么自己改个 parser ，扫一遍代码列出所有 service 和方法，按照固定格式输出，然后自己添点东西改成文档。

    要么找个开源的 LLM ，看看能不能改造集成让它给我生成文档。一般来说这种固定格式的文档，你自己写个服务调个开源的 LLM ，调一下模型或者搞提示词应该能很好的解决。甚至你也可以反过来用文档生成代码。都搞定了就可以准备跳槽了。这次再跳至少不会说什么 “公司技术栈陈旧，没有学习机会” 了。
  • 2024/5/29 17:19:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题