Articles
Agile: is adaptive rather than predictive is people-oriented rather than process-oriented Agile plans are a baseline that we use to help us control changes. Agile teams plan just as carefully as traditional teams, but the plans are constantly revising to reflect the things we learn during a project. Success is based on value delivered by the software. Agile engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team’s effectiveness, but are always second-order influences. different from plan-driven: Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform with this design. Success is measured according to how well development follows this plan. Plan-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer, and is easier to define skills and career paths. Direct Interaction with customer: All agile methods stress the importance of direct interaction between the developers of a system and customers who are its eventual beneficiaries. The agile manifesto said “Business people and developers must work together daily throughout the project”, which is there to stress the high frequency of interaction. Extreme Programming stresses this through its practice of OnsiteCustomer.
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a “refactoring”) does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is kept fully working after each refactoring, reducing the chances that a system can get seriously broken during the restructuring. Martin Fowler Refactoring lowers the cost of enhancements When a software system is successful, there is always a need to keep enhancing it, to fix problems and add new features. After all, it’s called software for a reason! But the nature of a code-base makes a big difference on how easy it is to make these changes. Often enhancements are applied on top of each other in a manner that makes it increasingly harder to make changes. Over time new work slows to a crawl. To combat this change, it’s important to refactor code so that added enhancements don’t lead to unnecessary complexity. Refactoring is a part of day-to-day programming Refactoring isn’t a special task that would show up in a project plan. Done well, it’s a regular part of programming activity. When I need to add a new feature to a codebase, I look at the existing code and consider whether it’s structured in such a way to make the new change straightforward. If it isn’t, then I refactor the existing code to make this new addition easy. By refactoring first in this way, I usually find it’s faster than if I hadn’t carried out the refactoring first. Once I’ve done that change, I then add the new feature. Once I’ve added a feature and got it working, I often notice that the resulting code, while it works, isn’t as clear as it could be. I then refactor it into a better shape so that when I (or someone else) return to this code in a few weeks time, I won’t have to spend time puzzling out how this code works. When modifying a program, I’m often looking elsewhere in the code, because much of what I need to do may already be encoded in the program. This code may be functions I can easily call, or hidden inside larger functions. If I struggle to understand this code, I refactor it so I won’t have to struggle again next time I look at it. If there’s some functionality buried in there that I need, I refactor so I can easily use it. Automated tools are helpful, but not essential When I wrote the first edition of Refactoring, back in the late 90’s, there were few automated tools that supported Refactoring. Now many languages have IDEs which automate many common refactorings. These are a really valuable part of my toolkit allowing me to carry out refactoring faster. But such tools aren’t essential – I often work in programming languages without tool support, in which case I rely on taking small steps, and using frequent testing to detect mistakes.
Web3 refers to a decentralized and censorship-resistant online ecosystem comprised of innovative technologies such as blockchain-based domain registries (e.g. Ethereum Name Service) and distributed content storage and delivery networks (e.g. IPFS). When enabled, NextDNS will act as an unfiltered gateway to this new Web, letting you experience it firsthand without the need to install anything. As most browsers only support classic top-level domains at the moment, you should add a trailing slash (“/“) when trying to access a Web3 domain directly (e.g. “vitalik.eth/” instead of “vitalik.eth“). Ethereum Name Servioce https://ens.domains/ https://unstoppabledomains.com/ https://handshake.org/ Interplanetary File System https://ipfs.io/
