✍️ Promyze's blog

Technical debt is a term that many software engineers have already heard, but on which they have divergent definitions. In most cases, it refers to: Issues that developers face when working on their source code, impacting their organizations’ business. Technical decisions made in the past that currently impact software maintenance and evolution. Time spent on...

Code review in GitLab is a standard process in software engineering teams. Developers who practice code review sometimes feel lassitude and frustration when they repeat the same concepts and best practices in their comments. Code review is also about educating developers, so this observation is quite natural and part of the process. Still, there’s a gap...

Software development teams structure and organization affect their efficiency and their productivity. If you have several software development teams in your company, maybe you’ve already heard: “Our teams don’t talk to each other” This situation happened more than once with our customers at Promyze. Companies have brilliant engineers in their teams that work on complex...

Our motivation at Promyze was to have an overview of “what’s a typical public PR on GitHub ?”. This platform is used today by a large panel of organizations: single developers for their side projects, private companies, open-source organizations, universities, and so on. Our purpose is not to highlight data on PRs management in private companies, with teams working...

Best practices for software development help developers to produce sustainable software. Working efficiently as a team on a software project requires strong communication and definition of coding standards and best practices. A best practice is a rule that should be applied in your project, and it might target any topic: a programming language, a framework,...

During a code review, you formulate comments that can address various topics: readability design & architecture performance framework or language usage These explanations are insightful, but in most cases, they’ll only be read by the submitter of the review. Once the review is over (and the Pull/Merge Request is closed), it’s very seldom to retake...

Code review is great for ensuring best practices and educating developers. If you follow a basic set of principles, such as: Favoring small pieces of code to review (no longer than 500 LOC), Checking the code meets requirements before submitting a review (unit tests OK, documentation updated, …), Being kind and respectful when providing comments...