我之前的文章 程序员你为什么这么累？ 中，我个人观点是加班原因是编码质量占了大部分因素，但是不少同学都不认为是代码质量导致的加班，都认为是不断的需求改动导致的加班。...我帮你做项目，写代码的时候也很想知道你TMD到底想要啥!” 有没有可能存在明确的、不再改动的需求呢？其实很难的。...有以下几点心得建议： 1 把代码写到最简单 最起码的要求，我之前一系列的文章说的就是这个。重要程度不需要再讲了。改1行简单代码和改10行复杂代码，工作量能一样吗？！...就像mvc一样，数据和视图要彻底的分离，否则业务代码里面有视图代码改起来是很痛苦的。 我的编码习惯 - 配置规范里面的举例，bean的定义就是第三者，就是为了解耦。如导出功能里面，也要有中介。...需求变更里面，我能控制是啥，我不能控制的是啥？我应该做好什么的准备来拥抱需求的变更？愿天下有永恒不变的需求 ? 图片来自网络，侵删。
还有就是在跟团队协作的时候，每个人都保持同一个风格进行代码书写，这样团队内部相互去看别人的代码的时候，就可以更容易的看懂。 ESLint实战小技巧全揭秘 那么ESLint如何去使用呢？...然后，我们要去项目的根目录里面手动创建一个.eslintrc文件，然后在里面敲入以下代码： { "extends": "standard" } 执行完以上步骤，我们就可以使用ESLint这个工具来校验项目里的代码...怎么在项目中预处理错误，eslint-loader来帮忙 我希望在项目开发的过程当中，每次修改代码，它都能够自动进行ESLint的检查。...里面就会马上报错，此刻我猜想terminal的内心活动应该是：“TMD，写的什么烂代码，天天写bug气得我每次脸都涨的通红”~~~ 幸运的是，机器是没有感情的，我们却可以嗨皮地立马定位到错误，然后把它改掉就可以了...写在最后 这就是ESLint，辅助编码规范的执行，有效控制项目代码的质量。更多操作指南可以前往官网了解，这里只提供在公司项目中快速上手ESLint的技巧，以及在实战项目中碰到的问题的解决方案。
无法打开 谷歌网上应用商店 --> 设置(齿轮) --> 我的扩展程序和应用 这个选项卡？该如何解决呢？操作如下图所示： ? 点击 我的扩展程序和应用 后出现的界面如下图所示： ?...经过多次点击重新加载后，依旧无法加载出来，该如何解决呢？这个可能是谷歌浏览器的小bug吧。 间接的解决方法如下所示： ? 点击后的界面如下图所示： ?...这样就可以启用或者禁用自己的扩展程序了，也可以选择 获取更多扩展程序。
—— 即使是这个项目的作者，我也要看我写的 README，才会想起来有这么一些功能。...如何设计测试防护网 是否能想到更好的设计来取代现有的方案？ 如何做一次有效的分析与评估？ 如何渐进式的重构系统？如何保持小的、快速的提交 怎样支持未来业务的可扩展？...即，多数团队成员都能快速上手 …… 重写的业务挑战 与重构不同的事，重写时的挑战主要是来自于梳理现有业务： 如何体系化的整理现有的业务？ 如何剔除已淘汰的业务？ 如何确保主干业务的完整性？...从这个手册快速的自然增长率（GitHub star 指标，没有经过大量宣传），并且已经在 Google 的相关关键字下（如系统重构、重构策略等）排名第一，我发现了人们缺少一份这样的指南和工具。...对于重构的方法论来说，实现上我们已经可以在市面上找到大量的相关书籍，只需要结合起来看就可以了： 《重构与模式》 《设计模式：可复用面向对象软件的基础》 《重构：改善既有代码的设计》 《领域驱动设计：软件核心复杂性应对之道
当时公司已经惨到只要改一个功能就得测试2周的悲惨境地，线上出一个故障技术团队更是惶惶不可终日。 我很快明白，如果搞不定这个工作，这次空降就基本算失败了。...在巨大的压力之下，我果断选择了DDD架构来应对这次大重构，原因也很简单：DDD特别适合应对复杂的业务场景，同时能有条不紊的推进重构全流程。...一方面，数字化时代为软件开发带来了新的挑战。如何实现业技融合，如何应对复杂多变的需求，如何防止架构和代码的腐化等问题，需要新的解决办法。而 DDD 正是顺应了时代的要求，日益普及起来。...这点在很多大厂招聘要求上也能看到，毕竟大厂软件更复杂，需求变化快，而且代码工程的规模也更大，这些都需要你深入了解和实践过 DDD。 那么，怎样跨越学习 DDD 的门槛，扫清落地 DDD 的障碍呢？...这里给大家分享一张Thoughtworks 首席架构咨询师钟敬梳理的「DDD 学习」知识地图，内容出自于《手把手教你落地 DDD》专栏，你可以跟着这个“套路“建模型、写代码，拾级而上，循序渐进地掌握 DDD
这可能导致开发者需要频繁修改代码，而没有足够的时间来重构和优化代码质量。 解决办法： ▶︎ 加强需求分析和明确：与客户或项目经理密切合作，确保需求被充分分析和明确。...这样可以应对可能的变更，减少时间压力。 03自我驱动力 尽管开发者知道代码整洁和代码质量的重要性，但他们可能缺乏自我驱动力来主动提高自己的编码水平。他们可能更关注完成任务而忽略了代码质量。...可以定期进行代码评审会议，让开发者分享自己的代码，并接受其他开发者的评审和建议。 ▶︎ 提供挑战和机会：给开发者提供挑战和机会，让他们参与复杂和有挑战性的项目。...，我直截了当说道：“这个项目整体没用规范，他可能都看不懂，我更看不懂”，后面还是勉强上线了，但问题较多，我的绩效一塌糊涂。我就在思考如何高效地开发代码和定位问题？并在我所在的这个项目中快速实施。...▶︎ “屎山一样的代码”我不可能一点点修复规范问题，有没有合适的工具可以提醒你呢，哪里问题较多，在我用了多个工具之后，我发现 CheckStyle 是我用过最好的代码规范检查工具，里面用了 sun 的规范
这可能导致开发者需要频繁修改代码，而没有足够的时间来重构和优化代码质量。 解决办法： ▶︎ 加强需求分析和明确：与客户或项目经理密切合作，确保需求被充分分析和明确。...这样可以应对可能的变更，减少时间压力。 03 自我驱动力 尽管开发者知道代码整洁和代码质量的重要性，但他们可能缺乏自我驱动力来主动提高自己的编码水平。他们可能更关注完成任务而忽略了代码质量。...可以定期进行代码评审会议，让开发者分享自己的代码，并接受其他开发者的评审和建议。 ▶︎ 提供挑战和机会：给开发者提供挑战和机会，让他们参与复杂和有挑战性的项目。...，我直截了当说道：“这个项目整体没用规范，他可能都看不懂，我更看不懂”，后面还是勉强上线了，但问题较多，我的绩效一塌糊涂。我就在思考如何高效地开发代码和定位问题？并在我所在的这个项目中快速实施。...▶︎ “屎山一样的代码”我不可能一点点修复规范问题，有没有合适的工具可以提醒你呢，哪里问题较多，在我用了多个工具之后，我发现 CheckStyle 是我用过最好的代码规范检查工具，里面用了 sun 的规范
编码阶段：在编码阶段，我会根据设计阶段的方案来实现具体的代码，确保代码编写规范、符合最佳实践，同时会进行适当的注释和文档编写。...以上是我编写代码时特别注意的流程，这些流程有助于提高代码质量、减少缺陷、提高效率、保证长期稳定运行。 二、你在工作过程中踩过哪些坑？你是如何处理的呢？...在工作中，我曾经踩过一些坑，包括以下几点： 不良的代码设计：在早期的工作中，我曾经犯过一些设计上的错误，导致代码难以维护和扩展。我通过重构代码、加强设计、与其他开发者讨论等方式来解决这些问题。...未考虑性能问题：在编写代码时，我曾经没有考虑到性能问题，导致代码运行缓慢，影响了用户体验。我通过优化算法、重构代码、使用缓存等方式来提高性能。...以上是我曾经踩过的坑，通过不断学习和总结经验教训，我逐渐提高了自己的技能水平和代码质量，同时也更好地应对了工作中的各种挑战。 三、结合自身工作经验，分享一下程序员有哪些要避免的坑吧。
1 如何从普通工程师成长为资深工程师？ InfoQ：您当初为什么会选择后端研发这个职业方向？可以分享一下您的技术成长经历吗？ 周正杭：我的职业选择其实与学校期间所学的方向、擅长的技术有关。...在这期间，我对复杂的业务流程、高并发处理，以及流量激增的应对方式产生了浓厚的兴趣，并在接下来的近十年时间中一直专注于后端研发的工作。 InfoQ：您是如何一步步地从普通工程师成长为资深工程师的呢？...我们在看书时也可以从目录的标题看起，目录的编排路径一定是由浅入深的技术介绍。 InfoQ：有用户提问，重构代码要如何打开思路？...周正杭：我们首先要确定驱动代码重构的原因，以及代码重构后能达成的结果。...对于十年来一直保持 Spring MVC 单体应用基础架构的公司而言，代码复杂度不言而喻，业务逻辑全部都在一个服务节点内，那么这种情况下重构是必然的。
那么在这个上下文中来谈要不要单元测试，我们就可以很有根据了，而不是“开发爽了就用，不爽就不用”这样含糊的答案： 如果你说我的业务部门不需要频繁上线，并且我有足够的人力来覆盖手工测试，那你可以不用单元测试...如果你说我不在意代码腐化，并且我也不做重构，那你可以不用单元测试 如果你说我不在意代码质量，好几个没有测试保护的 if-else 裸奔也不在话下，脑不好还做什么程序员，那你可以不用单元测试 如果你说我确有快速部署的需求...如果你想随时整理重构代码，那么你需要写单元测试；如果你想有自动化的测试套件来帮你快速验证提交的完整性，那么你需要写单元测试。 单元测试与自动化的关系 ? 综上，我们用来谈论单元测试的「透镜」是什么呢？...因此，意图依赖人、依赖手工的方式来应对响应力的挑战首先是低效的，从时间维度上来讲也是不可能的。...因此，为了服务于“高响应力”这个目标，随时重构整理代码是必须的，这就需要我们有一套自动化的测试套件，它能帮我们提供快速反馈，做质量的守卫者。
从广义上讲，TDD不限于开发人员在编码的过程中先写测试用例，然后驱动出代码实现，就连我们拿起一个待实现的用户故事[1]，在脑海中开始构思如何去验收这个功能，也是一个TDD的过程，只不过这个T存在于你的大脑中...本文我所要表达的TDD聚焦在编码层面中的单元测试。...试想如果我们在编写测试阶段就举步维艰，此时不得不逼着自己去思考如何让API能够利于测试。这个过程主要面临了两方面的挑战： 视角切换。从用户视角出发，将脑海中的隐性验收测试落地到代码层面。 API设计。...重构是一门手艺活，在日常编码中，你应该始终保持警惕，积极思考上述四个问题，另外辅以大量的刻意练习[5]，同时我强烈推荐你以《重构：改善既有代码设计》[6] 这本书作为起点。...结合TDD，重构大有用武之地，测试先行保驾护航，重构演奏，方能唱出悠久的歌声。然而重构到什么程度？让整洁代码来回答这个问题。
我看到周围，反而大量的是当年学习机械、电信、自动化专业的同学，在从事这一行业。 为什么会有这一奇怪的现象呢？...有了音视频的理论基础知识还不够，还需要有编码的实战能力，而锻炼这个能力，我觉得找一些大项目参与开发、动手做练习是最关键的。在做项目的过程中，把所有奇怪的坑都填一遍，水平自然就上来了。...LiveVideoStack：为什么要重构YY的直播系统？这里有哪些历史原因，又遇到了哪些来自业务的挑战？ 林绪虹：重构YY直播系统的动力，就是来自于业务的压力。...LiveVideoStack：重构进行的是否顺利？遇到了哪些挑战？ 林绪虹：最大的挑战，来自于YY直播的技术和业务历史包袱。...在音视频这个载体中，承载了大量人类想表达的信息，如何让计算机或是工具来理解其中的信息，并且更好的服务于人类，这必将是一个大家都想占领的技术制高点。
无论你是初创公司的创始人还是大型企业的工程师，这篇文章都能为你提供宝贵的见解，帮助你更好地理解并应对软件开发中的这些挑战。 软件公司的规模多种多样，包括小型初创公司、中型企业和大型企业。...此外，致力于一个不断变化的目标，一个正在积极开发的项目是困难的，而且优化的速度通常慢于新问题出现的速度。 所以，我们如何处理这些问题呢？当一个应用程序变得足够庞大时，其中一些问题似乎是无法避免的。...为了保持合规性，大公司付出了极大的努力，而这是有代价的。下面，我们来详细探讨每个合规性类别所带来的代价。 安全 安全问题究竟如何拖慢开发进程？...你可以查看这个简短的 Java 编码指南，或者如果你睡不着觉的话，可以看看这个长达 82 页的 C++ 编码指南。...到了这个时候，你可能已经编写了许多依赖于那段旧代码的新代码，甚至部署了它。现在，你需要进行一次明智的修复，解开这个混乱，部署它，并等待三个星期以确保一切正常。 在这个现实中，有一些提高生产力的小窍门。
在前言中，就写了本书的目的： 什么是软件专业人士 软件专业人士如何行事 软件专业人士如何处理冲突，应对很紧的工期，如何和不讲道理的管理人员打交道 软件专业人士何时应该说"不"？怎么说？...软件专业人士如何应对压力？ 这些问题，也正是一名软件开发人员需要去了解的问题。 所谓专业人士：就是能对自己犯下错误负责的人，哪怕那些错误实际上在所难免 专业人士有哪些特性呢？...因为他们没有做过测试 这个对于现在的开发环境太真实了，在一个项目上线后，其实在开发中后期，就已经出现这样的情况 一个方法，代码很乱，逻辑看着有点不通，出于对代码整洁的追求，重构起来，结果发布之后，出现了...这就是完全没有测试的问题。 要用这些自动化单元测试去测多少代码呢？还要说吗？全部！全部都要测 这一种方法，就是TDD，来规避这个问题。...在搏斗中，你不可能有充足的时间来研究架势，思考如何应对，这时候你只能依靠身体的反应。
工作内容涉及，开发，运维，运营，项目管理等等，在这复杂的工作中，对于如何专注，如何应对未知考验，如何抗压，也积累了一些经验。...02心流阶段 在后台基础的技术，掌握的差不多，流水线式的应对了几个月的需求后，我迎来的工作挑战的第一个升级，空间日志系统的重构。...这个说大不大，说小不小重构的机会，落到了我的头上。在经历了痛苦的方案设计，评审过后，我带着一个毕业生，开始了搬砖的过程。...这个过程，却让我感受到了从未有过的兴奋，每天起来就想第一时间去工作，晚上11点也不想回，就像大学打游戏一样，兴奋的不行。从代码开发，资源运营，测试上线等等，都是我们小团队主导。...03舒适阶段 在紧张刺激的日志系统重构稳定后，我的工作迎来了时间不短的一段舒适区，系统的工作节奏，在自己的掌握中。核心的挑战已经过去，用户的体验问题，也基本修复。
但是现在前端的代码逻辑越来越复杂，场景也越来越多。这套架构是否适合所有的应用场景值得考虑了。大前端的出现，就是一种尝试吧。试图通过Node.js接入来应对各种应用场景。 ?...如何得到一个合适的项目架构 这个确实是个问题，架构设计的合不合理。会影响到后期编码是否可以做到快速开发，还会影响后期的功能迭代和维护。 那么问题来了，我是预先设计还是预先编码？...说的是侧重点不一样，侧重于编码实现，将这个项目跑起来，然后通过重构去寻找出合适的项目架构。 对于先编码还是设计这个问题我借用重构里面的是一句话： “重构改变了预先设计的角色。...–摘自《重构-改善既有代码的设计》 实在不明白我推荐你去看看《重构-改善既有代码的设计》这本书。 所以我将侧重点放在了预先编码上，让后在整个项目demo跑起来之后再去寻找合适的架构。...这种种问题都会对你项目的架构做出挑战。这也就是我为什么先编码然后通过重构来调整项目架构的原因之一。
如果你是一个信心满满的架构师，选择了更具挑战的遗留系统改造，动手前你应该知道这个遗留系统有哪些呆账坏账，这些欠账称为技术债务。你不仅要搞清楚都有哪些债务，还要搞清楚欠债的根因是什么。...我认为重构、写测试也是编码，也属于产出，所以要给团队一个 Backlog，给团队一定的比例去做重构和开发者测试。开发者测试包括了 UT、FT、AT 等等，还包括一些性能测试、集成测试。...此时通过一些手段去优化测试、优化集成效率仍然不能满足 30 分钟以下，就可以分析如何拆分服务了，然后相应地根据康威定律的需要把这个团队进行拆分，这是我用来识别什么样的服务应该要被拆分的一种方式。...在改造过程中，架构演进难免碰到基础设施不兼容的场景，如何进行架构重构呢？第一步将基础设施比如 MQ、DB、DFS、Cache 等进行了基础设施的抽象，这一层很薄，但是却很重要。...我认为心得体会和经验才更有借鉴价值而非实践本身。优秀实践是如何诞生的呢？大都是把一个实践当做模板，结合团队的认知数据和现状数据，经过无数次迭代，参考会议上大家的改良意见从而形成优秀实践。
既然我们只需要可以运行的代码，我们为什么冒风险去激怒程序员呢？...说得对，但是，世界上有什么东西是万能的呢？我只能说，在需求变更非常快的情况下，面向对象思想，是现在我们能选择的最好工具了。...虽然我们知道，所谓的信息处理，最底层还是依赖大量的“计算”，然而，我们的程序员们，早已不再需要编写大量“计算”的代码，我们面临的挑战，是如何用代码准确而快速的表达这个世界。...代码架构与重构 我见过无数的代码架构图，里面画满了进程和服务器的拓扑，各种线条上标注了通讯协议，编码格式，还有各种流程图和协作图，然而，这些架构设计，无一例外的对于需求变更毫无帮助。...随着项目代码的不断变化，代码数量和关系都会膨胀，这种进程、通讯级别的结构，除了越来越复杂以外，根本对于指导项目如何应对各种“代码腐化”毫无用处。
[1] 所以对于这些挑战，我们也有想办法去解决，CI、CD 以及 DevOps 的出现都让我们看到了很好的方向。但是我看到很多团队其实只是靠 DevOps 解决了一些基本的问题，并没有解决核心的问题。...这是为什么呢？因为核心问题主要是靠开发人员的能力提升来解决的，但由于改变一个人是很难的，所以企业往往会绕开这些问题。所以我今天分享的内容主要会涉及到开发人员如何去写代码等一些实践。...[2] 那么质量内建的方式是怎么样的呢？首先我们通过自动化测试、重构、简单设计等手段，可以使在编码阶段引入的缺陷变少，因为我们代码写清楚了，bug 就藏不住了。...我们作为开发人员，最擅长的其实就是写代码，很多人会觉得自己的工作没什么挑战，这是因为你天天都在手工地做一些重复的事情，当然没有挑战了。...也就是将我们的这个流程固化下来了，原本一件事情今天是 A 做，明天是 B 做，他们在做的时候可能就基于自己的理解来做，中间就会引入一些错误。而自动化就可以规避这种问题。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
