我们点评了为程序员和开发人员提供的十大最佳 Linux 发行版（2022 版），以帮助他们完成工作和个人项目。程序员和开发人员在其工作或项目中会使用各种工具和应用程序，包括代码编辑器、编程语言编译器、附加组件、数据库等。如果你对现代开发者的工作流程进行分类，它包含以下典型的工作流程：访问代码库编程调试测试部署而这种典型的工作流程可能需要各种工具。一个标准的清单可能是这样的：代码编辑器简单的文本编辑器网页浏览器（网页开发者需要所有变体）数据库引擎一个本地服务器编程语言相应的编译器调试器监测或剖析工具（可执行文件或网络版）可以说，与 Windows 相比，Linux 是编程的最佳选择。（出于几个原因，我在本文中不对 macOS 进行比较。）Linux 是最佳选择的主要原因是，与 Windows 相比，在 Linux 发行版中已经预装具有现代技术的软件包和应用程序，或非常容易安装。因此，在这篇文章中，我们想列出 2022 年最适合程序员的 Linux 发行版。2022 年适合程序员的十大 Linux 发行版1、Fedora Workstation也许这个名单中最完美的 Linux 发行版是 Fedora Linux。它用于桌面的默认 Workstation 版通过其选择的软件包带来了正宗的 GNOME 桌面体验。Fedora Linux 的默认安装为你提供了所有主要的开发包，开箱即用。它们包括 PHP、OpenJDK、PostgreSQL、Django、Ruby on Rails、Ansible 等。通过 dnf 软件包管理器安装更多的应用程序是非常简单的，如 VS Code 编辑器和其他软件包。你也可以借助“ 软件 Software ”应用来安装，这是一个应用商店，你只需点击一个按钮就可以搜索和安装应用程序。Fedora Linux 支持 Snap 和 Flatpak，这给了你更多的灵活性。你也可以利用 Fedora 中的 RPM Fusion 仓库，这个仓库让你可以访问许多自由和非自由的软件包。由于许可证和其他明显的原因，Fedora Linux 不想在他们的主仓库中包括这些包。你可以在下面的官网上查看最新的 Fedora Linux。下载 Fedora2、Ubuntu Linux本列表中的第二个 Linux 发行版是 Ubuntu Linux。Ubuntu Linux 是目前在服务器和桌面上使用最多的 Linux 发行版。Ubuntu 提供长期支持（LTS）版本，有五年的官方支持（另外还有五年的维护支持），期间还有短期支持版本供高级用户使用。由于它很流行，所有最新的软件包和应用程序供应商都提供 Ubuntu（.deb）版本。因其流行，也带来了论坛和文档的大量支持，这对开发者来说是完美的，特别是当你在开发阶段被错误困住的时候。在下面的链接中了解更多关于 Ubuntu 的信息。下载 Ubuntu3、openSUSEopenSUSE 是全球在关键系统中使用的最稳定和最专业的 Linux 发行版之一。这个 Linux 发行版是企业级工作负载的首选解决方案之一，包括台式机、服务器和瘦客户机。它比 Ubuntu 和 Fedora 有一些优势。首先，它有两个变种：Leap 和 Tumbleweed。openSUSE Leap 是一个长期支持版本（LTS），提供最新的稳定性。openSUSE Tumbleweed 是一个滚动发布的软件，提供尖端的软件包。如果你的开发需要最新的软件包和硬件支持，那么 Tumbleweed 就是你的选择。如果你需要稳定性和一个运行时间较长、维护量较小的系统，请选择 openSUSE Leap。使用 openSUSE 进行开发工作的优势之一是其软件包管理器 YaST。使用 YaST 软件包管理器，你可以轻松地将许多事情自动化。除此之外，openSUSE 的软件交付方式也很出色。它的软件门户在网上，你可以访问它，搜索一个软件包，然后点击安装。如果与新用户相比，你对 Linux 有一定的经验，请选择 openSUSE 进行开发工作。下载 openSUSE4、Manjaro LinuxManjaro Linux 是一个基于 Arch Linux 的发行版，它使 Arch 的安装变得简单。它基于 Arch Linux，但带来了一些功能，如像 Ubuntu 或 Linux Mint 那样的图形化安装程序、 pamac 安装程序、精心策划的软件仓库等。Manjaro 有三种主要的桌面风格：GNOME、KDE Plasma 和 Xfce，可以满足几乎所有用户的需求。如果你想用 Arch Linux 和它的滚动发布包来满足你的开发需求，但又不想陷入安装原生 Arch 的麻烦，Manjaro 是你的完美选择。下载 Manjaro5、Arch Linux虽然 Manjaro 和其他基于 Arch 的易于安装的 Linux 发行版已经出现，但你可能还是想用 原生 Arch 来亲手定制你的桌面。这更多的是针对那些想要更多控制权和为项目或需求建立自定义 Linux 操作系统的资深开发者或程序员。在这些情况下，你可能想用你最喜欢的桌面安装 Arch Linux 来设置你的开发操作系统。假设你对 Arch Linux 和计算机有一定的经验。在这种情况下，这是所有选择中最好的，因为它可以让你完全控制定制的 Linux 操作系统中的每个软件包。下载 Arch Linux6、Pop OSPop OS（写作 Pop!\_OS ）是由计算机制造商 System76 为其系列硬件开发的。Pop OS 是自由开源的，基于 Ubuntu。它遵循 Ubuntu 的发布周期，同时带来额外的调整，以及为用户定制的软件包。Pop OS 是程序员的完美选择，因为它原生支持许多 Ubuntu 支持的编程语言。它因其打造的软件中心而在计算机科学家和程序员中广受欢迎，该软件中心有一个专门的部分介绍开发和编程的应用程序。除此之外，Pop OS 中的 COSMIC 桌面（一个定制的 GNOME 桌面）为程序员提供了独特的体验，包括自动平铺、可爱的调色板、原生的深色模式和丰富的设置。如果你需要一个基于 Ubuntu、稳定的、并对程序员友好的 Linux 发行版，那么请选择 Pop OS。下载 POP OS7、KDE Neon如果你是一个很习惯 KDE Plasma 桌面的开发者，并且想要一个基于 Qt 的开发环境，那么 KDE Neon 就非常适合你。KDE Neon 是一个基于 Ubuntu LTS 版本的 Linux 发行版，带有最新的 KDE Plasma 桌面和 KDE 框架包。因此，在 KDE Neon 中，你可以得到 Ubuntu LTS 的稳定性和带有 Qt 的最新 KDE 软件包。如果你需要一个拥有开箱即用的应用程序的快速系统、一个友好的用户界面和巨大的社区支持，这是一个完美的 Linux 发行版。下载 KDE Neon8、DebianDebian GNU/Linux 无需介绍。Debian 的稳定分支是 Ubuntu 及其所有衍生品的基础。因此，它是主要和稳定的 Linux 之一。它是你的开发环境的完美选择，因为它为你提供了终极稳定性和多年的支持。不过，Debian 的稳定分支在采用最新软件包方面略显保守。Debian 的维护者会仔细检查和合并软件包，因为整个世界（嗯，几乎）都依赖于 Debian 的稳定性。对于高级用户和系统管理员来说，如果你想要一个稳定的、长期运行的开发环境，并且维护工作量较少，那么它是一个完美的编程环境。下载 Debian Linux9、Kali LinuxKali Linux 是由 Offensive Security 开发的，主要针对寻找网络漏洞的道德黑客和渗透测试人员。它预装了大量的黑客工具和应用程序。如果你有足够的经验，它可以成为程序员和开发人员的一个完美的 Linux 发行版。如果你对 Linux 很熟悉，并且在处理错误和依赖关系方面有一定的经验，就可以选择 Kali Linux。下载 Kali Linux10、Fedora 实验室而这个名单上的最后一个 Linux 发行版是 Fedora Linux 的发行版组合。Fedora 实验室 Labs 为程序员、科学家和学生提供了专门策划的 Linux 发行版，并预装了应用程序、相应的软件包和实用程序。很多人都不知道这些，如果配置得当，它们可以作为完美的现成 Linux 发行版为你服务。下面是对它们的总结：Fedora 科学科学和数值开源工具与 KDE Plasma 桌面的结合应用列表包括：用于 C/C++ 的 GNU 科学库与 MATLAB 兼容的 MGNU OctaveLaTeXMaxima 计算机代数系统用于绘制二维和三维图形的 Gnuplot用于数据科学的 Pandas Python 库IPython用于 Java 和 R 编程语言的软件包关于 Fedora 科学，在此下载 和了解更多。Fedora 计算神经科学带有 GNOME 桌面环境的开源神经科学应用程序和软件包。了解更多并 在此下载。Fedora 机器人套件这个完美的 Linux 发行版结合了最好的开源机器人应用程序和软件包，针对初级和经验丰富的机器人科学家和程序员。了解更多并 在此下载。来自 Fedora Linux 的其他解决方案包括 Fedora 安全实验室、Fedora 天文学 和 Fedora Python 教室，你或许想看看这些解决方案。这些 Fedora 实验室选项可以成为编程项目或在特定科学领域工作的完美 Linux 发行版。总结那么，你如何在这份最适合程序员的 Linux 发行版名单中选择你的最爱？如果你不确定，并希望以最小的努力来建立和运行一个开发系统，那就选择 Fedora Workstation 或 Ubuntu。如果你有空闲时间，或者想对你的系统有更多的控制，喜欢做实验，对偶尔出现的错误也不在意，那么就选择基于 Arch Linux 的系统。对于刚进入 Linux 生态系统的新开发者来说，Pop OS 也是一个不错的选择。对于特定的需求，请到 Fedora 实验室选择。我希望这份 2022 年最适合程序员的 Linux 发行版清单能给你一些指导，让你选择最喜欢的 Linux 发行版进行编程和开发。干杯。via: https://www.debugpoint.com/top-linux-distributions-programmers-2022/作者：Arindam 选题：lkxed 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
Linux 内核 6.0 正式发布，但更期待 6.1没有遇到意外，Linus Torvalds 于今天推出了 Linux 6.0 稳定版。不过，虽然是新的大版本号，但是 Linus Torvalds 一如既往地重申，“希望每个人都清楚，主要版本号的变化更多是因为我手指头已经数不过来了，而不是任何重大的根本性变化。”这个版本号的前一个版本号是 5.19，曾有提议将此版本命名为 5.20。另外，这也标志着 Linux 内核 6.1 的合并窗口开启.Linus 说，“与 6.0 不同，6.1 有许多相当核心的新东西”，比如内核对 Rust 初步支持、能够大幅提升性能的 MGLRU 等等。6.1 将于今年年底发布。消息来源：Phoronix老王点评：好吧，让我们继续期待 6.1。2022 全球程序员薪资排行榜，中国倒数第九CodeSubmit 对二十多个国家的程序员的薪酬做了调查，前三名是：美国、瑞士和以色列。其中美国平均年薪 11 万美元。中国在二十多个国家中排名倒数第九（或者说位列中游），平均年薪 23,790 美元。而倒数第一和第二是尼日利亚（7,255）和印度（7,725）。此外，按编程语言划分：Go 和 Ruby 是收入最高的语言，均为 12 万美元左右；Python、Java、JavaScript 稍少一点，11 万美元。消息来源：CodeSubmit老王点评：中国程序员薪酬不算高并不意外。不过印度居然倒数第二，所以，印度的 IT 行业真的发达吗？黑客利用开源软件和虚假工作机会进行钓鱼式攻击微软威胁情报中心称，一个钓鱼黑客组织一直在使用木马化的开源应用程序和 LinkedIn 招聘诱饵来诱骗科技行业员工。他们发现该组织自 4 月底以来使用 PuTTY、KiTTY、TightVNC 等软件安装程序进行这些攻击。这和我们之前 报道 的谷歌 Mandiant 发现的情况一样。消息来源：ZDNet老王点评：这种被带木马的开源软件钓鱼的员工真的合格吗？我觉得各个企业是不是模拟一下这种钓鱼测试。
做一个高效的、充满好奇心的问题解决者吧！这会帮助你成为一名成功的程序员。你是否曾经遇到过这样一种情况：你想解决一个问题，并且你在 YouTube 或 Google 中找到了相关的教程。嗯，你觉得看会了，可真做起来，却止步不前，大脑一片空白。你感觉自己每一行代码都看懂了，可一旦离开了那个教程，就步履维艰。如果你在 HackerRank 或 LeetCode 上看过别人的解题过程，你就能体会到，一个有追求的程序员第一次看到这些挑战时，他会是何种感受。举例来说，假设你正在学习一门新语言，在你刚开始理解这门语言的基础知识的时候，你看了一个教程，摩拳擦掌，结果发现自己无法独立应用学到的知识，这反过来可能会导致你怀疑自己的知识和能力。把教程付诸于实践你应该从头开始吗？如果你这么做，你可能很快就会发现自己重复学习了很多次相同的知识点。虽然从头开始并不一定是种浪费，但是，你该如何变得更高效呢？死记硬背在编程中完全是行不通的。话虽如此，但你也不能够忽视熟悉语法的重要性。因为，死记硬背和养成习惯之间是有明显区别的。习惯是很难打破的。要养成多使用编程语言的常规语法、函数、方法、模式、范式和构造的习惯，这样你才能掌握它。掌握一门编程语言需要大量的创造力和练习。练习语法是非常必要的，直到它们能在你的脑海中自然地浮现，就像血液在血管里流动一样。“问题解决”的工作原理那么，你该采取什么样的方案呢？这实际上取决于许多因素。这些因素可以是任何东西，下至技术限制，上至用户需要。世界上有无数的问题，每个问题都有许多解决方式。如何选择一个最好的？这就需要 “问题解决” problem-solving 的技巧了。 下面是一个简单的例子。你需要把两个数相加，让它们等于 6。显然，你有多种方式可供选择：3 + 3 = 6 或 4 + 2 = 6 或 5 + 1 = 6同理，如果你需要让两个数字，经过一次减法、乘法或除法运算后，得到的结果为 6。你仍然有很多选项，包括：8 - 2 = 6 或 12 / 2 = 6 或 3 * 2 = 6每种方案都有它固有的限制，且各不相同。当你在现实生活中尝试做出一个高效的方案时，你必须要考虑到所有的限制。这个方案可行吗？有什么障碍吗？有可操作性吗？是否可扩展呢？而如何最小化约束，并做出一个最优方案，就取决于问题类型和业务需要。练习很重要编程的目标不仅仅是解决问题。因此，从工程视角理解代码如何工作始终是一个优势。这就是代码审查在企业级开发中发挥作用的地方。编程的最低要求是具备基本的编码知识，包括语言的语法、函数和方法。归根结底，“写代码”是需要你去写的，所以练习总是有助于提高你的技能。流畅的写作和复杂方案的开发都来自于持续的学习和训练。学习编码我撰写和分享这篇文章，是为了鼓励新程序员去探寻自己的内心，寻找那个“优秀的问题解决者”。请不要停止相信自己。要成功编码，你需要培养许多习惯。下面是我在学习编码时保持高效的方法：一个包含语法、方法和函数 速查手册 总能应付不时之需。将问题分解成更小的部分，便于追踪。尝试理解代码运行的核心概念。构思解决方案时，大可发挥你的创造力 —— 但刚开始还是要注重基础。在练习时，创建尽可能多的应用和组件。永远不要从 Stack Overflow/Exchange 等开放平台上复制/粘贴代码，特别是在不了解上下文的情况下。跟着教程做了一遍后，尝试从头开始构建所有内容。即使你只能独立完成一半，那也仍然是一个成就。祝我们所有人好运！via: https://opensource.com/article/22/8/coding-advice-new-programmers作者：Sachin Samal 选题：lkxed 译者：lkxed 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
硬核观察 #701 FSF 仍坚持使用古老而自由的服务器硬件
FSF 仍坚持使用古老而自由的服务器硬件自由硬件日益稀缺，但自由软件基金会（FSF）仍然在坚持其理念，它的服务器配置都相当古老，因为新一代的硬件都含有非自由的私有固件。FSF 最近表示它更换了最后一台运行非自由 BIOS 的机器。目前它有两个数据中心和逾百个虚拟机。英特尔和 AMD 在 2013 年之后发售的 CPU 都不支持自由 BIOS。这些 CPU 都会在 BIOS 中安装私有固件，如英特尔管理引擎（IME）。这些 CPU 也会拒绝运行未经过 AMD 和英特尔私钥加密签名的固件，而他们只会签名自己的非自由固件。消息来源：FSF老王点评：从自由软件和开源软件两个略有分歧的路线开始，现在看起来开源软件越来越广泛，而自由软件面临的局面越来越艰难了。因为，那些“拥抱”开源的企业发现，开源对他们是有利的，而自由软件则不是。各国程序员平均年薪，美国第一，中国仅相当于美国的 1/5一家招聘平台统计分析了 20 多个国家的软件开发者在 2022 年的薪资状况，并列出了排名数据。据统计，2022 年年薪最高的三个国家为：美国（11 万美元）、瑞士（9.8 万美元）和以色列（7.2 万美元）。而中国为 2.4 万美元，约折合人民币 16 万，仅相当于美国程序员平均收入的 21.6%。就全球使用的编程语言而言，Golang 和 Python 语言薪酬最高，PHP、JavaScript 语言最低。消息来源：Code Submit老王点评：今天正好在朋友圈看到一位朋友的信息，曾经的一位专业的 IT 女工程师，去跳槽到一家做减肥的微商公司。不由得感慨，在中国做 IT 真是艰难啊。不过，之前我们发过的另外一个消息显示，美国对 IT 专家的缺口很大，以至于业界要求政府加强计算机教育。Fedora 37 有望装备基于网页的全新 Anaconda 安装程序在今年早些时候，红帽公司宣布正在为 RHEL/Fedora 的 Anaconda 安装器开发全新基于网页的用户界面。即将于今年秋季发布的 Fedora 37 虽然会保留基于 GTK 的 Anaconda 安装器，但也会提供下一代基于网页的 Anaconda 安装器，带来全新的界面和安装体验。全新的界面更加现代化，未来将会彻底替代现有基于 GTK 的 Anaconda 安装器。消息来源：Phoronix老王点评：这倒是不错，其实采用网页可以有更丰富的表现力和功能。
无论你身处编程旅程中的何处，这 12 篇编程文章都有你需要学习一些东西。“学习计算机编程的最佳时间是 20 年前，其次是现在。” — 计算机科学的谚语（也许是）无论你是新程序员、经验丰富的 Web 开发人员、后端大师、头发花白的系统程序员，还是其他神秘物种的计算机极客？无论你身处广阔的软件开发人员生态系统中的何处，在我们领域中唯一不变的就是需要了解新技术及其应用方法。这是过去一年来阅读量最大的 Opensource.com 文章的集合，我很高兴在这里与你分享它们。好好学习无论你的技能或兴趣是什么，学习如何编写计算机程序都可以将特定领域的知识变成一种超能力。不幸的是，至少从现在开始，还不可能通过坐在计算机前面接受电磁辐射就能学会如何编程。在这之前，我推荐这些出色的文章来帮助激发你的编程技能。它们解决了一些重要的问题，例如考虑学习哪种语言以及不同的入门方式。你应该学习哪种编程语言？（译文）学习 Python 的 12 个方式（译文）你可以使用树莓派学习的三种流行编程语言（译文）利用 Python 引导孩子的计算机思维（译文）天天向上经验丰富的程序员知道，与学习编程相比，唯一更难的就是使你的技能和知识保持最新。但是我们是自学成才的一族，总是希望提高我们的专业知识和理解力。即使我们不期望使用新技术，我们也知道总会有人问起它们。这些有关 Rust、WebAssembly 和 Podman 的文章是开始学习软件技术一些即将出现的趋势的好地方。为什么要在 WebAssembly 中使用 Rust？使用 WebAssembly 扩展命令行领域免 root 的 Podman 如何工作？为什么选择 Rust 作为你的下一种编程语言老兵不死尽管新技术层出不穷，但回顾过去可以帮助你前进。当今惊人的技术是建立在昨天的工具之上的，即使我们从未使用这些传奇语言编写过代码，它也将使我们很好地理解这些工具的功能和局限性。这一系列文章集中于 C 语言、用 AWK 编写的实际应用程序，以及对流行度下降但也许还没有消亡的计算机语言的有趣讨论。C 的巨大影响如何写好 C main 函数（译文）用 AWK 喝咖啡（译文）你最喜欢的“死”语言是什么？学习不止无论你在编程过程中处于何处，总有更多东西需要学习。我希望这些来自 2019 年的顶级资源能帮助你为 2020 年做好准备。感谢作者们和你——读者。via: https://opensource.com/article/19/12/programming-resources作者：Erik O'Shaughnessy 选题：lujun9972 译者：wxy 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
这幅妙绝的题图来自 Miquel Beltran我的技术生涯，从两年前算起。开始是 QA 测试员，一年后就转入开发人员角色。没怎么努力，也没有投入过多的个人时间。你可以从我为何从生物学转向技术和我学习 Android 的一年 这两篇文章中找到些只言片语。今天，我想谈谈是自己是如何开始担任 Android 开发人员这个角色、如何换公司以及作为 Android 工程师的一年所得所失。我的第一个职位角色我的第一个职位角色， Android 开发者，开始于一年前。我工作的这家公司，可以花一半的时间去尝试其它角色的工作，这给我从 QA 职位转到 Android 开发者职位创造了机会。这一转变归功于我在晚上和周末投入学习 Android 的时间。我通过了 Android 基础纳米学位、Andriod 工程师纳米学位课程，也获得了 Google 开发者认证。这部分的详细故事在这儿。两个月后，公司雇佣了另一位 QA，我转向全职工作。挑战从此开始！比起给他们提供一台笔记本电脑和一个 git 账号来说，要把某人转变为胜任的开发角色，显然困难重重。在这里我解释一下我在那段时间遇到的一些障碍：缺乏预期我面临的第一个问题是不知道公司对我的期望。我认为他们希望我从第一天起就有交付物，虽然不会要求像那些经验丰富的同事一样，但也要完成一个小任务就交付。这种感觉让我压力山大。由于没有明确的目标，我一直认为自己不够好，而且是个伪劣的冒牌货。缺乏指导在公司里没有导师的概念，环境也不允许我们一起工作。我们很少结对编程，因为总是在赶项目进度，公司要求我们持续交付。幸运的是，我的同事都乐于助人！无论何时我卡住或需要帮助，他们总是陪我一起解决。缺乏反馈那段时间，我从来没有得到过任何的反馈。我做的好还是坏？我应该改进些什么？我不知道，因为我没有得到过任何人的评论。缺乏学习氛围我认为，为了保持常新，我们应该通过阅读博客文章、观看演讲、参加会议、尝试新事物等方式持续学习。该公司在工作时间并没有安排学习时间，不幸的是，其它开发人员告诉我这很常见。由于没有学习时间，所以我觉得没有资格花费哪怕十分钟的时间来阅读与工作相关且很有意思的博客文章。问题不仅在于缺乏明确的学习时间津贴，而且当我明确要求时，被拒绝了。当我完成突击任务时，发生了一个例子，我们已经完成了任务，因此我询问是否可以用剩下的时间来学习 Kotlin。这个请求被拒绝了。另外的例子是我想参加一个 Android 相关的研讨会，然后被要求从带薪年假中抽出时间。冒充者综合征在这公司缺乏指导、缺乏反馈、缺乏学习氛围，使我的开发者职业生涯的前九个月更加煎熬。我有感觉到，我内心的冒充者综合征与日俱增。一个例子就是拉取代码进行公开展示和代码审查。有是我会请同事私下检查我的代码，并不想被公开拉取，向任何人展示。其他时候，当我做代码审查时，会花好几分钟盯着“批准”按纽犹豫不决，在担心审查通过的代码会被其他同事找出毛病。当我在一些事上持反对意见时，由于缺乏相关知识，担心被坐冷板凳，从来没有大声说出来过。某些时间我会请同事私下[...]检查我的代码，以避免被公开展示。新的公司，新的挑战后来，我手边有了个新的机会。感谢曾经和我共事的朋友，我被 Babbel 邀请去参加初级 Android 工程师职位的招聘流程。我见到了他们的团队，同时自告奋勇的在他们办公室主持了一次本地会议。此事让我下定决心要申请这个职位。我喜欢公司的箴言：全民学习。其次，公司每个人都非常友善，在那儿工作看起来很愉快！但我没有马上申请，因为我认为自己不够好，所以为什么能申请呢？还好我的朋友和搭档推动我这样做，他们给了我发送简历的力量和勇气。过后不久就进入了面试流程。这很简单：以很小的程序的形式来进行编码挑战，随后是和团队一起的技术面试，之后是和招聘经理间关于团队合作的面试。招聘过程我用周未的时间来完成编码挑战的项目，并在周一就立即发送过去。不久就受邀去当场面试。技术面试是关于编程挑战本身，我们谈论了 Android 好的不好的地方、我为什么以这种方式实现这功能，以及如何改进等等。随后是招聘经理进行的一次简短的关于团队合作面试，也有涉及到编程挑战的事，我们谈到了我面临的挑战，我如何解决这些问题，等等。最后，通过面试，得到 offer，我授受了!我的 Android 工程师生涯的第一年，有九个月在一个公司，后面三个月在当前的公司。学习环境对我来说一个大的变化就是每两周会和工程经理进行面对面会谈。那样，我很清楚我们的目标和方向。在需要如何改进、需要如何提供帮助及如何寻求帮助这些事情上，我们得到持续的反馈和想法。他们除了提供内部培训的的福利外，我还有每周学习时间的福利，可以学习任意想学的。到目前为止，我正利用这些时间来提高我的 Kotlin 和 RxJava 方面知识。每日的大部分时间，我们也做结对编程。我的办公桌上总是备着纸和笔，以便记下想法。我旁边还配了第二把椅子，以方便同事就坐。:-)但是，我仍然在与冒充者综合征斗争。仍然有冒充者综合征我仍然在斗争。例如，在做结对编程时，当我对某个话题不太清楚时，即使我的同事很有耐心的一遍一遍为我解释，但有时我仍然还是不知道。两次三次后，压力就堵到胸口。为什么我还不知道？为什么就那么难理解？这种状态让我焦虑万分。我意识到我需要承认我确实不懂某个特定的主题，但第一步是要知道有这么个概念！有时，仅仅需要的就是更多的时间、更多的练习，最终会“在大脑中完全演绎” :-)例如，我常常为 Java 的接口类和抽象类所困扰，不管看了多少的例子，还是不能完全明白他们之间的区别。但一旦我使用后，即使还不能解释其工作原理，也知道了怎么使用以及什么时候使用。自信当前公司的学习氛围提升了我的自信心。即使我还在问很多问题，也开始如鱼得水了。经验较少并不意味着您的意见将不会被重视。比如一个提出的解决方案似乎太复杂了，我会挑战自我以更清晰的方式来重写。此外，我提出了一套不同的体验和观点，目前，对公司的应用程序用户体验改进有着很大帮助。提高工程师的角色不仅仅是编码，而是广泛的技能。 我仍然处于旅程的起点，在掌握它的道路上，我想着重于以下几点：交流：因为英文不是我的母语，所以有的时候我需要努力传达我的想法，这在我工作中是至关重要的。我可以通过写作，阅读和交谈来解决这个问题。提有建设性的反馈意见：我想给同事有意义的反馈，这样我们一起共同发展。为我的成就感到骄傲：我需要创建一个列表来跟踪各种成就，无论大小，或整体进步，所以当我挣扎时我可以回顾并感觉良好。不要着迷于不知道的事情：当有很多新事物出现时很难做到都知道，所以只关注必须的，及手头项目需要的东西，这非常重要的。多和同事分享知识：我是初级的并不意味着没有可以分享的！我需要持续分享我感兴趣的的文章及讨论话题。我知道同事们会感激我的。耐心和持续学习：和现在一样的保持不断学习，但对自己要有更多耐心。自我保健：随时注意休息，不要为难自己。 放松也富有成效。via: https://proandroiddev.com/a-year-as-android-engineer-55e2a428dfc8作者：Lara Martín 译者：runningwater 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
2016 年 10 月，当我从微软离职时，我已经在微软工作了近 21 年，在业界也快 35 年了。我花了一些时间反思我这些年来学到的东西，这些文字是那篇帖子稍加修改后得到。请见谅，文章有一点长。要成为一名专业的程序员，你需要知道的事情多得令人吃惊：语言的细节、API、算法、数据结构、系统和工具。这些东西一直在随着时间变化——新的语言和编程环境不断出现，似乎总有一些“每个人”都在使用的热门的新工具或新语言。紧跟潮流，保持专业，这很重要。木匠需要知道如何为工作选择合适的锤子和钉子，并且要有能力笔直精准地钉入钉子。与此同时，我也发现有一些理论和方法有着广泛的应用场景，它们能使用几十年。底层设备的性能和容量在这几十年来增长了几个数量级，但系统设计的思考方式还是互相有关联的，这些思考方式比具体的实现更根本。理解这些重复出现的主题对分析与设计我们所负责的系统大有帮助。谦卑和自我这不仅仅局限于编程，但在编程这个持续发展的领域，一个人需要在谦卑和自我中保持平衡。总有新的东西需要学习，并且总有人能帮助你学习——如果你愿意学习的话。一个人即需要保持谦卑，认识到自己不懂并承认它，也要保持自我，相信自己能掌握一个新的领域，并且能运用你已经掌握的知识。我见过的最大的挑战就是一些人在某个领域深入专研了很长时间，“忘记”了自己擅长学习新的东西。最好的学习来自放手去做，建造一些东西，即便只是一个原型或者 hack。我知道的最好的程序员对技术有广泛的认识，但同时他们对某个技术深入研究，成为了专家。而深入的学习来自努力解决真正困难的问题。端到端观点1981 年，Jerry Saltzer、 Dave Reed 和 Dave Clark 在做因特网和分布式系统的早期工作，他们提出了 端到端 end to end 观点，并作出了经典的阐述。网络上的文章有许多误传，所以更应该阅读论文本身。论文的作者很谦虚，没有声称这是他们自己的创造——从他们的角度看，这只是一个常见的工程策略，不只在通讯领域中，在其他领域中也有运用。他们只是将其写下来并收集了一些例子。下面是文章的一个小片段：当我们设计系统的一个功能时，仅依靠端点的知识和端点的参与，就能正确地完整地实现这个功能。在一些情况下，系统的内部模块局部实现这个功能，可能会对性能有重要的提升。该论文称这是一个“观点”，虽然在维基百科和其他地方它已经被上升成“原则”。实际上，还是把它看作一个观点比较好，正如作者们所说，系统设计者面临的最难的问题之一就是如何在系统组件之间划分责任，这会引发不断的讨论：怎样在划分功能时权衡利弊，怎样隔离复杂性，怎样设计一个灵活的高性能系统来满足不断变化的需求。没有简单的原则可以直接遵循。互联网上的大部分讨论集中在通信系统上，但端到端观点的适用范围其实更广泛。分布式系统中的“ 最终一致性 eventual consistency ”就是一个例子。一个满足“最终一致性”的系统，可以让系统中的元素暂时进入不一致的状态，从而简化系统，优化性能，因为有一个更大的端到端过程来解决不一致的状态。我喜欢横向拓展的订购系统的例子（例如亚马逊），它不要求每个请求都通过中央库存的控制点。缺少中央控制点可能允许两个终端出售相同的最后一本书，所以系统需要用某种方法来解决这个问题，如通知客户该书会延期交货。不论怎样设计，想购买的最后一本书在订单完成前都有可能被仓库中的叉车运出厍（LCTT 译注：比如被其他人下单购买）。一旦你意识到你需要一个端到端的解决方案，并实现了这个方案，那系统内部的设计就可以被优化以利用这个解决方案。事实上，这种设计上的灵活性可以优化系统的性能，或者提供其他的系统功能，从而使得端到端的方法变得如此强大。端到端的思考往往允许内部进行灵活的操作，使整个系统更加健壮，并且能适应每个组件特性的变化。这些都让端到端的方法变得健壮，并能适应变化。端到端方法意味着，添加会牺牲整体性能灵活性的抽象层和功能时要非常小心（也可能是其他的灵活性，但性能，特别是延迟，往往是特殊的）。如果你展示出底层的原始性能（LCTT 译注：performance，也可能指操作，下同），端到端的方法可以根据这个性能（操作）来优化，实现特定的需求。如果你破坏了底层性能（操作），即使你实现了重要的有附加价值的功能，你也牺牲了设计灵活性。如果系统足够庞大而且足够复杂，需要把整个开发团队分配给系统内部的组件，那么端到端观点可以和团队组织相结合。这些团队自然要扩展这些组件的功能，他们通常从牺牲设计上的灵活性开始，尝试在组件上实现端到端的功能。应用端到端方法面临的挑战之一是确定端点在哪里。 俗话说，“大跳蚤上有小跳蚤，小跳蚤上有更少的跳蚤……等等”。关注复杂性编程是一门精确的艺术，每一行代码都要确保程序的正确执行。但这是带有误导的。编程的复杂性不在于各个部分的整合，也不在于各个部分之间如何相互交互。最健壮的程序会将复杂性隔离开，让最重要的部分变的简单直接，通过简单的方式与其他部分交互。虽然隐藏复杂性和信息隐藏、数据抽象等其他设计方法一样，但我仍然觉得，如果你真的要定位出系统的复杂所在，并将其隔离开，那你需要对设计特别敏锐。在我的文章中反复提到的例子是早期的终端编辑器 VI 和 Emacs 中使用的屏幕重绘算法。早期的视频终端实现了控制序列，来控制绘制字符核心操作，也实现了附加的显示功能，来优化重新绘制屏幕，如向上向下滚动当前行，或者插入新行，或在当前行中移动字符。这些命令都具有不同的开销，并且这些开销在不同制造商的设备中也是不同的。（参见TERMCAP 以获取代码和更完整的历史记录的链接。）像文本编辑器这样的全屏应用程序希望尽快更新屏幕，因此需要优化使用这些控制序列来从一个状态到另一个状态屏幕转换。这些程序在设计上隐藏了底层的复杂性。系统中修改文本缓冲区的部分（功能上大多数创新都在这里）完全忽略了这些改变如何被转换成屏幕更新命令。这是可以接受的，因为针对任何内容的改变计算最佳命令所消耗的性能代价，远不及被终端本身实际执行这些更新命令的性能代价。在确定如何隐藏复杂性，以及隐藏哪些复杂性时，性能分析扮演着重要的角色，这一点在系统设计中非常常见。屏幕的更新与底层文本缓冲区的更改是异步的，并且可以独立于缓冲区的实际历史变化顺序。缓冲区是怎样改变的并不重要，重要的是改变了什么。异步耦合，在组件交互时消除组件对历史路径依赖的组合，以及用自然的交互方式以有效地将组件组合在一起是隐藏耦合复杂度的常见特征。隐藏复杂性的成功不是由隐藏复杂性的组件决定的，而是由使用该模块的使用者决定的。这就是为什么组件的提供者至少要为组件的某些端到端过程负责。他们需要清晰的知道系统的其他部分如何与组件相互作用，复杂性是如何泄漏出来的（以及是否泄漏出来）。这常常表现为“这个组件很难使用”这样的反馈——这通常意味着它不能有效地隐藏内部复杂性，或者没有选择一个隐藏复杂性的功能边界。分层与组件化系统设计人员的一个基本工作是确定如何将系统分解成组件和层；决定自己要开发什么，以及从别的地方获取什么。开源项目在决定自己开发组件还是购买服务时，大多会选择自己开发，但组件之间交互的过程是一样的。在大规模工程中，理解这些决策将如何随着时间的推移而发挥作用是非常重要的。从根本上说，变化是程序员所做的一切的基础，所以这些设计决定不仅要在当下评估，还要随着产品的不断发展而在未来几年得到评估。以下是关于系统分解的一些事情，它们最终会占用大量的时间，因此往往需要更长的时间来学习和欣赏。层泄漏。层（或抽象）基本上是泄漏的。这些泄漏会立即产生后果，也会随着时间的推移而产生两方面的后果。其中一方面就是该抽象层的特性渗透到了系统的其他部分，渗透的程度比你意识到得更深入。这些渗透可能是关于具体的性能特征的假设，以及抽象层的文档中没有明确的指出的行为发生的顺序。这意味着假如内部组件的行为发生变化，你的系统会比想象中更加脆弱。第二方面是你比表面上看起来更依赖组件内部的行为，所以如果你考虑改变这个抽象层，后果和挑战可能超出你的想象。层具有太多功能。您所采用的组件具有比实际需要更多的功能，这几乎是一个真理。在某些情况下，你决定采用这个组件是因为你想在将来使用那些尚未用到的功能。有时，你采用组件是想“上快车”，利用组件完成正在进行的工作。在功能强大的抽象层上开发会带来一些后果。组件往往会根据你并不需要的功能作出取舍。为了实现那些你并不没有用到的功能，组件引入了复杂性和约束，这些约束将阻碍该组件的未来的演变。层泄漏的范围更大。一些泄漏是由于真正的“抽象泄漏”，另一些是由于明显的，逐渐增加的对组件全部功能的依赖（但这些依赖通常都没有处理好）。Office 软件太大了，我们发现，对于我们建立的任何抽象层，我们最终都在系统的某个部分完全运用了它的功能。虽然这看起来是积极的（我们完全地利用了这个组件），但并不是所用的使用都有同样的价值。所以，我们最终要付出巨大的代价才能从一个抽象层往另一个抽象层迁移，这种“长尾”没什么价值，并且对使用场景认识不足。附加的功能会增加复杂性，并增加功能滥用的可能。如果将验证 XML 的 API 指定为 XML 树的一部分，那这个 API 可以选择动态下载 XML 的模式定义。这在我们的基本文件解析代码中被错误地执行，导致 w3c.org 服务器上的大量性能下降以及（无意）分布式拒绝服务攻击。（这些被通俗地称为“地雷”API）。抽象层被更换。需求在进化，系统在进化，组件被放弃。您最终需要更换该抽象层或组件。不管是对外部组件的依赖还是对内部组件的依赖都是如此。这意味着上述问题将变得重要起来。自己构建还是购买的决定将会改变。这是上面几方面的必然结果。这并不意味着自己构建还是购买的决定在当时是错误的。一开始时往往没有合适的组件，一段时间之后才有合适的组件出现。或者，也可能你使用了一个组件，但最终发现它不符合您不断变化的要求，而且你的要求非常窄、很好理解，或者对你的价值体系来说是非常重要的，以至于拥有自己的模块是有意义的。这意味着你像关心自己构造的模块一样，关心购买的模块，关心它们是怎样泄漏并深入你的系统中的。抽象层会变臃肿。一旦你定义了一个抽象层，它就开始增加功能。层是对使用模式优化的自然分界点。臃肿的层的困难在于，它往往会降低您利用底层的不断创新的能力。从某种意义上说，这就是操作系统公司憎恨构建在其核心功能之上的臃肿的层的原因——采用创新的速度放缓了。避免这种情况的一种比较规矩的方法是禁止在适配器层中进行任何额外的状态存储。微软基础类在 Win32 上采用这个一般方法。在短期内，将功能集成到现有层（最终会导致上述所有问题）而不是重构和重新推导是不可避免的。理解这一点的系统设计人员寻找分解和简化组件的方法，而不是在其中增加越来越多的功能。爱因斯坦宇宙几十年来，我一直在设计异步分布式系统，但是在微软内部的一次演讲中，SQL 架构师 Pat Helland 的一句话震惊了我。 “我们生活在爱因斯坦的宇宙中，没有同时性这种东西。”在构建分布式系统时（基本上我们构建的都是分布式系统），你无法隐藏系统的分布式特性。这是物理的。我一直感到远程过程调用在根本上错误的，这是一个原因，尤其是那些“透明的”远程过程调用，它们就是想隐藏分布式的交互本质。你需要拥抱系统的分布式特性，因为这些意义几乎总是需要通过系统设计和用户体验来完成。拥抱分布式系统的本质则要遵循以下几个方面：一开始就要思考设计对用户体验的影响，而不是试图在处理错误，取消请求和报告状态上打补丁。使用异步技术来耦合组件。同步耦合是不可能的。如果某些行为看起来是同步的，是因为某些内部层尝试隐藏异步，这样做会遮蔽（但绝对不隐藏）系统运行时的基本行为特征。认识到并且明确设计了交互状态机，这些状态表示长期的可靠的内部系统状态（而不是由深度调用堆栈中的变量值编码的临时，短暂和不可发现的状态）。认识到失败是在所难免的。要保证能检测出分布式系统中的失败，唯一的办法就是直接看你的等待时间是否“太长”。这自然意味着取消的等级最高。系统的某一层（可能直接通向用户）需要决定等待时间是否过长，并取消操作。取消只是为了重建局部状态，回收局部的资源——没有办法在系统内广泛使用取消机制。有时用一种低成本，不可靠的方法广泛使用取消机制对优化性能可能有用。认识到取消不是回滚，因为它只是回收本地资源和状态。如果回滚是必要的，它必须实现成一个端到端的功能。承认永远不会真正知道分布式组件的状态。只要你发现一个状态，它可能就已经改变了。当你发送一个操作时，请求可能在传输过程中丢失，也可能被处理了但是返回的响应丢失了，或者请求需要一定的时间来处理，这样远程状态最终会在未来的某个任意的时间转换。这需要像幂等操作这样的方法，并且要能够稳健有效地重新发现远程状态，而不是期望可靠地跟踪分布式组件的状态。“最终一致性”的概念简洁地捕捉了这其中大多数想法。我喜欢说你应该“陶醉在异步”。与其试图隐藏异步，不如接受异步，为异步而设计。当你看到像幂等性或不变性这样的技术时，你就认识到它们是拥抱宇宙本质的方法，而不仅仅是工具箱中的一个设计工具。性能我确信 Don Knuth 会对人们怎样误解他的名言“过早的优化是一切罪恶的根源”而感到震惊。事实上，性能，及性能的持续超过 60 年的指数增长（或超过 10 年，取决于您是否愿意将晶体管，真空管和机电继电器的发展算入其中），为所有行业内的惊人创新和影响经济的“软件吃掉全世界”的变化打下了基础。要认识到这种指数变化的一个关键是，虽然系统的所有组件正在经历指数级变化，但这些指数是不同的。硬盘容量的增长速度与内存容量的增长速度不同，与 CPU 的增长速度不同，与内存 CPU 之间的延迟的性能改善速度也不用。即使性能发展的趋势是由相同的基础技术驱动的，增长的指数也会有分歧。延迟的改进跟不上带宽改善。指数变化在近距离或者短期内看起来是线性的，但随着时间的推移可能是压倒性的。系统不同组件的性能的增长不同，会出现压倒性的变化，并迫使对设计决策定期进行重新评估。这样做的结果是，几年后，一度有意义的设计决策就不再有意义了。或者在某些情况下，二十年前有意义的方法又开始变成一个好的决策。现代内存映射的特点看起来更像是早期分时的进程切换，而不像分页那样。 （这样做有时会让我这样的老人说“这就是我们在 1975 年时用的方法”——忽略了这种方法在 40 年都没有意义，但现在又重新成为好的方法，因为两个组件之间的关系——可能是闪存和 NAND 而不是磁盘和核心内存——已经变得像以前一样了）。当这些指数超越人自身的限制时，重要的转变就发生了。你能从 2 的 16 次方个字符（一个人可以在几个小时打这么多字）过渡到 2 的 32 次方个字符（远超出了一个人打字的范围）。你可以捕捉比人眼能感知的分辨率更高的数字图像。或者你可以将整个音乐专辑存在小巧的磁盘上，放在口袋里。或者你可以将数字化视频录制存储在硬盘上。再通过实时流式传输的能力，可以在一个地方集中存储一次，不需要在数千个本地硬盘上重复记录。但有的东西仍然是根本的限制条件，那就是空间的三维和光速。我们又回到了爱因斯坦的宇宙。内存的分级结构将始终存在——它是物理定律的基础。稳定的存储和 IO、内存、计算和通信也都将一直存在。这些模块的相对容量，延迟和带宽将会改变，但是系统始终要考虑这些元素如何组合在一起，以及它们之间的平衡和折衷。Jim Gary 是这方面的大师。空间和光速的根本限制造成的另一个后果是，性能分析主要是关于三件事： 局部化 locality 、 局部化 locality 、 局部化 locality 。无论是将数据打包在磁盘上，管理处理器缓存的层次结构，还是将数据合并到通信数据包中，数据如何打包在一起，如何在一段时间内从局部获取数据，数据如何在组件之间传输数据是性能的基础。把重点放在减少管理数据的代码上，增加空间和时间上的局部性，是消除噪声的好办法。Jon Devaan 曾经说过：“设计数据，而不是设计代码”。这也通常意味着当查看系统结构时，我不太关心代码如何交互——我想看看数据如何交互和流动。如果有人试图通过描述代码结构来解释一个系统，而不理解数据流的速率和数量，他们就不了解这个系统。内存的层级结构也意味着缓存将会一直存在——即使某些系统层正在试图隐藏它。缓存是根本的，但也是危险的。缓存试图利用代码的运行时行为，来改变系统中不同组件之间的交互模式。它们需要对运行时行为进行建模，即使模型填充缓存并使缓存失效，并测试缓存命中。如果模型由于行为改变而变差或变得不佳，缓存将无法按预期运行。一个简单的指导方针是，缓存必须被检测——由于应用程序行为的改变，事物不断变化的性质和组件之间性能的平衡，缓存的行为将随着时间的推移而退化。每一个老程序员都有缓存变糟的经历。我很幸运，我的早期职业生涯是在互联网的发源地之一 BBN 度过的。 我们很自然地将将异步组件之间的通信视为系统连接的自然方式。流量控制和队列理论是通信系统的基础，更是任何异步系统运行的方式。流量控制本质上是资源管理（管理通道的容量），但资源管理是更根本的关注点。流量控制本质上也应该由端到端的应用负责，所以用端到端的方式思考异步系统是自然的。缓冲区膨胀的故事在这种情况下值得研究，因为它展示了当对端到端行为的动态性以及技术“改进”（路由器中更大的缓冲区）缺乏理解时，在整个网络基础设施中导致的长久的问题。我发现“ 光速 light speed ”的概念在分析任何系统时都非常有用。光速分析并不是从当前的性能开始分析，而是问“这个设计理论上能达到的最佳性能是多少？”真正传递的信息是什么，以什么样的速度变化？组件之间的底层延迟和带宽是多少？光速分析迫使设计师深入思考他们的方法能否达到性能目标，或者否需要重新考虑设计的基本方法。它也迫使人们更深入地了解性能在哪里损耗，以及损耗是由固有的，还是由于一些不当行为产生的。从构建的角度来看，它迫使系统设计人员了解其构建的模块的真实性能特征，而不是关注其他功能特性。我的职业生涯大多花费在构建图形应用程序上。用户坐在系统的一端，定义关键的常量和约束。人类的视觉和神经系统没有经历过指数性的变化。它们固有地受到限制，这意味着系统设计者可以利用（必须利用）这些限制，例如，通过虚拟化（限制底层数据模型需要映射到视图数据结构中的数量），或者通过将屏幕更新的速率限制到人类视觉系统的感知限制。复杂性的本质我的整个职业生涯都在与复杂性做斗争。为什么系统和应用变得复杂呢？为什么在一个应用领域内进行开发并没有随着时间变得简单，而基础设施却没有变得更复杂，反而变得更强大了？事实上，管理复杂性的一个关键方法就是“走开”然后重新开始。通常新的工具或语言迫使我们从头开始，这意味着开发人员将工具的优点与从新开始的优点结合起来。从新开始是重要的。这并不是说新工具，新平台，或新语言可能不好，但我保证它们不能解决复杂性增长的问题。控制复杂性的最简单的方法就是用更少的程序员，建立一个更小的系统。当然，很多情况下“走开”并不是一个选择——Office 软件建立在有巨大的价值的复杂的资源上。通过 OneNote， Office 从 Word 的复杂性上“走开”，从而在另一个维度上进行创新。Sway 是另一个例子， Office 决定从限制中跳出来，利用关键的环境变化，抓住机会从底层上采取全新的设计方案。我们有 Word、Excel、PowerPoint 这些应用，它们的数据结构非常有价值，我们并不能完全放弃这些数据结构，它们成为了开发中持续的显著的限制条件。我受到 Fred Brook 讨论软件开发中的意外和本质的文章《没有银弹》的影响，他希望用两个趋势来尽可能地推动程序员的生产力：一是在选择自己开发还是购买时，更多地关注购买——这预示了开源社区和云架构的改变；二是从单纯的构建方法转型到更“有机”或者“生态”的增量开发方法。现代的读者可以认为是向敏捷开发和持续开发的转型。但那篇文章可是写于 1986 年！我很欣赏 Stuart Kauffman 的在复杂性的基本性上的研究工作。Kauffman 从一个简单的布尔网络模型（“NK 模型”）开始建立起来，然后探索这个基本的数学结构在相互作用的分子，基因网络，生态系统，经济系统，计算机系统（以有限的方式）等系统中的应用，来理解紧急有序行为的数学基础及其与混沌行为的关系。在一个高度连接的系统中，你固有地有一个相互冲突的约束系统，使得它（在数学上）很难向前发展（这被看作是在崎岖景观上的优化问题）。控制这种复杂性的基本方法是将系统分成独立元素并限制元素之间的相互连接（实质上减少 NK 模型中的“N”和“K”）。当然对那些使用复杂隐藏，信息隐藏和数据抽象，并且使用松散异步耦合来限制组件之间的交互的技术的系统设计者来说，这是很自然的。我们一直面临的一个挑战是，我们想到的许多拓展系统的方法，都跨越了所有的方面。实时共同编辑是 Office 应用程序最近的一个非常具体的（也是最复杂的）例子。我们的数据模型的复杂性往往等同于“能力”。设计用户体验的固有挑战是我们需要将有限的一组手势，映射到底层数据模型状态空间的转换。增加状态空间的维度不可避免地在用户手势中产生模糊性。这是“纯数学”，这意味着确保系统保持“易于使用”的最基本的方式常常是约束底层的数据模型。管理我从高中开始担任一些领导角色（学生会主席！），对承担更多的责任感到理所当然。同时，我一直为自己在每个管理阶段都坚持担任全职程序员而感到自豪。但 Office 软件的开发副总裁最终还是让我从事管理，离开了日常的编程工作。当我在去年离开那份工作时，我很享受重返编程——这是一个出奇地充满创造力的充实的活动（当修完“最后”的 bug 时，也许也会有一点令人沮丧）。尽管在我加入微软前已经做了十多年的“主管”，但是到了 1996 年我加入微软才真正了解到管理。微软强调“工程领导是技术领导”。这与我的观点一致，帮助我接受并承担更大的管理责任。主管的工作是设计项目并透明地推进项目。透明并不简单，它不是自动的，也不仅仅是有好的意愿就行。透明需要被设计进系统中去。透明工作的最好方式是能够记录每个工程师每天活动的产出，以此来追踪项目进度（完成任务，发现 bug 并修复，完成一个情景）。留意主观上的红/绿/黄，点赞或踩的仪表板。我过去说我的工作是设计反馈回路。独立工程师，经理，行政人员，每一个项目的参与者都能通过分析记录的项目数据，推进项目，产出结果，了解自己在整个项目中扮演的角色。最终，透明化最终成为增强能力的一个很好的工具——管理者可以将更多的局部控制权给予那些最接近问题的人，因为他们对所取得的进展有信心。这样的话，合作自然就会出现。关键需要确定目标框架（包括关键资源的约束，如发布的时间表）。如果决策需要在管理链上下不断流动，那说明管理层对目标和约束的框架不好。当我在 Beyond Software 工作时，我真正理解了一个项目拥有一个唯一领导的重要性。原来的项目经理离职了（后来从 FrontPage 团队雇佣了我）。我们四个主管在是否接任这个岗位上都有所犹豫，这不仅仅由于我们都不知道要在这家公司坚持多久。我们都技术高超，并且相处融洽，所以我们决定以同级的身份一起来领导这个项目。然而这槽糕透了。有一个显而易见的问题，我们没有相应的战略用来在原有的组织之间分配资源——这应当是管理者的首要职责之一！当你知道你是唯一的负责人时，你会有很深的责任感，但在这个例子中，这种责任感缺失了。我们没有真正的领导来负责统一目标和界定约束。我有清晰地记得，我第一次充分认识到倾听对一个领导者的重要性。那时我刚刚担任了 Word、OneNote、Publisher 和 Text Services 团队的开发经理。关于我们如何组织文本服务团队，我们有一个很大的争议，我走到了每个关键参与者身边，听他们想说的话，然后整合起来，写下了我所听到的一切。当我向其中一位主要参与者展示我写下的东西时，他的反应是“哇，你真的听了我想说的话”！作为一名管理人员，我所经历的所有最大的问题（例如，跨平台和转型持续工程）涉及到仔细倾听所有的参与者。倾听是一个积极的过程，它包括：尝试以别人的角度去理解，然后写出我学到的东西，并对其进行测试，以验证我的理解。当一个关键的艰难决定需要发生的时候，在最终决定前，每个人都知道他们的想法都已经被听到并理解（不论他们是否同意最后的决定）。在 FrontPage 团队担任开发经理的工作，让我理解了在只有部分信息的情况下做决定的“操作困境”。你等待的时间越长，你就会有更多的信息做出决定。但是等待的时间越长，实际执行的灵活性就越低。在某个时候，你仅需要做出决定。设计一个组织涉及类似的两难情形。您希望增加资源领域，以便可以在更大的一组资源上应用一致的优先级划分框架。但资源领域越大，越难获得作出决定所需要的所有信息。组织设计就是要平衡这两个因素。软件复杂化，因为软件的特点可以在任意维度切入设计。Office 软件部门已经使用共享团队来解决这两个问题（优先次序和资源），让跨领域的团队能与需要产品的团队分享工作（增加资源）。随着管理阶梯的提升，你会懂一个小秘密：你和你的新同事不会因为你现在承担更多的责任，就突然变得更聪明。这强调了整个组织比顶层领导者更聪明。赋予每个级别在一致框架下拥有自己的决定是实现这一目标的关键方法。听取并使自己对组织负责，阐明和解释决策背后的原因是另一个关键策略。令人惊讶的是，害怕做出一个愚蠢的决定可能是一个有用的激励因素，以确保你清楚地阐明你的推理，并确保你听取所有的信息。结语我离开大学寻找第一份工作时，面试官在最后一轮面试时问我对做“系统”和做“应用”哪一个更感兴趣。我当时并没有真正理解这个问题。在软件技术栈的每一个层面都会有趣的难题，我很高兴深入研究这些问题。保持学习。via: https://hackernoon.com/education-of-a-programmer-aaecf2d35312作者：Terry Crowley 译者：explosic4 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
HackerRank 最近公布了 2018 年开发者技能报告的结果，其中向程序员询问了他们何时开始编码。39,441 名专业人员和学生开发者于 2016 年 10 月 16 日至 11 月 1 日完成了在线调查，超过 25％ 的被调查的开发者在 16 岁前编写了他们的第一段代码。（LCTT 译注：日期恐有误）程序员是如何学习的报告称，就程序员如何学习编码而言，自学是所有年龄段开发者的常态。“尽管 67％ 的开发者拥有计算机科学学位，但大约 74％ 的人表示他们至少一部分是自学的。”开发者平均了解四种语言，但他们想学习更多语言。对学习的渴望因人而异 —— 18 至 24 岁的开发者计划学习 6 种语言，而 35 岁以上的开发者只计划学习 3 种语言。程序员想要什么HackerRank 还研究了开发者最想从雇主那里得到什么。平均而言，良好的工作与生活平衡，紧随其后的是专业成长与学习，是最理想的要求。按地区划分的数据显示，美国人比亚洲和欧洲的开发者更渴望工作与生活的平衡。学生倾向于将成长和学习列在工作与生活的平衡之上，而专业人员对薪酬的排名比学生高得多。在小公司工作的人倾向于降低工作与生活的平衡，但仍处于前三名。年龄也制造了不同，25 岁以上的开发者将工作与生活的平衡评为最重要的，而 18 岁至 24 岁的人们则认为其重要性较低。HackerRank 说：“在某些方面，我们发现了一个小矛盾。开发人员需要工作与生活的平衡，但他们也渴望学习“。它建议，专注于做你喜欢的事情，而不是试图学习一切，这可以帮助实现更好的工作与生活的平衡。via: https://mybroadband.co.za/news/smartphones/246583-how-programmers-learn-to-code.html作者：Staff Writer 译者：geekpi 校对：wxy本文由 LCTT 原创编译，Linux中国 荣誉推出
测试覆盖 （ Testing coverage ） ，指测试系统覆盖被测试系统的程度，一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。 如果在写代码的人仅为可运行而编码，那么在后边会出现一系列的连锁反应，任何没有经过真构思之后书写的代码，都会带来巨大的维护成本吧。昨天 (2017.09.05) 刚刚读到一篇 为什么你的前段工作经验不值钱，不同的人对这里边的那个题的考虑程度是不同的。但我们在每次开始编码之前，都应该以 “代码可用 - 代码健壮 - 代码可靠 - 对需求的宽容” 为规格来约束自己。译者简介：GHLandy —— 生活中所有欢乐与苦闷都应藏在心中，有些事儿注定无人知晓，自己也无从说起。via: http://turnoff.us/geek/the-depressed-developer-17/作者：Daniel Stori 译者：GHLandy 校对：wxy 合成：GHLandy 点评：GHLandy本文由 LCTT 原创编译，Linux中国 荣誉推出
哎，又是 Bug 和 Debug！ 感觉代码之中永远脱离不了这个魔咒啊！还真是尴尬。不知道，编码之间进行详细的规划，能不能尽量避免那些不必要的 Bug？译者简介：GHLandy —— 生活中所有欢乐与苦闷都应藏在心中，有些事儿注定无人知晓，自己也无从说起。via:http://turnoff.us/geek/the-depressed-developer-16/作者：Daniel Stori 译者：GHLandy 校对：wxy 合成：GHLandy 点评：GHLandy本文由 LCTT 原创编译，Linux中国 荣誉推出