程序员职业发展中要避免的11大误区

前言

程序员从初入职场到成长为技术骨干,甚至进入管理层的过程,类似于游戏中的“打怪升级”。然而,大多数程序员在职业发展的过程中都会遇到相似的“怪”(误区)。今天,我将盘点程序员常见的误区,并探讨相应的解决方案。

误区

1、同时追求太多技术

许多程序员热衷于追逐新兴技术,但往往在尚未深入掌握一项技术时,便急于学习下一项。随着技术的层出不穷,这种做法容易导致顾此失彼,技术广度虽然扩展了,却缺乏足够的深度,最终削弱了自身的竞争力。一些 Java 程序员在工作中以 Java 为主,但看到 Go 语言流行后便急于学习,随后又转向 Python,结果导致对每种语言的掌握都停留在浅层。

应对策略:技术的关键在于精通而非多而不精。选择一个适合的核心技术栈,集中精力深入研究,远比浅尝辄止更具长远价值。工作中,我曾亲眼目睹一位名校毕业的同事在短短一晚熟悉了对他全新的编程语言 Swift,次日便开始项目开发,并在几天内完成了一个完整 iOS 软件的开发与提交。这说明技术的底层原理往往是相通的,一旦深入掌握了一种技术,再学习其他技术将事半功倍,从而更快提升整体的技能水平。

2、轻视文档

许多程序员轻视文档,使用某项技术已久,却从未认真阅读过其官方文档。由于缺乏系统性的了解,他们在学习和应用过程中往往走了许多弯路而未察觉,导致大量时间浪费在本应看文档就可以避免的问题的排查上,效率低下,得不偿失。

应对策略:在学习一项新技术前,应先投入时间仔细阅读相关文档。与此同时,还应培养编写文档的好习惯,在进行方案设计时尽可能详尽,方便后续的维护。

3、忽视测试

许多程序员由于项目工期紧张、态度懈怠或对测试的重要性认识不足,而忽视了测试工作。这导致单元测试覆盖率不足,甚至缺失单元测试,项目自测不全面,大量缺陷被带到线上,造成严重后果。

应对策略:首先,必须重视单元测试。可以借助 AI 辅助生成测试代码并进行二次修改提高编写效率和体验。其次,项目自测阶段应确保全面覆盖,包括正常情况和边界条件测试,让问题尽早暴露和解决。团队管理者可以明确单元测试的覆盖率、提测前核心链路必须通过等要求,制定 Bug和故障数量相关的奖惩措施。

4、解决方案过于复杂

许多程序员由于经验不足,在设计技术方案时往往会使其过于复杂,导致项目工作量增加,且降低了系统的可扩展性和可维护性。这不仅为后续的维护工作带来了额外负担,也埋下了潜在隐患。正如所谓的“大道至简”,优秀的程序员能够将深奥的原理用通俗易懂的语言解释清楚,并在面对复杂问题时,设计出相对简洁的解决方案。

应对策略:遵循 KISS 原则,即“保持简洁”(Keep It Simple, Stupid),避免不必要的复杂性,保持方案的简洁性。当发现技术方案过于复杂时,可以尝试从不同角度思考,或与同事讨论,寻找更简单且易于维护的解决方案。团队管理者也应重视技术方案的评审工作,及时发现复杂设计并提供合理建议。

5、不主动寻求帮助

有些程序员初入新团队时,往往因为不好意思开口而不主动寻求帮助;也有一些程序员担心请求帮助会被同事认为能力不足;还有些人习惯独自研究问题。然而,如果某些问题没有及时寻求帮助,不仅会影响项目进度,还会加深个人的挫败感。

例如,在工作中,许多人常常遇到一些难以排查的“疑难杂症”,即使工作经验丰富的程序员,也可能经过长时间的分析找到根本原因。在这种情况下,及时向同事寻求帮助往往能够事半功倍,迅速找到解决方案,避免不必要的时间浪费。

应对策略:我们应积极调整心态,认识到“人无完人”的道理,学会接纳自己的不完美。面对问题时,首先要独立思考,接着可以尝试求助 AI,如果依然无法解决问题,再向同事求助。这样能既锻炼自身能力,又避免过度打扰同事。

6、忽视软技能

常见的软技能包括沟通表达能力、报告写作能力、时间管理能力、批判性思维能力和领导能力等。尽管许多程序员在编码方面表现出色,但往往在软技能上有所欠缺。有些人抱有偏见,认为只要技术过硬,其他能力便不重要。然而,事实证明,获得晋升的程序员往往不是技术最顶尖的,而是那些同时具备技术实力和软技能的人。随着职业发展,沟通、时间管理以及报告写作等软技能的重要性日益凸显。

此外,一些程序员凭借出色的写作和演讲能力积累了广泛的影响力,不仅对职业发展带来了显著帮助,甚至在知识付费领域取得了可观的收益。

应对策略:在提升编码能力的同时,注重培养沟通、汇报写作、时间管理等软技能,从而全面提高职场竞争力。

7、害怕遇到 Bug

许多程序员,尤其是初学者,往往对Bug和错误心存畏惧,因此在编写代码时显得过于谨慎。例如,一些代码本应借此机会进行重构,以提高其可读性和可扩展性,但由于害怕出错,程序员常常以“这是原本的设计”为借口,避免进行改进。此外,在日常开发中,遇到 Bug 是不可避免的情况。然而,一些人往往不加思考,直接通过搜索引擎寻找解决方案,草草修复问题后便不再深入探究。

应对策略:每一个 Bug 都是学习和成长的好机会。如果我们能够对出现的 Bug 或错误进行反思,深入探讨其根本原因,便能在技术水平上迈上新的台阶。

8、深陷舒适区停滞不前

技术日新月异,稍有懈怠,技术栈就可能迅速过时。作为面试官,我深切感受到,尽管拥有相同的工作年限,有些候选人却早已停止“成长”。一些人在工作 5 年后,仍能持续学习、反思,并紧跟技术发展的步伐;而另一些人虽然同样具备 5 年的工作经验,却未见明显进步。例如,部分 Java 程序员的技术栈依旧停留在过去流行的 JDBC、JSP、Struts 和 Hibernate 上,而对如今广泛使用的分布式中间件知之甚少。

此外,面对问题的解决方式也在发生变化。过去,程序员习惯通过 Google 或 StackOverflow 查找答案,或向同事求助。而如今,随着大语言模型的普及,越来越多的开发者借助 AI 工具来辅助编程与学习。例如,许多人已经在使用 Cursor、通义灵码等智能编码工具来提升效率,甚至能够快速借助 AI 分析并解决问题。然而,仍有部分开发者尚未尝试这些工具,依旧依赖传统搜索引擎或同事的帮助。

如今,许多程序员已经从传统的搜索引擎转向大语言模型平台(如 ChatGPT、通义千问、文心一言、讯飞星火)和 AI 搜索平台(如天工AI、Perplexity、秘塔AI搜索、Felo)等,以更高效地解决问题,但仍有一部分人对此缺乏主动探索的意识。

应对策略:积极利用人工智能工具高效学习与解决问题。关注行业内知名的技术公众号、播客、论坛,紧跟技术发展的最新趋势,培养持续学习和终身学习的习惯。

9、忽视休息

研究表明,成年人在不休息的情况下,通常只能集中注意力约 20 至 50 分钟。如果在工作过程中缺乏适当的休息,效率不仅不会提高,反而会下降。许多程序员习惯于熬夜,如果晚上未能得到充分休息,次日的工作表现也会因此受到影响。

应对策略:建议采用定期休息的方式,如在电脑上安装番茄时钟软件,运用番茄工作法进行时间管理,即在一段高效工作后安排短暂休息。此外,确保夜间有充足的睡眠,并适当进行午休,以维持最佳的工作状态。

10、忽视人际关系

许多程序员性格内向,不善交际,往往避免参与团建、技术大会,也不主动接触用户。然而,这种行为可能让他们错失重要机会,例如让领导了解自身能力、赢得合作方信任、深入了解用户需求以及拓展职业发展的机会。一些同事擅长向上管理,能够更好地争取领导支持,成果更容易得到认可;另一些同事则善于与合作方建立良好关系,使合作伙伴愿意付出额外努力,推动项目成功;还有人通过主动进行用户访谈,获得更真实的反馈,帮助产品迭代优化;也有同事擅长分享和写作,在公司内外建立了巨大的技术影响力,进而获得更多发展机会。

应对策略:积极“走出去”,让更多人注意到你的价值。主动进行向上管理,与合作方建立良好关系,积极与用户沟通获取真实反馈,广泛分享经验,逐步树立个人影响力。

11、冒名顶替综合征

冒名顶替综合征(Impostor Syndrome)是一种心理现象,指个体在取得成就或身居成功位置时,难以认同自身的成就,常常觉得自己不配享有当前的地位或荣誉,担心他人会识破自己的“伪装”。尽管外界对其能力和成就给予高度认可,经历者仍然对自己的能力产生怀疑,并伴有不安与焦虑的情绪。

许多程序员因受家庭教育或个人性格的影响,尽管已经非常优秀,仍可能陷入自我怀疑,表现出完美主义倾向或归因偏差。这种情况在他们经历工作挫折时尤为明显,容易引发“冒名顶替综合征”。例如,某些技术水平较高的程序员,尽管在工作中屡获奖项和晋升,遇到特别困难的项目时,仍可能因与以往经历的反差而怀疑自己的能力。

应对策略:接受自己的不完美,设定切实可行的目标,避免过度追求完美;对自己的荣誉进行正确地归因;加强与领导的沟通,及时获得客观的反馈。

总结

在职业生涯中,程序员常常会遇到各类误区,深入了解这些误区及其应对方法至关重要。希望本文能够为你的职业成长提供一些有益的参考。

 

来源:https://www.cioage.com/article/800059.html

发布于

程序的“通用性”和“过度设计”困境

在软件工程的实际操作中,我常常遇到这样一种现象:本可以用简单代码解决的问题,却因为设计者过分关注“通用性”、“可维护性”和“可扩展性”而变得不必要地复杂,难以理解。

他们的思维方式是这样的:“这段代码未来可能会在更多场景中使用,所以我现在应该考虑它的可扩展性。”结果,他们在代码中加入了各种“框架结构”,以便在未来有新需求时,无需修改就能在新的地方使用。

“通用性”的价值与误区

作者并不否认“通用性”的价值,我的一些程序也具有很高的通用性。然而,很多人所谓的“通用性”实际上适得其反,这种现象通常被称为 “过度设计” 。关于过度设计,有一个有趣的故事:

传说在上世纪60年代美国和俄罗斯的“太空竞赛”期间,NASA 遇到了一个严重的技术问题:宇航员需要一支能在外太空真空环境中书写的笔。最终,NASA 花费了150万美元开发了这样一支笔。不幸的是,这种笔在市场上并不畅销。

俄罗斯人也面临同样的问题,他们则用了铅笔。

虽然这个故事是虚构的,但它具备了伊索寓言的力量。现在让我们看看软件行业,可能会发现:

代码需要“重用”的场合比您想象的要少得多

许多人在写程序时,连“当前异常”都处理不好,却关注“未来的需求”。他们总是想象别人会重用这段代码。然而,实际上,由于设计过于复杂,理解这些设计所需的心智努力已经超过了从头开始的成本。因此,大多数人根本不会使用他们的代码,而是重新写一个。有些人最终会发现自己甚至看不下去之前写的代码,更愿意删除它并重新开始,而不是谈论重用。

继续阅读程序的“通用性”和“过度设计”困境

发布于

什么是远程物联网设备管理

工业4.0的兴起和连接设备的指数级增长,导致了远程物联网设备管理解决方案的出现。物联网可以看作是一个生态系统,可以通过蓝牙、WiFi、LoRa等无线网络连接多个智能设备。信标、传感器和跟踪器等智能设备很常见,每个设备都分配有唯一的IP地址用于识别。连接设备管理后,无需人工干预,自动采集和传输大量数据,辅助监控和故障排除。本文将深入探讨有关远程物联网设备管理的定义,及其他内容。

什么是远程物联网设备管理?

远程物联网设备管理是指从中央位置或平台监视、管理和控制联网设备。远程管理允许管理员通过基于云的工具安全地管理整个分布式物联网资产组,而不必在物理上靠近设备来配置设置或解决问题。

远程物联网设备管理对于大规模高效操作分散的连接设备是必不可少的。基本系统提供监控和远程控制,而高级平台则利用遥测数据分析进行深入的监督。总而言之,预先诊断即将发生的问题的能力非常有价值。

继续阅读什么是远程物联网设备管理

发布于

IT经理把项目带崩是因为这几点没做好

分享一个来自码哥工作中遇到的时间紧任务重,对系统不熟悉,没有产品文档,目标就是将原有系统改造成客户本地部署运行的多重困难跨团队协作项目管理差点带崩的经历。

通过该经历重点在于给大家分享如何避免项目搞砸,以及一个项目初期、中期、收尾阶段需要做的工作重点和注意事项,如何管理项目规避风险。

项目背景

项目的目标是将公司 saas 团队的供应链金融系统移植到客户独立部署,主要有以下几个风险和难点。

  • 团队内的人包括我并不熟悉该系统的业务流和系统的代码,难以分析项目的风险和改造点。
  • 干系人分析不足,没有将熟悉该系统的人引入,导致风险无法识别,进度缓慢。
  • 时间和人力明显不足:人力极致压榨。
  • 跨多个团队协作:开发该系统的团队并没有参与此次迁移工作。
  • 原系统与公司内部的接口交互需要全部通过 Http 来实现:原有的系统架构并不适用直接迁移到客户部署,部分接口能力是调用公司的其他团队实现,比如 AI 识别或用到 MQ 通信,通过 Dubbo 或者 HTTP 调用其他团队接口实现逻辑,需要统一改造成通过 Http 调用公司开放的接口实现。

除此之外,该 saas 系统由于原先开发人员的技术能力较弱,以及历史渊源,框架设计不合理,可读性和可维护性比较弱的情况下,如何更好的与原维护者沟通也是一大难题。

因为技术人会容易看不上别人的代码和设计,尤其是架构确实有明显不足的时候。

打开项目代码发现这是一个披着微服务外衣的大单体巨石服务。一边骂别人系统垃圾,一边还要请求人家帮助的事情需要合理手段解决。

最终发现拆了一堆的服务,可是实际上业务逻辑和系统的压力全都集中在 web-service 上。

至于拆出来的微服务,只干了一件事:myabtis 作为 ORM 框架操作数据库,也不懂这个项目的原开发和架构是怎么想的,单一职责不是这样理解的,大兄弟。

真的是「黛玉骑鬼火,该强的强,该弱的弱」。

遇到这种情况,我们一定要秉着谦虚的态度,因为还要请教他们解答项目如何迁移,需要我们想方设法用彩虹屁夸他们,让他们觉得受到尊重,虽然很反人类,可这是我们的必修课:

  1. “大佬,你们这块的设计思路是基于什么考虑呢,能这么平稳的运行一定有道理”
  2. 这块的设计真棒,学到了很多。

总之一定要一顿夸,切不可用技术人的视角把实际情况说出来,要是指出系统懂得各个不是,各种技术垃圾,你觉得别人还会帮你么?

继续阅读IT经理把项目带崩是因为这几点没做好

发布于

通过滴滴技术博客:探寻造成此次P0故障的真正原因

2023年11月27日晚至2023年11月28日早晨,滴滴发生了长达12小时的P0级故障,导致滴滴核心业务都受到了影响,比如不显示定位无法打车、滴滴单车无法扫码等问题,期间滴滴进行了多次致歉。

来源:https://weibo.com/2838754010/NuMAAaUEl

目前问题故障已经恢复,根据最新的消息得知造成此次事故的原因,是由于升级K8S 集群导致。

1. 集群体量大

最大集群规模已经远远超出了社区推荐的5千个 node 上限,有问题的爆炸半径大。

2. 版本升级跨度大

直接从1.12 升级到了1.20,跨越多个版本,有可能存在api不兼容的问题。

3. 升级方式应该选择了原地升级

虽然滴滴有能力基于K8S二次开发,但是由于版本跨度较大,细节点较多,原地升级风险我觉得比替换升级大不少。

比如集群版本已经升级为1.20,但是Node节点的kubelet的版本还是 1.12,如果api不兼容,那么这个影响是非常大的,集群回滚又没有那么快。

至于为什么采用原地升级方案,估计还有很多细节我们不得而知,但是此种方式确实有点激进,船大不好掉头。

 

来源:https://www.51cto.com/article/775071.html

发布于