Notes and remarks about Software Design, Code Craft, Continuous Integration, Automation, Quality Assurance, Release and Deployment Engineering (Dev/DevOps)
Showing posts with label ALM. Show all posts
Showing posts with label ALM. Show all posts
2019-06-19
Bots and automated commits – Continuous Integration for Quality Assurance and Performance
The idea of having bots writing code is only the continuation of code analysis. In this mindset, 1/ one creates levels of abstractions and let automated systems write the actual code (eg. through snippets, custom DSLs, etc.) and 2/ one associates its code with tests that are run on automated systems and let the "bots" auto-merge features when tests pass.
For those who are interested, this information comes from the following article (a very long, but interesting thing to read btw): "Why Google Stores Billions of Lines of Code in a Single Repository | July 2016 | Communications of the ACM" - https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
2019-06-18
Things you will gain and things you will lose by switching from CVS to DVCS
- What you will gain
It's easy to make one short-lived branch per ticket.
When switching to Git, you are encouraged to use branches extensively, in fact you can/should create one branches per ticket, and merge everything back
into dev (and eventually in the master branch) in one click when you finished all your work (instead merging individual “associated changesets”, which is a
tedious process.)
- What you will lose
Central info is not supported in Git.
If you need edit binary files (eg. images, icons,
etc.) or files that are famous for being hard to merge (eg. complex xml files, unfiltered
log files, etc.), know that when you use a distributed version control
system you will stop being aware of whether a file is currently locked for
edition, or not. [This is one of the two reasons that makes Git unsuitable for
game development because of all the binary assets – the other reason being that versioning
binary files is not among Git’s strengths, even if the Git-LFS project kind-of
bridged the gap there].
2019-01-22
Code Analysis for C# – Comparing Visual Studio and Sonar Capabilities
I have made some attempts to run code analysis tools on C# code and I have a couple remarks and examples.
But first, let's clarify what is the technology that makes it so easy to inspect static C# code: the Roslyn compiler.
Roslyn doesn't have a preference for any particular set of rules. The "Rules" are just a plugin. Each of us could write our own set of rules if we wanted to (see "Tutorial: Write your first analyzer and code fix | Microsoft Docs" ).
Visual Studio provides its own implementation of a C# analyzer with its own set of rules. But as it turns out, based on my case study, those rules are not the same ones as the ones implemented and enforced in Sonar for instance. The default Visual Studio analyzer and the default Sonar analyzer are not chasing after the same things. In fact either of this tool might report as a "warning", things that the other does not report at all. I believe that the same thing applies to NDepend.
This means that tools like *Sonar* and *NDepend* are NOT just GUIs to a well established set of rules. Each tool comes with its own philosophy and system of beliefs about what is good or bad practice.
You might then say: whatever then, who's better than Microsoft for setting rules about the language they created, right? Maybe. And maybe not.
In practice, different analyzers are complementary. The analyzer provided by Visual Studio seems better at picking up edge cases related to the language, whereas Sonar seems to operate at a higher (logical) level.
EXAMPLE #1:
Example of a problem picked up by the the Visual Studio analyzer but not by by the Sonar analyzer :
the following code
Stream data = webclient.OpenRead(url);
StreamReader reader = new StreamReader(data);
xmlstring = reader.ReadToEnd();
data.Close();
reader.Close();
supposedly will cause Dispose() to be called twice on the 'data' object...
The following code removes the warnings:
using (StreamReader reader = new StreamReader(webclient.OpenRead(url)))
xmlstring = reader.ReadToEnd();
Like I said, this was not picked up by Sonar.
EXAMPLE #2:
Example of a problem picked up by the the Sonar analyzer but not by by the Visual Studio analyzer :
"Comparing to itself always returns true."
FYI, I've turned on all info and warnings and made them all visible. Visual Studio just does not see the pb with `listPrevious.SequenceEqual(listPrevious)` :stuck_out_tongue: Which is a shame, because that is a real bug in production code (a typo, or a bad copy-paste), it's not something I just made up. And Sonar's set of rule was able to detect this.
So in conclusion, my feeling is that Visual Studio's set of rules is better at detecting the "edge cases" related to the actual syntax features of the language and the .NET APIs, (which is only natural since both are Microsoft's creations). Whereas Sonar, being 10 years old, and being born in another world (Java) and supporting many languages, is more capable when it comes to reasoning on the semantic and logical levels.
CONCLUSION:
If I had to rephrase, I think that Sonar just doesn't bother with the flavor of the language; it cares about the logic and the semantics. Whereas Visual Studio tries to make it hard to shoot yourself in the foot with this one particular language; but on the other hand, it will let you write silly code if you want to, as long as you respect the internal constructs and overall code design.
READ MORE:
To close on this matter, a final quantitative analysis gives us:
SONAR:
- Number of active C# rules in Sonar, by default = 216
- Maximum number of available C# rules in Sonar = 355
VISUAL:
- Number of active C# rules in Visual, by default = 62
- Maximum number of available C# rules in Visual = 455
RulesCount-inSonar:
RulesCount-inVisual:
RulesCount-inVisual+ALL:
REMARK 1: A shared server is the preferred way to use Sonar, because it is very easy to create projects (one – or more – per developer) and use individual tokens to upload results before checking code in (and browsing results anonymously, in read-only mode, within the company's LAN/VPN). [However, if really wanted, an individual, private localhost instance setup, is possible too, in about 20 minutes when you have a concise documentation.]
REMARK 2: There seems to be a Visual Studio plugin that allows to run Sonar's rule on the fly
SonarLint for Visual Studio 2017: https://marketplace.visualstudio.com/items?itemName=SonarSource.SonarLintforVisualStudio2017
SonarLint for Visual Studio 2019 : https://marketplace.visualstudio.com/items?itemName=SonarSource.SonarLintforVisualStudio2019
From the website:
SonarLint spots bugs and quality issues as fast as you code.
SonarLint spots bugs and quality issues as fast as you code.
- 5 languages supported: C#, VB .Net, C, C++ and Javascript.
- Open source, Roslyn based code analyzers.
- Deep code analysis algorithms using pattern matching and dataflow analysis
- Hundreds of rules, and growing.
- Comes with explanations to resolve detected issues.
Subscribe to:
Posts (Atom)







