架构设计过程中的十点体会

在软件工程领域,任何脱离实际业务需求的架构设计都是一种不负责任的行为,甚至可以称之为”技术层面的形式主义”。这种设计倾向往往表现为过度追求技术新颖性、盲目采用复杂架构模式,或者为了架构而架构的设计理念。很多技术债务也是由于架构设计与业务需求脱节造成的。

多年的实践,经历了很多的项目和工程架构实现,整理了10点体会,可能不对,可能片面,都来自于过去的经验。

1.每个人都是凡人,无关职位

许多人从小就被灌输”要做一个听话的孩子”的观念,这种观念往往会在潜意识中形成对权威的畏惧心理。然而,随着互联网时代的到来,平等、开放、共享的互联网思维正在重塑新一代年轻人的思维方式。

事实上,在当今这个信息高度对称的时代,真正的权威往往更倾向于倾听不同的声音,因为创新往往来自于多元观点的碰撞。每个人都是独特的个体,都拥有值得分享的经验和见解。当我们能够以平等的姿态进行交流时,不仅能更好地表达自己的观点,也能从对话中获得更多启发。

在跨部门协作或多方参与的会议中,建立正确的角色认知至关重要。我们首先应当认识到,无论职位高低、资历深浅,所有参与者都是平等的,其次才是各自承担的特定角色——无论是负责技术架构的软件架构师、专注实现的工程师、把握产品方向的产品经理,还是统筹全局的项目经理。这种认知能够帮助我们摒弃职位带来的心理隔阂,营造开放、包容的讨论氛围。

继续阅读架构设计过程中的十点体会

发布于

微信纯血鸿蒙版正式上架华为应用商店!历时295天,鹅厂新开发团队曝光:超资深骨干与华为团队手搓代码,限量内测的原因找到了

鸿蒙原生版微信终于正式上线!

目前的版本号已经来到了1.0.3.42。从更新说明来看,这次功能上新之后,与普通版微信的使用体验几乎相差无几!(具体的几个差别我们将在下文展开讲讲

目前,基础通讯、社交、微信支付(以及大家特别关注的能否在春节期间领上红包)、公众号、小程序、视频号、直播等功能已经配齐,绝大多数的使用场景是cover上了!

鸿蒙原生版的微信界面是这样婶儿的:

由于微信产品的体量之大、功能之复杂,其鸿蒙原生版的开发与上架一直备受关注!

我们从去年10月8日公测版鸿蒙上架时,就一直在报道其进展,仍然觉得这是一个漫长的等待。

对于不太关注这方面的朋友,很多人的感受更可能是:

“原来还没正式上架?”

或是:

其实,鸿蒙原生版微信的开发实属不易,团队成员@客村小蒋将其工程量形容为“三峡大坝”。

鸿蒙系统采用了一套全新的技术框架和独特的ArkTS编程语言,这意味着微信团队要从头开始“手搓”应用。

“不过,对微信团队来说,学习新的编程语言,可能是整个适配工作中,最不算困难的事情之一。

在一个全新的平台上,做一款要支撑海量用户、高并发的通讯需求,同时有支付、小程序、视频平台等多个大功能模块的应用,还要满足极高频使用下的稳定性,是更大的挑战。”客村小蒋这样写道。

继续阅读微信纯血鸿蒙版正式上架华为应用商店!历时295天,鹅厂新开发团队曝光:超资深骨干与华为团队手搓代码,限量内测的原因找到了

发布于

世界上最完美的两个软件,太厉害了

今天给大家介绍两个软件,一个体现了人类在软件开发流程上的极致,另外一个则体现了程序员个体能力的巅峰。

一、航天飞机飞控软件

先来说第一个,航天飞机飞行控制软件,就是下图这个大家伙。

航天飞机重达120吨,还携带着2000吨的燃料。

它有四台硬件相同,软件也相同的计算机对发射过程进行精准控制,从几千个传感器中提取信息,每秒做出几百个决定,并且对每个决定进行投票。

第五台计算机,则运行着不同的软件,随时待命,准备替换其他发生故障的计算机。

这些计算机要确定什么时候对主发动机点火,什么时候下令固体火箭助推器点火,火箭姿态控制….

每次发射,软件都控制着价值40亿美元的设备,六名航天员的生命,以及国家的梦想。

这个软件不能崩溃,不能重启,最小的误差都不允许:一个三分之二秒的计时错误就会使航天飞机偏离航线近5公里。

洛克希德马丁公司的航天飞机小组实现了目标:软件几乎没有错误,接近完美。

软件的最后三个版本,每个版本(42万行代码)只有一个Bug。

最后的11个版本一共有17个错误,同等复杂度的商业程序有5000个。

这样的软件是如何炼成的呢?

答案是极为苛刻软件流程。

洛克希德马丁公司的航天飞机软件小组有260名员工,这些人创造了一种完全不同的开发文化。

没有超级明星程序员,开发软件的整个流程都是有意设计的,不依赖任何特定的人。

这个流程使得他们过上正常的生活,满足最后期限,交付完全符合其承诺的软件。

继续阅读世界上最完美的两个软件,太厉害了

发布于

代码审查,从Unix设计哲学到编码设计原则

随着研发团队规模的逐步扩大,新项目及新成员越来越多,如何做好 code review,把控研发人员的代码质量很是关键。

相信大部分团队,谈到 code review 时候就会面漏哀状:

“上线时间倒排,研发工期这么紧,连码代码的时间都不够了,你还要我CR?”

“上版的需求,这版就变了,代码生命周期太短,烂就烂吧,反正能用就行啦”

最近在团队内 CodeReview 过程中遇到一些案例,感觉挺有意思的,记录分享下来跟大家分享下,希望能给大家的工作带来一些借鉴和思考~

本文关键内容:
1、为什么要做CodeReview?
2、为什么大家要重视Review中的思考和总结最佳实践
3、几种代码变坏的根源情况
4、形成思考、总结很重要
5、从Unix设计哲学到编码设计原则
6、实践出真知

为什么技术人员包括 leader 都要做 code review

‘Talk Is Cheap, Show Me The Code’。

知易行难,知行合一更难。

嘴里要讲出来总是轻松,把别人讲过的话记住,组织一下语言,再讲出来,很容易。

绝知此事要躬行。设计理念你可能道听途说了一些,以为自己掌握了,但是你会做么?有能力去思考、改进自己当前的实践方式和实践中的代码细节么?不客气地说,很多人仅仅是知道并且认同了某个设计理念,进而产生了一种虚假的安心感—自己的技术并不差。但是,他根本没有去实践这些设计理念,甚至根本实践不了这些设计理念,从结果来说,他懂不懂这些道理/理念,有什么差别?变成了自欺欺人。

代码,是设计理念落地的地方,是技术的呈现和根本。同学们可以在 review 过程中做到落地沟通,不再是空对空的讨论,可以在实际问题中产生思考的碰撞,互相学习,大家都掌握团队里积累出来最好的实践方式!

当然,如果 leader 没时间写代码,仅仅是 review 代码,指出其他同学某些实践方式不好,要给出好的实践的意见,即使没亲手写代码,也是对最佳实践要有很多思考。

继续阅读代码审查,从Unix设计哲学到编码设计原则

发布于

程序员职业发展中要避免的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

发布于