敏捷方法论和项目管理
查看所有标签
在现代的数据驱动时代，获取和管理网上信息变得至关重要。为企业和开发者提供强大支持的，Crawlab出现了，它是一个企业级的爬虫管理平台，特点是开箱即用。无论您的团队规模大小，Crawlab都能为您提供专业和高效的爬虫管理解决方案。
Crawlab的核心功能包括分布式系统管理、爬虫任务管理和调度、文件编辑、消息通知、依赖管理、Git集成以及性能监控等多方面。其中，它的分布式节点管理让爬虫程序能够在多台服务器上高效运行。再也不用担心手动上传、监控和部署的麻烦，Crawlab将这一切全部自动化，确保您能轻松调度爬虫任务，并实时查看爬虫程序的运行状态以及任务日志。
特别值得一提的是，Crawlab提供在线编辑爬虫代码的功能，支持主流编程语言高亮显示，让您轻松调试爬虫程序。此外，它还提供了Crontab风格的定时任务设置，让您能在指定时间自动执行爬虫任务，极大提高了工作效率。
复杂度是软件工程中永恒的挑战。随着项目规模的增长，复杂度会以指数级的速度增加，如果不加以控制，最终会导致项目的失败。
在软件开发的世界里，复杂度无处不在。从简单的"Hello World"程序到大型分布式系统，复杂度始终伴随着我们的开发过程。作为软件架构师和技术负责人，理解复杂度的本质、来源以及如何管理复杂度，是我们必须掌握的核心技能。
“今天加一下班把这个需求做了吧，老板催得很急。”--某时某厂某项目经理
敏捷，这个曾经作为灵活速度的代名词，在过去 20 年里逐渐发展成为 IT 界中被程序员们时常挂在嘴边的看似深奥的专业术语。敏捷开发（Agile Development）作为很多开发团队的项目管理框架首选，因为其简单、灵活，更重要的是它字面上暗示着 “快”。想一想无数码农为了赶进度而无偿加班吧。
当你的开发团队遭遇项目延期、产品质量降低、士气低下以及客户关系恶化时，你的朋友或许会推荐你使用敏捷开发：“嘿，兄弟。我听说最近敏捷挺火的，你可以试一下。” 但是，当你在团队中推行敏捷一段时间后，你很可能会发现它并不好使：产品发布后依旧大量的bug、无穷无尽的加班、源源不断的最高优先级需求。在与老板的日常会议中，老板问你：“听说你们正在用敏捷来提升交付效率，很棒！所以我下周能看到之前给你提的重要功能吗？”
“敏捷就是快速交付”，这是很多敏捷实践者中最大的误区。其实，敏捷并不一定意味着快；相反，它还会引入更多额外工作，从而可能导致更慢的交付功能。对，你没看错。严格意义来说，敏捷会降低交付速度。例如，极限编程（XP，敏捷框架之一）要求为每一个功能编写单元测试，这会引入 1-2 倍的额外代码。
A bad plan is better than no plan.
坏计划也好过没有计划。--彼得·蒂尔《从0到1》
在软件开发工程中，很少会有单打独斗的程序员。这是因为现代较常见的软件项目通常都非常复杂，所要求的人力、资源、时间也比较多，仅由一个开发者来完成大型软件项目无异于 “愚公移山”。因此，软件开发通常离不开团队协作和项目管理。所谓项目管理（Project Management），简单来就是有序的组织、规划、执行并完成项目中各个任务的一种方法论。当然，实际项目管理的范畴还远不止这些，通常还会涉及资源调配、优先级制定、进度追踪等。它是工业革命的产物，也是现代管理学的分支，它能够大幅提高工程完成效率以及成功率。本文讨论的主要是软件项目管理，相较于传统的建筑工程、机械工程等项目管理有很大的不同。早期的 IT 项目管理来自于建筑工程等传统项目管理方法论，在信息时代早期扮演了重要的角色，大幅提高了软件开发和协同效率。然而，随着 IT 行业高速发展，消费者产品需求瞬息万变，市场形势变得越来越不确定（Volatile），传统的软件项目管理模式已经不能再满足软件开发需求。因此，现代软件开发模式，例如敏捷开发（Agile Development），应运而生，成为了很多互联网企业的首选。
传统项目管理模式（例如瀑布流）有什么弊端？现代项目管理模式（例如敏捷）又有什么改进？我们是否应该完全摈弃瀑布流模式，全面拥抱敏捷开发？作为一个程序员，是否应该掌握一些项目管理知识以及相关工具？作为一个团队领导，应该如何制定项目管理流程保证开发效率和质量？如果读者有类似上述问题的疑惑，本篇文章将为您详细分析和解答。
The most incomprehensible thing about the world is that it is comprehensible.
世界上最不可理解的地方就是它竟然是可以理解的。-- 阿尔伯特·爱因斯坦
开源（Open-Source）造就了如今繁荣活跃的软件行业。开源让全世界的开发者都能够协力编写出优秀的工具类项目，也就是所谓的 "轮子"，在造福大大小小的公司个人的同时，也可以展现创作者或贡献者的技术实力。如今很多开发者都在大量使用开源项目作为自己项目的第三方库或依赖，更快更高效的完成开发任务。
笔者也不例外。我最近在用 Vue 3 重构 Crawlab 前端的时候，用到了 Element 团队开发的升级版的 ElementUI，也就是 Vue 3 重构的新 UI 框架 Element Plus。Element 团队在 Element Plus 中将该项目用 Vue 3 完全重构，全面拥抱了 TypeScript；而且相比于之前的 Vue 2 版本丰富了部分组件；而整体风格和使用方式跟之前的版本一致；一些 API 在使用上还变得更精简了。因此，笔者在重构 Crawlab 前端初期过程中没有遇到太大的障碍，再加上之前的编写经验，开发过程中显得驾轻就熟。然而，好景不长，随着项目的不断开发，笔者遭遇到一些技术上的困难。更准确的说，在实现一些复杂功能时遇到了来自于 Element Plus 框架本身的限制。虽然最终想方设法将问题解决了，但是我也深刻体会到了硬啃（Hacking）开源项目源代码的困难。因此，也希望借此机会将自己驾驭开源代码的经验分享给读者。
The only constant in the world is change.
世界上唯一不变的是变化。--《谁动了我的奶酪》作者 斯宾塞·约翰逊
IT 行业变化太快了，尤其是前端开发（Frontend Development）。如果能穿越回 10 年前，碰上一位 Web 开发软件工程师，他一定会告诉你玩转前端就是精通 jQuery 和搞定 IE 浏览器兼容性。不过随着前端的不断发展，jQuery 遭遇 “官方逼死同人” 逐渐退出历史舞台（元素选择和操作被标准的 DOM API 所统一）；而饱为诟病的 IE 浏览器兼容性问题，因为 IE 市场的逐渐萎缩以及一些兼容性工具（Polyfill）的出现，让其从之前的核心优化问题降级为如今的瘙痒问题，不再成为前端工程师的标配。
如今的前端开发，有着玲琅满目的专业术语和纷繁复杂的技术生态，可能会让初入前端开发的工程师感到惴惴不安：要学的东西实在是太多了。现在的前端工程师如果不了解 Webpack、Babel、Node.js、NPM/Yarn、ES6/7、React/Vue、Sass/Less、TypeScript、ESLint、Canvas/SVG 等现代化前端知识，就难以让人信服自己的专业背景。2021 年的前端工程师可能是真正意义上的工程师（Engineer），他们通常需要运用大量的专业知识来解决工程化问题，包括如何将项目进行模块化，如何设计组件间的交互，如何提高可复用性，如何提升打包效率，优化浏览器渲染性能，等等。他们不再像以前，只需要 HTML/CSS/JS 一个套路来开发静态页面。
本文将着重就现代前端开发的主题，来详细介绍前端工程化的各个重要技术，帮助读者了解现代前端页面的复杂和多样性是如何构造的。本文是一篇关于前端工程的科普文，即使你不了解前端技术，也可以从本文受益。
工欲善其事，必先利其器 --《论语》
在如今被三大框架支配的前端领域，已经很少有人不知道 Vue 了。2014 年，前 Google 工程师尤雨溪发布了所谓的渐进式（Progressive）前端应用框架 Vue，其简化的模版绑定和组件化思想给当时还是 jQuery 时代的前端领域产生了积极而深远的影响。Vue 的诞生，造福了那些不习惯 TS 或 JSX 语法的前端开发者。而且，Vue 较低的学习门槛，也让初学者非常容易上手。这也是为什么 Vue 能在短时间内迅速推广的重要原因。从 State of JS 的调查中可以看到，Vue 的知名度接近 100%，而且整体用户满意度也比较高。
Vue 既强大又易学，这是不是意味着 Vue 是一个完美框架呢？很遗憾，答案是否定的。虽然 Vue 的上手门槛不高，灵活易用，但是这种优势同时也成为了一把双刃剑，为构建大型项目带来了一定的局限性。很多用 Vue 2 开发过大型项目的前端工程师对 Vue 是又爱又恨。不过，随着 Vue 3 的发布，这些开发大型项目时凸显出来的劣势得到了有效解决，这让 Vue 框架变得非常全能，真正具备了跟 "前端框架一哥" React 一争高下的潜力。Vue 3 究竟带来了什么重要的新特性呢？本篇文章将对此进行详细介绍。