软件开发 – 第45页小小书 XXshu

12个技巧，如何清理项目中的所有错误

在本文中，我想总结一下我们在7个月内如何创建完整产品的经验。如果您不确定我们的资料对您没有用，请不要犹豫。在DueFocus开发的初始阶段，我们面临着与大多数有雄心壮志但还没有足够的经验来及时正确地完成一切工作的团队相同的问题。我们有很多没有运行遗留代码的地方，而只有一小部分产品文档。我们的重新开放率接近30％（有时甚至更高）。目前，我们正处于发布前阶段，我们的结果已达到我们的期望。现在， DueFocus是完美无缺且功能强大的生产力助手，可帮助有效地跟踪时间和控制团队，简化并增强公司的内部流程。它可以与所有最常用的任务管理器进行同步，从而提高生产率并更好地组织管理。但是，为什么您的“超级巨星”开发人员会产生如此多的错误，并且暂时无法创建产品的稳定版本。错误出现的所有原因我们可以分为两个部分： 1.在项目需求收集阶段的误解。沟通流程组织不善。这包括：描述不佳的技术要求；对产品功能以及开发人员将与之交互的整个系统的理解不足；在项目管理和开发方面缺乏沟通和透明度。 2.开发过程中的人为错误。…

有助于技术写作的软技能

软技能通常在技术写作中被忽略。人们只有在情况严重时才开始认真对待他们。就像，当您意识到自己的时间管理能力很差，以至于影响了您的职业发展。积极主动地运用软技能真是太棒了，因为它们可以使您的职业生涯变得更加轻松，防止倦怠并提高绩效。在本文中，我们将讨论技术作家的软技能以及如何从今天开始开发它们。通讯技术作家需要进行的交流远远超过了人们的想象。 Doc团队可以与公司中的任何部门进行与工作相关的对话，但是，当然，主要的沟通渠道可以导致主题专家或SME的简称。交流作为一个概念包含许多方面。让我们看一下其中的一些：提出正确问题的能力。一项非常重要的技能。提出正确的问题后，答案将更加明确，并且您将花费更少的时间对所获得的所有信息进行系统化和分类。忍耐。每个人都是不同的，这给清除自己的沟通造成了障碍。最重要的是，我们只是人类，所以情绪波动和个人事务也会干扰。即使是我们最好的人，也不一定总是能够阻止我们的内心状态影响我们的工作。因此，您应该对他人和您自己保持耐心。…

初级，中级和高级开发人员走进酒吧，他们订购了ALTER表

Dan Gold在Unsplash上拍摄的照片齐聚一堂，让我告诉你那段时间，我的队友和我取消了该平台最关键的服务之一。为了叙述起见，我将同事命名为 S （高级）和 M （中级），但我更改了日期和一些技术细节，以尽可能地保持匿名。 T’是2016年7月底一个漂亮的星期四下午。天气比以前几天要温和，我的队友和我刚搬到办公室的新地方。生活大都是美好的。前一周没有我们最高级的开发人员S参加，但我和M设法独自完成了一些任务。这些更改包含一些相当繁重的内容（新的数据库字段，新的端点），因此我们决定在合并它们之前等待S的审查。数据库更改和迁移脚本同时，另一位开发人员检查了所做的更改，并提到迁移脚本中的操作对于数据库服务器可能是很多工作，并且可能会使其锁定一段时间。因此，他提出了一些替代方案。如果您不知道什么是数据库迁移，那么将使用一系列SQL脚本（按顺序执行）从头开始创建整个数据库架构（表，列，默认值，约束等）。通常，它们在每个部署上运行，但前提是要应用新的东西，即新的迁移文件。我们不想将更改作为迁移来运行，因为那样的话，更改将由我们的持续集成系统执行，并且完全不受我们的控制。…

作为开发人员，我惯于shoot脚

中断，上下文切换，微观管理，有许多外部因素会影响开发人员的工作效率。我不会谈论这些。我将谈论我做错的所有事情以及如何修正自己的行为。不了解背景添加功能请求时，我最常见的错误之一是不了解需求的上下文。目标是什么？为什么要求此功能？它试图解决什么？有什么期望？未来的计划是什么？了解了这些答案（以示例为例），我可以理解我的主要精力应该放在哪里。了解了这个问题后，我可以从另一角度看到功能请求。我不会尝试涵盖所有不必要的情况（并夸大我的ETA）。我可以简单地处理消息，通知，警报等附带问题；而不是通过开发试图解决初始请求之外的问题的整个系统。如果功能请求是实验的一部分，如果尚未决定未来的计划，并且它依赖于初始版本的性能，那么我可以以其他方式设计代码。我可以专注于交付的速度，限制我的重构，使用现有的方法和类，而不必追求旨在无限扩展的完美代码。过度思考，过度行动，恐慌…

测试驱动的开发根本不涉及测试

如果您问我从肯特·贝克（Kent Beck）2003年的书中学到的关于测试驱动开发的最意外的事情是什么，那么我将确切地知道该怎么回答。它也可能会让您感到惊讶，所以跳进去，让我们尝试从另一个角度看一下。当您第一次听说TDD时，您如何看待它？我记得这种感觉很好：这是“不，你不能认真对待，我该如何测试我什至还没有实现的东西？”的混合体，一种呆滞的感觉，“上帝，编写测试是太难了”和一点点耻辱，因为“优秀的程序员会执行自动化测试”，而我根本没有做太多的测试。大概是十年前，那时我还在大学三年级，几乎没有任何“工业”经验。 TDD和其他敏捷思想正朝着阻塞软件开发流程的现代问题发展，这远非俄罗斯计算机科学专业的学生所理解。 TDD还对在实际项目中在地球上如何可行提出了疑问。那你为什么决定读这本书？几年后，我找到了我的第一份“工业”工作：那是一家俄罗斯大型互联网公司的测试软件工程师。在很短的时间内，我看到了许多质量各异的代码，这些代码大多数时候都在巨大的负载下工作，并为公司带来了可观的收益。我主要从外部探索代码，因为我最关心的是如何调用返回用户得分的服务，或者如何使数据处理守护程序以单进程模式启动，以便其行为至少在可预测期间可预测。测试。但是我也偶然地窥视了内部。我应该说这在大多数情况下是结构不良，难以理解的–塔达！ -没有单元测试？我对自己问的问题是，TDD似乎很有道理，为什么不将其应用于此处？离开后，我去寻找答案-在书的页面上。最后，最出乎意料的是什么？…

程序员的6种职业助推器

我有近十年的软件工程师经验，在此期间，我已经经历了许多使我成长为专业人士的情况。在本文中，我想分享一些技巧，您可以立即开始应用这些技巧，以便快速成长为软件开发人员。您是否曾经对同事感到嫉妒？他做了一件了不起的事，而您希望是您。冷静下来，这是从我们的人性以及社会传递给我们的信息中得出的。如果您考虑一下，这并不会给您带来任何好处，确实这对您的职业生涯是非常不利的，您应该了解，与能做出令人惊奇的事情的人一起工作会使您接近做类似的事情。了解了您可以做的事情之后，请与同事聊天，分享一些想法，提出一些建议并提供帮助。如果您在一个健康的公司，这将是一个非常自然的过程。另一方面，如果您的公司中没有这种环境，请努力工作，您会吸引这家公司进入您的生活。将同事视为盟友而不是敌人的另一个好处是，建立了乐于与您合作的人际网络。这在将来可能很有价值。这是一个非常有争议的话题。我看到太多的程序员崇拜一种编程语言，而忽略其余的编程语言，我认为这太糟糕了。让我来告诉你为什么… 当您崇拜某物时，您便成为该物的奴隶。不应该是逆数吗？您应该使用一种语言作为您的奴隶，而不能成为一种语言的奴隶。如何克服呢？…

文档化的文档化宣言：如何在敏捷团队中维护文档

如果一家科技公司没有每隔15分钟就谈论他们如何成为“快节奏，敏捷的工作环境”，那么他们实际上是一家科技公司吗？撇开所有笑话，我真的很欣赏敏捷的哲学。以结果为导向的项目，迭代式开发，自我授权，协作和信任都构成了一个出色的工作环境。但是，我想讨论敏捷宣言的四个价值之一：工作软件胜过全面文档正在编写1.4.03版补丁说明的初稿在最初启发“ 宣言 ”的背景下，这种说法很有道理。呆滞在滑雪场上重塑发展实践的17个人来自疲软的公司环境。除了支持其他无意义的流程之外，对那些没有贡献任何现实价值的流程进行的巨大投资令人心碎。文档仅凭现有的优点就可以存在，并且随着给定业务中技术的变化，它很快失去了价值。对于想要以不同方式拥抱工作的人们，采取这种立场既大胆又振奋。但是，我认为行业很容易误解敏捷原则，因为它是一种工作哲学，而不是具体过程。 Scrum方法论可能是最流行的敏捷原则框架，但是即使该框架也被明确设计为开放式的。敏捷的好处同时为滥用提供了机会。对于半完成的项目，业务可以证明对功能需求进行枢轴调整是合理的，因为它们包含对变更的响应。…

“加拿大没有开展足够的创新”

照片来自Unsplash 在加拿大的IT行业工作了近15年之后，得知失败的IT项目（如护照处理系统，Phoenix Pay系统和加拿大政府的Web续订项目）中浪费的钱，这真是令人伤心和尴尬。我什至不知道从哪里开始解释这是多么残酷，但我想我首先要看CBC新闻网站上资深记者Dean Beeby的一篇文章，标题是渥太华经常转向美国科技巨头。我认为尝试找出导致渥太华一直不了解IT项目运作方式以及如何去寻找合适的加拿大供应商的原因可能是有用的（技术代表着寻找合适的加拿大技术合作伙伴）。让我们开始吧… 长期以来，加拿大的本土科技公司一直抱怨渥太华会继续寻求像IBM这样的大型美国公司来满足其对信息技术的需求-一份内部联邦报告表明它们是正确的。这不仅是渥太华的问题，也是省级的问题。很棒的是，至少有一份内部联邦报告确认了手头的问题。如果有机会，请向IBM员工询问这种情况。这很滑稽。他们将坚持要求他们与加拿大的任何中小型IT公司都处于相同的严格采购或建议书（RFP）流程之下。唯一的区别？他们有一支游说采购的顾问大军。不幸的是，在提案和RFP方面，像我这样的大多数小型加拿大IT公司可能只有一两个人来回应RFP。本文将继续引用加拿大首席信息官Alex Benay的评论。…

我对DevOps Journeys 2.0的贡献

我认为与您共享电子书可能会有所帮助，因为对于那些对DevOps和现代软件/基础设施工程的未来感兴趣的人们，它具有宝贵的内容，分享我自己的贡献并获得您的反馈。您可以在此处阅读完整的电子书。这些是我的贡献：关于DevOps DevOps是一种文化，它需要一种新的愿景，其共同目标是通过建立正确的沟通流程和跨职能协作，将人员和部门围绕独特的目标统一起来。这些文化特征之一就是以客户为中心：以客户为中心是使团队朝着相同的重要目标结盟而又不会引起部门间战争的最佳方式。” 关于采用DevOps 正如Aymen El Amri所说的那样，DevOps始于流程：“采用DevOps需要由合适的人使用正确的工具来完成正确的流程”。关于我的早期经历 Aymen El Amri谈论了他在DevOps项目上的早期经验，研究了“困难的问题，（奇妙但不成熟的）技术和一些误解”： “但是我并不孤单，一个不断发展的社区正在解决类似的问题，这些人奠定了基础，并使DevOps引入从初创公司到公司的所有类型的公司成为可能。” DevOps是一项社区运动，网络会议，聚会和论坛的迅速发展为寻找解决问题的方法提供了巨大的机会，越来越多的工程师可以将灵感带回他们的组织。关于正确的工程DevOps转型 DevOps是一个令人兴奋的领域，面临许多挑战，例如零停机时间部署，自我修复和自动扩展性。…

要学习新的编程语言，请重新开始

最初发布在 http://www.mberlove.com/blog/a-new-programming-language-starting-over/ 程序员以其容易学习新技能的能力而感到自豪，他们依靠根深蒂固的概念和抽象的方法来以最小的难度找到一种新的工作方式。在工具，语言或环境之间进行平滑切换是一种引以为傲的能力，但这并不总是那么有趣：即使对于那些喜欢学习新技能的人，以这种方式更改环境也会给生产力带来压力。经过多年的学习，培训和工作，所有社区和背景的开发人员都倾向于使用理想的语言，独特的编码风格，个人工作习惯等，这不足为奇。这些偏好在日常工作中表现出来，并嵌入到代码的结构中。也许这就是为什么要过渡到全新的系统会很困难的原因-不仅是获得新技能或学习使用其他工具；还包括开发人员往往擅长于此。相反，由于系统和过程的差异，它要求开发人员重新发明自己。无论是过渡到新工作还是只是改变一种更适合项目目标的语言和环境，学习用一种新语言表达自己的感觉就像是在漫长的休假后第一次锻炼：您还记得一切应该如何工作，但一切都变了。我已经为这种过渡苦苦挣扎了很多次，而且总是有些痛苦—我认为我们永远都不会摆脱它。但是随着时间的流逝，我发现有一些策略可以使您更快地启动并运行，并且减少挫败感。 1.至少在开始时，假装不知道如何编码。您可能从我出生之前就一直在编写代码，但是您的新语言并不知道。很容易假设您可以跳过基础知识，因为许多面向对象的语言在总体上都是相似的。不要成为这个陷阱的牺牲品！您可能是95％正确的人，但是错过了5％的人会在您不期望且负担不起的情况下使您陷入困境。处理您的表现。阅读或听取针对假定的新鲜辅料的材料还将使您深入了解该语言及其用法所固有的细微差别和假设。…