社区
非技术区
帖子详情
老板说懂业务逻辑比只会编程的人工资高????????????
oneoneone
2006-07-26 08:09:18
老板说 业务逻辑熟的的人很难招到,
会编程的人的人漫天飞
...全文
6293
141
打赏
收藏
老板说懂业务逻辑比只会编程的人工资高????????????
老板说 业务逻辑熟的的人很难招到, 会编程的人的人漫天飞
复制链接
扫一扫
分享
举报
写回复
配置赞助广告
用AI写文章
141 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
jacklondon
2006-08-14
打赏
举报
回复
另外技术分析员由程序员兼任也有很大问题。同一个技术问题,往往有几种不同的技术实现,选择哪一种,往往需要技术人员有较高的技术水平、丰富的经验。
如果项目中由一两个技术很高的技术分析员,可以选择比较好的技术实现路线。否则可能会选上不好的技术路线,导致项目周期长、系统复杂度大、技术问题很多之类的。
只不过在国内,这个问题尚未引起足够的重视。
jacklondon
2006-08-11
打赏
举报
回复
一般来说,系统分析员分为业务分析员和技术分析员,国内很多公司只有业务分析员。技术分析员由程序员自己兼任搞定。
系统分析员工资一般都程序员高。
国内的 IT 项目水平低,很多项目做完后都发现偏离客户需求。正如作文考试,偏题,不管你写得多么漂亮,都是零分。因为国内很少能够有业务分析员能够把客户的真实需求分析清楚,俗话说,物以稀为贵,我觉得很正常。
tgq1981
2006-08-11
打赏
举报
回复
编程你都学会了,难到还不能把业务搞懂,花点时间,用点心思,忍一时之气,最终超过那个只懂逻辑的人,让他失业去。
呵呵.......
只抱怨是没有用的。老板大多是不懂技术的,所以他们一般都站在业务那一边。你的程序再怎么优化,他们都不会明白。
cime63
2006-08-11
打赏
举报
回复
zhouhongyun(最终幻想) ( ) 信誉:99 2006-08-11 16:32:00 得分: 0
假如你现在要开发一套酒店管理系统,你是不是有必要了解酒店的业务,当然有必要,但你必须在很短的时间内了解酒店的业务,最多一两个月吧,一两个月就能掌握的东西能称为高深的东西吗??当你做下一个系统的时候,也许是一个完全陌生的领域,比如GIS系统,或者OA系统,但它们的业务一般的人也可以在很短的时间内掌握,所以业务对程序员来说算不上什么,可以说不值一提,因为程序员更多的时候不是对业务的担心,而是对开发能力的担心,害怕遇到技术上的问题,业务上不懂的可以问客户,技术上不懂的问谁去??对程序员来说,业务很少有通用性,但技术有通用性,所以把时间花在业务上未必值得,学一门技术要花五六年才能上路,了解一个业务短短两个星期就可以搞定,所以我很同意楼上一些人的看法,业务不过是某些不懂编程的人太高自己的筹码,其实狗屁不值
==================================================
OA一般没有太难难度,但GIS却绝不容易
涉及到太多的东西,地理上的,数学上的
粉红色的火烈鸟
2006-08-11
打赏
举报
回复
至于你所说的软件本身的业务逻辑,写代码是高手的基本上在软件业务逻辑上也是高手,这是顺理成章的事,所以楼主的担心根本就是多余
粉红色的火烈鸟
2006-08-11
打赏
举报
回复
假如你现在要开发一套酒店管理系统,你是不是有必要了解酒店的业务,当然有必要,但你必须在很短的时间内了解酒店的业务,最多一两个月吧,一两个月就能掌握的东西能称为高深的东西吗??当你做下一个系统的时候,也许是一个完全陌生的领域,比如GIS系统,或者OA系统,但它们的业务一般的人也可以在很短的时间内掌握,所以业务对程序员来说算不上什么,可以说不值一提,因为程序员更多的时候不是对业务的担心,而是对开发能力的担心,害怕遇到技术上的问题,业务上不懂的可以问客户,技术上不懂的问谁去??对程序员来说,业务很少有通用性,但技术有通用性,所以把时间花在业务上未必值得,学一门技术要花五六年才能上路,了解一个业务短短两个星期就可以搞定,所以我很同意楼上一些人的看法,业务不过是某些不懂编程的人太高自己的筹码,其实狗屁不值
粉红色的火烈鸟
2006-08-10
打赏
举报
回复
你这是强辩,因为写DELPHI的人面对的客户是一般程序员,所以对于他们来说,程序员如何使用DELPHI完成编程的逻辑就是业务逻辑,而一般程序员面对的客户是企业客户,所要求的是实现企业管理层面的业务逻辑
-----如果你说的业务逻辑指的这些的话,试问哪个上了路的程序员不懂业务逻辑??这还有讨论的必要吗,楼主所说的根本不是指的这种业务逻辑
zhmt
2006-08-10
打赏
举报
回复
up!..............mark!
raze911
2006-08-10
打赏
举报
回复
如果你说的业务逻辑指的这些的话,试问哪个上了路的程序员不懂业务逻辑??这还有讨论的必要吗,楼主所说的根本不是指的这种业务逻辑
===
业务逻辑当然是相对而言的,是相对于客户而言的,不同的客户有不同概念上的业务逻辑
你面对的客户是程序员,那么你就必须了解程序员思考与处理问题的角度与逻辑
你面对的客户是企业用户,那么你就必须了解企业用户思考与处理问题的角度与逻辑
你不能在面对企业用户时以面对程序员的角度去了解企业用户要什么,也就是说“不懂业务逻辑”这句话永远是相对而言的,是相对你将要面对的客户而言的,如果你面对的是程序员,就不需要懂得企业用户概念上的业务逻辑,但必须懂得程序员概念上的业务逻辑
程序员开发一套程序不就是在做业务生产产品吗?所以程序员本身的工作也是有业务逻辑的,只不过与企业用户的业务逻辑在概念与范围上不同而已
raze911
2006-08-09
打赏
举报
回复
-----要你操心??我写个驱动程序也要懂某个工厂的业务逻辑吗??anders写delphi的时候需要懂银行的业务逻辑吗??
=========================
你这是强辩,因为写DELPHI的人面对的客户是一般程序员,所以对于他们来说,程序员如何使用DELPHI完成编程的逻辑就是业务逻辑,而一般程序员面对的客户是企业客户,所要求的是实现企业管理层面的业务逻辑
假如anders完全不懂得一个程序员在编程时需要什么,那么他是不可能设计出DELPHI来的
很简单,我可以百分百肯定DELPHI的设计文档也包括了DELPHI的框架是如何的、程序员如何与DELPHI交互、DELPHI的模块分割、适应平台等等各类极详细且有层次的需求文档
从全行业的范围来说,代码员的平均收入必然是比设计师一级的程序员要低的,因为在供应量上,代码员的数量远远超过设计师,当然这只是说平均收入水平,不排除较少数的代码员比设计师的收入高
will123
2006-08-02
打赏
举报
回复
谢谢各位的答案,让我学到东西了。。谢谢
粉红色的火烈鸟
2006-07-31
打赏
举报
回复
只会编程的人 不懂业务逻辑 又 如何编码?
-----要你操心??我写个驱动程序也要懂某个工厂的业务逻辑吗??anders写delphi的时候需要懂银行的业务逻辑吗??quake的作者写quake的时候是不是也要学业务逻辑呀??你要去搞什么业务逻辑那是你的事,没必要让别的程序员陪太子读书,我不懂业务逻辑也不妨碍我拿高薪,anders不懂业务逻辑也不妨碍盖次亲自请他。
十分钟年华老去
2006-07-31
打赏
举报
回复
写代码的是工人,懂设计的才是工程师,看看盖楼的就知道了
xiangbo520
2006-07-30
打赏
举报
回复
程序编来是做什么的?
处理业务逻辑的。
你程序写的再好,处理过程不对,还不是白搭。
musicsoul
2006-07-30
打赏
举报
回复
事实是这样的
jnch
2006-07-30
打赏
举报
回复
程序员不能只看代码,还应该多学点别的
jspxnet
2006-07-29
打赏
举报
回复
业务逻辑熟的的人来软件公司做什么?把业务逻辑告诉你然后等你叫走人。疯的才干。
会编程的人的人漫天飞,编得好的就几个。
yinxu
2006-07-28
打赏
举报
回复
中国自古以来就不重视技术,会盖房子的叫瓦匠,会做家具的叫木匠,会打铁的叫铁匠,会画画的叫画匠...似乎都只是一个匠而且,而不会成为师,其社会地位相当低下.偶尔弄出什么新的发明,也被称之为奇巧淫技,难登大雅之堂.所以中国没有文艺复兴,没有工业革命.历史进程到了现代,做技术的也常常带着"员"、"工"的帽子.
社会要求既懂技术又懂业务的人,其根本原因是为了降低成本.而真正既懂技术又懂业务的又有几人?大都不过是半生不熟罢了,技术没有学好,业务也没有学精,设计出来的软件漏洞百出,修修补补,不堪其苦.
事实上相互的人工合作是很重要的,懂业务的人从业务的角度阐述问题,懂技术的人再转换成相应的实现,这样两者兼顾,有什么不好呢!
AK47CN
2006-07-28
打赏
举报
回复
再说一句,业务逻辑/业务是表层的东西,
编程水平、系统分析设计才是内在的根本;
如果你离开了你现在的这个公司,跳槽到另外一个不同业务的公司,
那么你所学的这个公司的业务逻辑对于你来说,
就形同虚设,没有什么用处了;
但是你的编程技能、系统设计水平则可以应付任何业务下的程序实现。
现在该清楚谁才是根本吧?你的技术水平!
不要舍本逐末!!!
HelloWorld_GHH
2006-07-28
打赏
举报
回复
好的程序员,为了编写一个项目,可以非常快地熟悉相应的业务。而且不仅是熟悉,还能发现“对业务熟”的人发现不了的问题,并且能够归纳总结,形成业务人员想到的、没有想到的、或者是想了一点点却没有继续想下去的想法。
加载更多回复(121)
LLM在RTL验证中的应用:GRPO-SMu方法解析
硬件验证是数字芯片设计中的关键环节,传统方法如手工测试和约束随机验证(CRV)面临效率与覆盖率的双重挑战。随着大语言模型(LLM)技术的发展,其在代码生成领域的潜力为自动化验证提供了新思路。RTL验证具有时序敏感性和并发处理的特殊性,需要模型不仅能理解设计意图,还需逆向思考故障模式。GRPO-SMu方法通过两阶段验证框架和状态突变强化学习,显著提升了验证效率。该方法在测试计划生成与测试平台执行解耦的基础上,引入树状突变机制和动态奖励模型,有效解决了稀疏奖励问题。实验表明,GRPO-SMu使7B小模型超越32
GRPO-SMu:AI驱动的硬件验证技术创新与实践
硬件验证是确保芯片功能正确性的关键技术,随着半导体设计复杂度提升,传统验证方法面临覆盖率不足和效率低下的挑战。现代验证技术结合强化学习与大型语言模型(LLM),通过任务分解和智能测试生成显著提升验证效率。GRPO-SMu创新性地采用两阶段框架,首先生成可解释的测试计划,再通过改进的PPO算法实现测试用例自动生成。该技术在时序电路验证中展现出82.4%的分支覆盖率和8.7用例/秒的生成速度,较传统方法提升显著。典型应用场景包括RISC-V核心验证和DDR控制器测试,其树状突变策略和分层奖励设计为解决状态空间爆
LLM在RTL验证中的测试计划生成优化实践
硬件验证是芯片设计流程中确保功能正确性的关键环节,其中RTL(寄存器传输级)验证尤为重要。传统方法依赖工程师手动编写测试计划,耗时且易遗漏边缘情况。随着大语言模型(LLM)在代码生成领域的突破,其在硬件验证中的应用也展现出潜力。然而,RTL描述的时序概念与软件
编程
范式存在显著差异,导致通用LLM直接应用于测试计划生成效果有限。本文介绍了一种创新的两阶段框架,结合GRPO-SMu强化学习方法,显著提升了测试计划的生成质量和效率。该方案在GPU子模块验证等实际工程场景中,相比传统方法可减少约3人月的工作量,为现
202609212009.7z.004 4/8 unity
202609212009.7z.004 4/8 unity
20260920828.7z.004
20260920828.7z.004
非技术区
23,404
社区成员
70,506
社区内容
发帖
与我相关
我的任务
非技术区
Java 非技术区
复制链接
扫一扫
分享
社区描述
Java 非技术区
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章