Best pratices (Dev - development Methods) Pitfall. The wheel of estimation. Tous les dimanches, recevez non seulement les 5 dessins de la semaine, mais également notre sélection de vidéos, de gifs et d’articles qui nous on fait marrer et qui devraient vous faire marrer aussi !
Bug Management. Feature / Feedback Management. Oops. Design Pattern. Open a pipe stream and execute command. #include <stdio.h> FILE *popen(const char *command, const char *mode); The function executes the specified command.
It creates a pipe between the calling program and the executed command, and returns a pointer to a stream that can be used to either read from or write to the pipe. The function passes the command to the host environment so that a command processor can execute it. The command ensures that any streams from a previous call that remain open in the parent process are closed in the new child process.
The requested mode string specifies the I/O mode: If the mode is "r", "rt", or "rb", when the child process is started, its stdout is the writable end of the pipe, and the file descriptor of the returned stream is the readable end of the pipe. After returns, both the parent and the child process are capable of executing independently before either terminates.
UML. Sequence Diagram & UML. Test Driven Development TDD. Information Technology Infrastructure Library. Un article de Wikipédia, l'encyclopédie libre. Pour l’article homonyme, voir Itil. ITIL. ITIL® Home. ITIL France - Le site francophone et gratuit sur ITIL. Brooks's law. Brooks's law is a principle in software development which says that "adding manpower to a late software project makes it later.
"[1][2] It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. The corollary of Brooks's Law is that there is an incremental person who, when added to a project, makes it take more, not less time. Loi de Brooks. Un article de Wikipédia, l'encyclopédie libre.
La loi de Brooks — d'après Frederick Brooks — est une prédiction sur la productivité des projets informatiques : « Ajouter des personnes à un projet en retard accroît son retard » (formulation originale : « Adding manpower to a late software project makes it later »). Le postulat est que la plupart des tâches ne sont pas partitionnables et que les nouveaux arrivants vont faire perdre du temps aux équipes en place en temps de communication. Le Mythique homme-mois. Un article de Wikipédia, l'encyclopédie libre.
Le Mythe du mois-homme (titre original : The Mythical Man-Month: Essays on Software Engineering) est un livre de Frederick Brooks considéré comme un classique dans le domaine du génie logiciel. Le titre de l'ouvrage fait référence à une unité de coût de développement : le mois-homme ou plus communément l'homme-mois, c'est-à-dire le travail d'un homme pendant un mois. Le seul fait d'utiliser cette unité tend à faire croire qu'un travail de 1 personne pendant n mois peut parfaitement être réalisé par n personnes pendant 1 mois ; selon cette idée, on pourrait diviser les temps de développement par deux en mettant deux fois plus de personnel. Or, expérimentalement, cela est faux. Method & Management (work job oops) Etes vous plutôt Scrum ou eXtreme Programming ? [Débat]
Canvas. SOLID principles (plus DRY, YAGNI, KISS and other YAA) ~ Siderite's Blog. Intro I want to talk today about principles of software engineering.
Just like design patterns, they range from useful to YAA (Yet Another Acronym). Usually, there is some guy or group of people who decide that a set of simple ideas might help software developers write better code. This is great! Unfortunately, they immediately feel the need to assign them to mnemonic acronyms that make you wonder if they didn't miss some principles from their sets because they were bad at anagrams. Some are very simple and not worth exploring too much. If you really want to fill your head with principles for software engineering, take a look at this huge list: ⚓List of software development philosophies. But what I wanted to talk about was SOLID, which is so cool that not only does it sound like something you might want your software project to be, but it's a meta acronym, each letter coming from another: S - SRPO - OCPL - LSPI - ISPD - DIP OK, I was just making it look harder than it actually is.
KISS, YAGNI & DRY, 3 Principles to Simplify Your Life as a Developer - iTexico. Best Practices for Agile/Lean Documentation. Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand.
Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall project risk and therefore strive to be as efficient as possible when it comes to documentation.
Agilists write documentation when that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. This article summarizes common "best practices" which agilists have adopted with respect to documentation. Agile/Lean Documentation: Strategies for Agile Software Development. In this article I address the following topics: 1.
Critical Points The fundamental issue is communication, not documentation. Agilists write documentation if that's the best way to achieve the relevant goals, but there often proves to be better ways to achieve those goals than writing static documentation. Document stable things, not speculative things. 2. Figure 1. 3.
Documentation (code) Code maat (visualization / analyze source code) Clean Archi / Architecture. Unit Test Your Architecture with ArchUnit. Discover architectural defects at build time.
August 20, 2019 Download a PDF of this article A common problem faced by development organizations is that code implementations can often diverge from the original design and architecture. The problem is common enough, especially on large projects, that a new tool has emerged to help test that a code implementation is consistent with the originally defined architecture. ArchUnit is a small, simple, extensible, open source Java testing library for verifying predefined application architecture characteristics and architectural constraints.
In this article, I explain why you should test your architecture and how to get started with ArchUnit to do exactly that. Why Should You Test Your Architecture? Software architecture is an important prerequisite for the comprehensibility and changeability of codebases as well as for adherence to software quality goals. Preparing to Write Architecture Tests.