社区
非技术区
帖子详情
业务,技术都在变化,你选择跟随哪一个?
老紫竹
2012-08-10 01:10:18
个人建议:
如果你新工作,多关注各种技术,多尝试一下
如果你已经算有经验的,多关注某方面的业务,别随便换行业。
限定词不同,大家有兴趣就发表一下自己的看法吧。
...全文
427
15
打赏
收藏
业务,技术都在变化,你选择跟随哪一个?
个人建议: 如果你新工作,多关注各种技术,多尝试一下 如果你已经算有经验的,多关注某方面的业务,别随便换行业。 限定词不同,大家有兴趣就发表一下自己的看法吧。
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
15 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
朗晴
2012-08-20
打赏
举报
回复
自古成功在尝试。
Ivan_2000
2012-08-20
打赏
举报
回复
同意竹子所说的,工作久了吃的都是行业知识。换行就得重新排队卖包子,有人能排到有人排不到,风险成本都挺高。
技术还得耍,好的东西还要及时尝尝鲜。
jackson_fighting
2012-08-11
打赏
举报
回复
先技术 后业务
减肥啊啊啊啊啊
2012-08-11
打赏
举报
回复
以后可能会更关注业务吧、
其实经验大部分都是跟业务熟练度挂钩的、
业务熟练、用什么技术开发出来都一样、
做完的东西总是要走产品流程的、
诶、这倆也确实不好分开、
h70614959
2012-08-11
打赏
举报
回复
技术和业务两者是相辅相成的关系,二者都是相互参杂在前一起,无法分离~~~
哎~对于与初学者当然偏重技术,偏轻业务~~,慢慢的才开始有了业务的概念。
是一个过渡的阶段。
lz和ls 的都是技术前辈~,都给意见~~
MiceRice
2012-08-11
打赏
举报
回复
1
确实有时候很纠结,技术人员内心往往喜欢搞技术,但其实搞业务(不是指市场或商务)从收入来说会比搞技术的高,而且更容易受用户所尊敬;而纯搞技术的,往往是负责挨骂的,做好了是业务设计好,做烂了是系统开发烂;进入运维期后往往更甚:系统正常是应该的,不会有功劳一说,系统如果瓢了那就全是你的问题了。
此外,所谓架构师,往往是需要对业务有相当程度掌握的,否则应用架构就会很虚;所以绝大多数企业的架构师基本上只有领域架构师,不太可能培养基础技术体系的架构师。
所以我觉得啊,在绝大多数企业里,想要能干出点成绩来,两手都得抓。
brightyq
2012-08-10
打赏
举报
回复
兴趣也比较重要了。
brightyq
2012-08-10
打赏
举报
回复
兴趣也比较重要了。
-AJ-
2012-08-10
打赏
举报
回复
想把两者完全分开看,挺难的。
业务需要技术的支持,而技术为业务服务。
就我个人而言,比较花心,两个都跟,有时37开,有时46开,对技术关注的比业务稍多一些。尤其是web这一块,每年都有新东西,肯定不会都拿来用,不过了解一下还是好的。
zqfddqr
2012-08-10
打赏
举报
回复
老紫竹 有段时间看不到了啊. 严重同意楼主观点 , 但是作为一个程序员注定是要追逐新的技术的,老程序员追追相关的就好了吧.
朗晴
2012-08-10
打赏
举报
回复
我选技术。
我来了,分在哪儿
Cactus_hxk
2012-08-10
打赏
举报
回复
个人觉得要涉猎面广,去学习一种新的技术,未必要弄得滚瓜烂熟,主要要知道他是干什么啊,他能帮你实现什么要的事!然后记住它的名字!等在开发的过程中遇到那样的业务需求,就可以拿来用来了!
Jeff-HT-Lee
2012-08-10
打赏
举报
回复
[Quote=引用 2 楼 的回复:]
作为技术人员 技术是基础,有了技术才是业务。
否则你拿什么吃饭?
[/Quote]
技术再牛逼,做出一个客户不需要的东西,你也挣不到钱。相反,你的产品采用的技术可能落后点,但十分符合客户的需求,钱照样挣。
加油馒头
2012-08-10
打赏
举报
回复
作为技术人员 技术是基础,有了技术才是业务。
否则你拿什么吃饭?
libei_march
2012-08-10
打赏
举报
回复
1
我应该算LZ描述的第一条吧,现在正在充实中...
解读软件架构的复杂性:
业务
和
技术
的双重挑战
本文探讨了软件架构中的复杂性及其对
业务
成功的影响。随着
技术
和
业务
环境的快速
变化
,架构师面临着管理日益增加的复杂性挑战。文章分析了影响架构复杂性的关键因素,如
技术
选择
、团队协作和需求变更,并提出了一系列应对策略,包括明确的架构决策流程和持续的架构评估。通过强调沟通与合作,架构师可以更有效地应对复杂性,从而为企业创造持久的价值。
职业规划(程序员)中
业务
型 和
技术
型 那个更重要?
不管是
业务
型还是
技术
型,适合自己才是最重要的。 职业规划对于每
一个
人来说都很重要,对于步入社会不久或者进入
一个
新行业时,很多人都会有困惑。 该如何规划自己的职业生涯呢? 之所以产生这种困惑的原因在于自身对于行业的掌握情况不足。 很多人都会想如何提高自己的薪资,因为想要提升自己,迷茫中的你或许会求教身边比自己水平更高的人,或许他们会给予你答案。 或许你常常听人说程序员分为
技术
性程序员 和
业务
型程序员。或许你的导师会告诉你,如果自己的
技术
很差,而且感觉学的慢,可以尝试做
业务
型程序员。----然而,这其
AI Agent到Agno框架
选择
:性能vs易用性vs生态,这是
一个
单选题吗?
说了这么多,不是要告诉大家什么框架好或者不好。在Agent框架的
选择
上,没有绝对的对错,只有适不适合你的
业务
场景。我建议你用三个维度来评估:第一,
业务
复杂度:你的Agent需要处理多少种场景?场景之间是否有明确边界?复杂
业务
需要更灵活的框架,简单
业务
可能需要更稳定的框架。第二,团队能力:你的团队对框架的理解程度如何?学习成本vs开发效率的权衡?不要
选择
超出团队能力太多的框架。第三,演进预期:你的
业务
会如何发展?框架能否支持
业务
的
变化
?选
一个
能随着
业务
一起成长的框架。
“
技术
总监面试,凭啥不问你
技术
细节?”
小A所在的公司因为最近
业务
快速发展,从外面新招了
一个
技术
总监,来带领整个
技术
开发团队以便跟上
业务
的需求。过了前两周了解熟悉的阶段,小A跟小B吐槽:怎么新来的总监只知道把
业务
部门提过来的需...
做好
技术
选型:用合适的
技术
做合适的事(干货满满)
根据实际
业务
管理的需要,对硬件、软件以及所要用到的
技术
进行规格的
选择
。狭义上的
技术
选型:团队决定选用哪种
技术
去解决
业务
问题。(某种语言、某种框架去开发项目)广义上的
技术
选型:泛指项目实施过程中的各种
技术
决策。(制定
技术
AB方案选其中一套,每个
技术
决策都是
技术
选型)在决定采纳某个
技术
之前,一定要做好调研,并尝试小规模引入,积累经验,经过验证后再大规模采用。总结一下
技术
选型的简单过程;解决了那些问题;是否达到了预期;哪些地方是值得改进的。如果落地失败,总结失败的原因是什么;总结如何防止再犯;
非技术区
23,408
社区成员
70,513
社区内容
发帖
与我相关
我的任务
非技术区
Java 非技术区
复制链接
扫一扫
分享
社区描述
Java 非技术区
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章