Week 4, year 2021

Bliki: RefinementCodeReview - When people think of code reviews, they usually think in terms of an explicit step in a development team's workflow. These days the Pre-Integration Review, carried out on a Pull Request is the most common mechanism for a code review, to the point that many people witlessly consider that not using pull requests removes all opportunities for doing code review. Such a narrow view of code reviews doesn't just ignore a host of explicit mechanisms for review, it more importantly neglects probably the most powerful code review technique - that of perpetual refinement done by the entire team. One of the most pervasive perspectives in software is the notion that it's something we build and complete - hence the endless metaphor of building construction and architecture. Yet the key property of software is that it is soft, and can be as easily modified after it's released as it was when initially composed in the programmer's editor. That's why Erik Dörnenburg wisely argues that architecture is a poor metaphor and would be betterreplaced by town planning. [Martin Fowler]
Bliki: PullRequest - Pull Requests are a mechanism popularized by github, used to help facilitate merging of work, particularly in the context of open-source projects. A contributor works on their contribution in a fork (clone) of the central repository. Once their contribution is finished they create a pull request to notify the owner of the central repository that their work is ready to be merged into the mainline. Tooling supports and encourages code review of the contribution before accepting the request. Pull requests have become widely used in software development, but critics are concerned by the addition of integration friction which can prevent continuous integration. Pull requests essentially provide convenient tooling for a development workflow that existed in many open-source projects, particularly those using a distributed source-control system (such as git). [Martin Fowler]
Distributed Systems Pattern: Idempotent Receiver - Clients send requests to servers but might not get a response. It's impossible for clients to know if the response was lost or the server crashed before processing the request. To make sure that the request is processed, the client has to re-send the request. If the server had already processed the request and crashed after that, servers will get duplicate requests when the client retries. more… [Martin Fowler]
Maximizing Developer Effectiveness: Organizational Effectiveness - Tim finishes his article by looking at how highly effective organizations design their engineering organization to optimize for effectiveness and feedback loops. He illustrates what this looks like by the example of Etsy, who actively measures their ability to put valuable products into production quickly and safely, adjusting their technical investments to fix any blockers or slowness. more… [Martin Fowler]
What texting your Ex has to do with Event-Driven Design? - We sometimes feel melancholic, blue and a bit messy. When we enhance those feelings with “gummy berry juice” then various dubious ideas come… [Event-Driven by Oskar Dudycz]
Choosing a ServiceLifetime - A subtle source of errors and less-than-subtle source of frustration is understanding and using service lifetimes appropriately with .NET Core dependency injection. Service lifetimes, while complicated on the surface, can help developers that need to share state across different lifetimes of an application. Typically, a long-running application has three service [Jimmy Bogard]
Making Complex Topics Stick (Part 1: Content) - Ethos, Logos, and Pathos have to be built-in, not tacked on. [The Architect Elevator]

Permalink | From 25 January 2021 to 31 January 2021 | Last updated on: Tue, 25 Oct 2022 17:09:04 GMT