作为一名软件工程师工作了10年，我学到了10条适用于我们职业生涯的经验教训。在职业道路上，你应该学会向那些成功人士请教，问他们做了什么，为什么这样做，以及他们的具体做法。在本文中，我将分享我在职业生涯中作为全栈工程师所学到的知识。作为一名年轻的工程师，我在科技行业和硅谷工作了十年。十年来，我一直在高增长的初创公司工作，经历了与之相关的所有起起落落。从构建下一代电子邮件客户端，到在全球推广电动汽车，再到查看在线购物，我学到了很多东西。当我回头看时，我认为有些错误是可以避免的。在本文中，我将分享我在职业生涯中作为全栈工程师所学到的知识。从中，我总结出十个教训。我相信这些教训将经得起时间的考验，并在未来的岁月中保持现实意义。该列表从前端开始，然后是后端API和数据库，最后是工程最佳实践/流程。经验教训组件层次结构中的CSS特异性设计状态后端编程中的意大利面条、烤宽面条和馄饨生产中的Postgres仓促制造浪费投资于自动化掌握你的工具最小可行产品可行产品，MVP)研究支持开发科学调试1.CSS特异性错误:我的CSS不适用。我要使用!important。经验教训：!important应保留用于特殊情况，因为它们会破坏整个CSS层次结构并强制使用特定样式。所以，你需要了解CSSSpecificity。CSS特异性是浏览器应用的一组规则，用于确定哪些CSS样式更具体。您可以将其视为一个基于点的系统，它决定哪些CSS样式获得优先级并最终应用于DOM元素。如果您想知道，为什么您的CSS没有被应用，这与CSS特异性有关。在大型项目中，这是一个非常普遍的问题，在大型项目中，像SCSS这样的预处理器与复杂的CSS层次结构一起使用。了解CSS的特殊性将帮助您继续使用!important并且仅在极其罕见的覆盖情况下使用它，例如，当您想要覆盖CSS库或让iframe覆盖主机站点样式时。本质上，优先顺序是这样的：ID选择器>类选择器>类型选择器。!important和内联样式属性覆盖所有CSS。对于应用于元素的每个CSS，您可以轻松确定哪些样式将生效。例如，如果您加载上面的HTML代码：在这种情况下，ID选择器优先于类型选择器。如果冲突的CSS选择器具有相同的优先级，则将选择CSS文件中的最后一个。最后，ChromeDevTools将显示如上所示的特定顺序。如果您不会使用CSS，请查看Chrome使用的特异性顺序，然后添加更具体的选择器（如ID选择器、类选择器、类型选择器），使您的CSS更具体并指示浏览器选择它。如果你不想这样做，看看这个特异性计算器链接：https://specificity.keegan.st/2.组件层次结构的设计状态是错误的：我需要添加这个新状态。我只要把它放在这个reducer里面就行了，但是不知道为什么这个reducer还有那么多状态？经验教训：管理不善的redux状态会在开发人员中造成混淆并导致错误。如果您正在使用React和Redux构建前端应用程序，那么您可能会考虑使用这种可视化技术从UI组件层次结构中构建状态和缩减器层次结构。从零到统一的组件状态层次结构分为三个步骤：线框可视化UI可视化状态层次结构以反映UI构建reducer层次结构以反映状态层次结构让我们看一个例子。在这个例子中，我们建立一个博客网站，它有两个页面，一个页面是博客列表，另一个页面是个人博客：Step1:可视化线框图中的用户界面Step2:可视化状态层次结构到反映用户界面对应的状态层次结构图如下所示：类似地，任何共享状态都可以在层次结构中“向上冒泡”，因此很明显子组件共享该状态。第3步：构建reducer层次结构以反映状态层次结构reducer层次结构这是一个简单但功能强大的示例，展示了如何构建状态和reducer层次结构以匹配用户界面。这个过程很容易扩展到复杂的应用程序和大型团队。最后，您可以在此结构之上构建操作层和表示层。3.后端编程中的意大利面条、酥皮糕点和馄饨错误：这个代码库是如何组织的？也许我可以像所有其他存储库代码一样在此处添加此文件。经验教训：我写过三种“意大利面条代码”。老实说，我觉得把“迷你酥皮代码”放在“馄饨代码”中可能是个好主意。组织和培训所有开发人员以这种方式构建代码库，使代码保持可维护、可测试，最重要的是，保持代码敏捷。你可以很容易地修改某个特定“馄饨码”（即函数）的实现细节，而不影响其他函数。《千层饼码》是：层次分明的架构，外层是I/O，内层是纯数据结构依赖注入内层不依赖外层优先组合，而不是继承“馄饨式代码”“是：尖叫架构切片和分层文件夹和文件，其中空间位置可以是微服务将它们放在一起，您将获得可扩展，可维护的代码库。如果您能找到一种组织文件夹的方法4.Postgreserrorinproduction:whyisthisquerysoslow?我认为这是因为Postgres很慢。我需要切片，或者我认为它是一个ORM，或者，我需要一个不同的数据库，Postgres不适合我。经验教训：如果您在生产环境中运行Postgres，您将遇到缓慢的查询、表锁、无限的迁移等待和错误。如果不是，它对你有好处吗？你是怎么做到的？这并不意味着Postgres不再是正确的工具，而是意味着您需要揭开帷幕，看看下面发生了什么。到目前为止我发现的最好的工具是pgbadger。您可以使用它来解决几乎任何Postgres问题。链接：https://github.com/darold/pgbadger这是一个Perl命令行工具，它将Postgres（如果您使用AWS，则为RDS）日志作为输入和输出报告。此报告仅与您在Postgres上启用的日志记录一样好。因此，您可能需要在第一步中启用这些日志：log_checkpoints=onlog_connections=onlog_disconnections=onlog_lock_waits=onlog_temp_files=0log_autovacuum_min_duration=0log_error_verbosity=defaultlog_min_duration_statement=1s此外，您可能还需要启用pg_stat_statements语句以实时自动分析查询时间，并启用auto_explain在日志中解释运行缓慢的查询。运行报告：pgbadger--prefix'%m%u@%d%p%r%a:'/pglog/postgresql.log该报告将总结数据并提供大量关于Postgres正在做什么的信息。您可以找到有关错误、最慢查询、最长等待查询、获取的锁类型、临时文件是否用于排序、检查点运行频率、真空运行频率以及其他类似信息的信息。有了这些数据，您就可以识别和修复运行缓慢的查询，并通过调优提高Postgres的性能。您可以连续运行此报告（CLI支持增量模式）以掌握新问题。此外，如果您想了解解释后的输出，可以使用此工具。链接：https://tatiyants.com/pev/#/plans/new该工具将解释后的JSON和原始查询作为输入，并在如下所示的可视化树图中解释解释后的输出：如您所见，节点将具有标签，如最大、最慢、最昂贵等。这将帮助您根据Postgres的执行方式优化查询。最后，如果在Postgres中构建能力不可行，我建议您询问像Percona这样的数据库咨询公司。链接：https://www.percona.com/5。欲速则不达错误：看起来不错，让我们交付！经验教训：在这个快速行动和打破常规的时代，这似乎不是最流行的建议，但“慢慢来”会有回报。与其快速发布错误代码，不如有条不紊地发布几乎没有生产错误的代码。一个好的工程师会考虑软件系统的方方面面。链接：https://codesqueeze.com/the-7-software-ilities-you-need-to-know/他们不仅关心代码覆盖率，还关心可能破坏相同代码路径的奇怪输入。使用分层架构，他们可以实现模拟层并仅测试正在考虑的层。他们不仅实施单元测试，还实施集成和功能测试。如果您的团队也有QA工程师，请与他们一起测试这些用例。说：“欲速则不达，欲速则不达，欲速则不达。”6.对自动化的错误投资：我们手动部署到暂存和沙箱，这些都是临时的。生产也是手动部署的，但每天执行一次。教训：让CI/CD系统管理部署意味着更可预测的结果。软件通过促销策略在管道中移动，而临时部署被降级为特殊情况。这确保了您交付的软件的稳定性和可靠性，这是工程团队的主要职责。投资：培训团队成员如何进行代码审查。您的团队成员可能拥有各种技能，但并不是每个人都知道如何更好地进行代码审查。因此，您应该投资学习和教授代码审查最佳实践。使用像peril和hound这样的自动代码审查系统。Peril可以检查代码更改，并根据预先配置的设置标记警告和构建失败。例如，如果数据库迁移文件缺少statement_timeout或包含不必要的DEFAULTNULL，拉取请求可能会失败。您可以编写许多此类检查和特定于团队的规则，让Peril成为更改的“看门人”。HoundCI可以做类似的事情，而且规则是完全可配置的。使用CircleCI等工具设置具有自动推广策略的CI/CD管道。随着时间的推移优化构建和部署管道。链接：https://circleci.com/7。掌握你的工具错误：我需要找到这个实现接口，先搜索。我记得以前在这个文件夹里，现在不见了？看看那个文件夹，我最好问问别人！经验教训：不知道如何使用你的工具会降低你的工作效率。你能想象一个草率的裁缝使用缝纫机吗？这不仅仅关乎代码结果，还关乎您构建软件的效率。了解你的工具和掌握捷径。代码编辑器可能是您将掌握的第一个工具。您应该知道如何设置选项卡的顺序、打开上次编辑的文件、显示调用图等。如果您使用基于文本的编辑器而不是GUI，这也适用。像Vim这样的编辑器有很多有用的技巧。请注意您手动执行的常见操作，并了解如何使用快捷键来执行这些操作。一个简单的方法是先记住5个快捷键，熟练掌握它们，然后再记住5个快捷键。全栈工程师日常接触的其他常用工具还有终端、docker、tableplus/pgadmin/一些其他数据库客户端用户界面、Chrome开发工具等。8.MinimalViableProduct(MVP)bug：我觉得这个特性会有用的。我将使用分布式容错复制一个高度可用的数据存储。我还想构建一个基于插件的架构，使这个软件具有超强的可扩展性。经验教训：在您构建某物之前，请确保它是您想要构建的正确的东西。这就是MVP的用武之地。理想的最小可行产品(MVP)应该尽可能少地接触所有层，而不仅仅是一层。这是一种降低风险的方法。最好以最低限度构建所有层，而不是完善单个层。最小可行产品并不意味着技术债务、糟糕的代码或缺乏测试。它不是一次性代码。如果MVP花费的时间太长（在某种程度上），那么它很可能是错误的解决方案，并且可能有更简单的解决方案。奥卡姆剃刀：在所有其他条件相同的情况下，更简单的解释通常比更复杂的解释更好。9.研究支持开发错误：我（工程师）认为这是我们应该构建的。经验教训：应该在开发之前进行大量研究以支持它。不要跟随你的直觉，而是进行用户研究。要了解用户需求，您可以进行面对面或视频访谈、进行调查、查看日志等。这将帮助您更好地了解您的用户。然后，您可以提出一个假设并对其进行实验。在形成假设时，使用反演来反驳你的主张。链接：https://fs.blog/2013/10/inversion/投资一个允许您进行实验的A/B测试框架。时间宝贵，请明智地使用它。最聪明的工程师会尝试优化不应该存在的东西。尽早提出正确的问题非常重要。10、科学调试bug：有bug。我认为这是因为代码更改。让我看看这个文件。很有可能是内存问题。或许这两个原因。课程：作为一名工程师，您将调试软件中的问题，无论是作为事件的一部分还是在本地环境中。如果不通过结构化推理进行调试，调试可能会很痛苦且很慢。我们如何系统地找出程序失败的原因？如果没有“直觉”和“敏锐的思维”这样模糊的概念，我们怎么能做到这一点呢？我们想找到一种方法来找到失败的原因-一种方法：不需要先验知识是系统的我们可以确保找到根本原因，并随意重现应用科学方法调试问题在开发中是合理的失效方法理论。科学调试的步骤如下：重现错误（通常是时间、数据、用户、操作系统、调试器的某种组合）观察事实（彻底阅读日志、错误跟踪等）在日志中明确陈述假设，而不是在Make中心理上的假设如果你在程序的某些部分发现了一个错误，使用结构化的方法来缩小错误的范围，比如二进制搜索测试假设：使用日志、断点、断言如果通过，应用修复并确保没有新错误如果没有，请重复步骤3到6。对于简单的调试情况，这似乎有点矫枉过正。然而，对于涉及多个团队的复杂分布式系统，系统科学调试过程提供了消除歧义的必要结构。十一、额外收益（一）分享知识，服务他人优秀的行为就是帮助他人成长。当你需要用别人能理解的方式解释某件事时，你对事物的理解会更加清晰。每天在Slack上分享深思熟虑的链接，进行演示，表扬他人的积极行为，挑战模棱两可的决定，并在您希望与某人或某个决定朝着不同的方向前进时提供建设性的反馈。您可以使用短语“感谢ABC...希望XYZ”来表达您的反馈。通过这样做，您可以为自己建立个人品牌，从而获得专业资本。研究表明，那些拥有强大个人品牌、在线形象和帮助他人取得成功的记录的人，更重要的是，拥有充实的职业生涯。(2)塑造你自己的世界你不必接受这个现实。您可以坐在驾驶座上塑造您所感知的世界。这可能意味着在设计讨论和代码审查期间提供输入，或修复关键的不稳定测试。很多人会告诉你说出来并提高你的形象，这样你就可以在公司内成长，但他们从不告诉你如何去做。做到这一点的最好方法是拥有强烈的观点和信心，将人们拉向你的方向。不要害怕组建小团队来构建/改进事物。不要屈服于你的恐惧。大声说出来，只要不冒犯人，都可以。负面情绪是改变的巨大动力。如果有什么问题困扰着你，问问自己并想办法改变它。如果您将每一天都视为成长的途径，那么生活就会变成一种锻炼。(3)交朋友如果你像我一样想弄清楚什么对你来说真正重要，那就结交很多朋友，尤其是那些你感兴趣的。这可能意味着参加会议、参与在线社区或在黑客马拉松和项目上进行合作。这种接触将帮助你弄清楚你想做什么。这样，您就可以对无关紧要的事情说“不”，并抓住对您重要的机会。许多成功人士感到幸运，他们声称知道自己想从什么开始，仅仅是因为他们在正确的时间、正确的地点做了正确的事情。这使他们能够适应并抓住机会而不会后悔。遇到聪明人，不要轻易拒绝。通过这样做，我发现我更喜欢广度而不是深度，重视创造力和自由，喜欢多样性和非正式的关系。结构化的重复性工作、例行公事、稳定和安全不是我的事。如果您知道自己想要什么，世界就会为您提供所需的信息。全栈编程很有趣。这是一个不断发展的领域，也是一片学习冲浪的海洋。不要把你自己或你的错误看得太严重。分享它们并不断成长。
