Refactoring-a Shot in the Dark? Leppanen, Marko; Makinen, Simo; Lahtinen, Samuel ...
IEEE software,
2015-Nov.-Dec., 2015-11-00, 20151101, Letnik:
32, Številka:
6
Journal Article
Recenzirano
Odprti dostop
A study performed semistructured interviews of 12 seasoned software architects and developers at nine Finnish companies. Its main goals were to find out how the practitioners viewed the role and ...importance of refactoring, and how and when they refactored. Another goal was to see whether shortened cycle times and, especially, continuous-deployment practices affected how and when refactoring was done. The results paint a multifaceted picture with some common patterns. The respondents considered refactoring to be valuable but had difficulty explaining and justifying it to management and customers. Refactoring often occurred in conjunction with the development of new features because it seemed to require a clear business need. The respondents didn't use measurements to quantify the need for or impact of refactoring. This article is part of a special issue on Refactoring.
Micro-frontend (MFE) architecture for a web application aims at doing the same for a monolithic user interface (UI) that microservices do for a monolithic backend: it decomposes the UI into ...self-contained components that can be developed, deployed, and provisioned together with their associated backend service. This paper represents a small team's experiences at the Visma company transforming its monolithic UI into a Micro-frontend solution. We describe the motivations, the key design decisions based on Web Component technologies, the design and implementation process including ATAM-based architectural assessment, and our learnings from the case. The key takeaways are that (1) the motivations for MFE concerned improving customer-specific configurability and lowering the related costs rather than enabling team independence, (2) the APIs provided by web standards - and the Web Components API based on them - offered a competitive alternative for JavaScript frameworks avoiding many framework-induced problems, and (3) small organizations without a large number of feature teams can benefit from Micro-frontend architectures.
ScrumBut as an Indicator of Process Debt Lahti, Jacinto Ramirez; Tuovinen, Antti-Pekka; Mikkonen, Tommi ...
2022 48th Euromicro Conference on Software Engineering and Advanced Applications (SEAA),
2022-Aug.
Conference Proceeding
Technical debt analysis is used to detect problems in a codebase. Most technical debt indicators rely on measuring the quality of the code, as developers tend to induce recurring technical debt that ...emerges along with evolution cycles. This debt can emerge when project pressure leads to process deviations, for instance. In agile methods like Scrum, such deviations are commonly known as ScrumButs (like Scrum but ...), which can be considered as a form of process debt. In this paper, we investigate two recurring signs of process debt (i.e. code smells and anti-patterns) caused by Scrumbuts. Our contribution investigates typical ScrumBut practices found in agile projects in one company and we report the relationships found between problems in code and ScrumBut issues. Our findings identify three types of ScrumButs, their root causes, and how these relate to concrete code smells and anti-patterns.
Technical debt has become a common metaphor for the accumulation of software design and implementation choices that seek fast initial gains but that are under par and counterproductive in the long ...run. However, as a metaphor, technical debt does not offer actionable advice on how to get rid of it. To get to a practical level in solving problems, more focused mechanisms are needed. Commonly used approaches for this include identifying code smells as quick indications of possible problems in the codebase and detecting the presence of AntiPatterns that refer to overt, recurring problems in design. There are known remedies for both code smells and AntiPatterns. In paper, our goal is to show how to effectively use common tools and the existing body of knowledge on code smells and AntiPatterns to detect technical debt and pay it back. We present two main results: (i) How a combination of static code analysis and manual inspection was used to detect code smells in a codebase leading to the discovery of AntiPatterns; and (ii) How AntiPatterns were used to identify, characterize, and fix problems in the software. The experiences stem from a private company and its long-lasting software product development effort.
We present and discuss a tool that can estimate the worst-case memory usage of interacting software components. The tool applies formal analysis based on Coloured Petri nets (CPN). For a given set of ...interaction scenarios, the tool calculates a state space of a CPN model and finds a path, which corresponds to a worst-case memory usage interleaving of the events in the scenarios. To hide the formal analysis from the users of the tool, IBM Rational Rose is used as front-end to specify scenarios as annotated UML sequence diagrams, and Microsoft Excel is used as back-end to present the analysis results. PUBLICATION ABSTRACT
The ability to report syntactic errors and to recover from them are basic requirements for any programming environment where programs are parsed before execution. Advanced error handling techniques ...are standard tools when processing textual programs, whereas in the context of visual languages the problem is factually unexplored.
In this work, we develop an error recovery strategy for the parsing algorithm for atomic relational grammars originally developed by K. Wittenburg. We present a definition of parser-defined syntax errors for Wittenburg's parser by analyzing the possible parsing action failures and by showing how an explicit parse trace can be constructed to locate the errors. Then, we present two error recovery techniques, describe how they are integrated to the parser, and discuss further directions.
A modern mobile phone supports many features: voice and data calls, text messaging, personal information management like phonebooks and calendars, WAP browsing, games, alarm clock, etc. All these ...features are packaged into a handset with a small display and a special purpose keypad. The limited user interface and the seamless intertwining of logically separate features cause many interactions between the software components in the UI of mobile phones. In this paper, we present an overview of our approach to modelling feature interactions in Nokia's mobile phones with explicit behavioral models of features. We use Coloured Petri Nets as the modeling language and the tool Design/CPN that provides a graphical, interactive user interface for constructing and simulating Coloured Petri Nets. We describe at a general level how we have created a graphical user interface for controlling and observing the simulations of models through an on-screen mock-up of a mobile phone. Then, we discuss the concrete results we have achieved by using our approach.
Technical debt has become a common metaphor for the accumulation of software design and implementation choices that seek fast initial gains but that are under par and counterproductive in the long ...run. However, as a metaphor, technical debt does not offer actionable advice on how to get rid of it. To get to a practical level in solving problems, more focused mechanisms are needed. Commonly used approaches for this include identifying code smells as quick indications of possible problems in the codebase and detecting the presence of AntiPatterns that refer to overt, recurring problems in design. There are known remedies for both code smells and AntiPatterns. In paper, our goal is to show how to effectively use common tools and the existing body of knowledge on code smells and AntiPatterns to detect technical debt and pay it back. We present two main results: (i) How a combination of static code analysis and manual inspection was used to detect code smells in a codebase leading to the discovery of AntiPatterns; and (ii) How AntiPatterns were used to identify, characterize, and fix problems in the software. The experiences stem from a private company and its long-lasting software product development effort.
Feature Interaction Control on Smartphones Bosch, G.; Creus; Tuovinen, A.-P.
2007 International Symposium on Industrial Embedded Systems,
2007-July
Conference Proceeding
Smartphones are becoming increasingly complex software-intensive devices. The platforms supporting these devices need to cope with the growing complexity while maximising the use of the underlying ...hardware. At the same time, manufacturers need to ensure that the different features do not clash or have undesired interactions between them, leading to a bad user experience and ultimately a bad perception of the product. This paper focuses on one of the common resources used by all features in the system; namely, processor capacity. While it is desirable to maximise the use of available processor capacity, overuse can have dire consequences for usability. We present the Application Superstate Control System, a centralised approach based on a negotiation protocol for sharing the available capacity among features in a configurable fashion. Manufacturers and platform integrators can get visibility over feature interactions and control their outcome with the proposed framework.
PDF
