Save, folks.
Much has been said lately about software quality, quality development. Even up with some questions that have become almost catchphrases. So, what is quality? How can we say that our applications are or not quality? It is even easy to say that an application is bad?
For more people than I’ve seen answer that question, I saw few directly respond to what I think personally. An experienced developer can mention:. Software that does not use standards, or that it is not well structured or that has many keys “hardcoded” … are numerous defects that an expert can list on another’s software
To the present writer, bad software that is difficult to maintain – is for the sole developer of it, is for the rest of the current or future team. Many of the cited reasons contribute to an application hinders the development of a team – but is not crucial to the development of standardized stream. Yes, when I say “software”, I mean not only the code but to work committed to developing it.
We could be discussing practices and bad practices, but it would be an endless discussion. Many “bad practices” persist for no reason within companies and projects for other reasons n. I’ve seen some teams that have adopted a “bad practice” as part of the flow – how it worked that scope, it was played and the project was still working. Was a failure? Possibly, but controlled and science of all.
Quality, in short, is a gradation of anything within a measurable expectations. Complicated? We can say that something has quality when we know that the hope that “something” and we can determine these you about it – if that determination is positive, that “something” is / has quality. Think of the screen right in front of him: what you expect from her? She handed you a clear image without deadpixels with good visibility into possible light variations, with precise adjustments … if you can measure these questions and prove the effectiveness of the screen in each of them, if these are the definition of quality criteria then it is good.
And with software? How we measure quality? First of all, we need to raise what criteria will the project evaluation screens. Let’s assume that one of the criteria is based on Unit Testing. Our project needs to have a coverage of more than 80% E (AND, +) must pass completely. If only this criterion is important to you and your team, and you can apply this, congratulations, you have a quality software – although, to deliver to production, users complain that it is impossible to browse your application. So I ask: the user’s eyes / client, your application is quality
Choose quality criteria is essential in any project?. Unit tests are great, but it has some tangible value to those who will use? We can add behavioral testing, usability … to add value to the product, why not not include them as a criterion? A survey of each layer interested in the project regarding the expected can lead to a successful quality management adoption strategy. The developers expect? What does management expect? The Product Owners? More importantly, the consumer?
We have criteria, and we how to measure each of them. Great. How do you know if the quality improves or worsens, every delivery? You should keep a history of measurements, follow these results and see if delivery delivery, they improve. Ideally, knowing the metrics, you can map out a plan of goals and continuous improvement and to monitor developments. It may be that the compliance rate of the target can also be a criterion – who does not like recursion
In a hypothetical case, we are in a project and have different metrics, with goals being met. We have a quality product? Within the criteria, yes. We have a good software? Yes and no (who personally know me probably hates that my answer).
Yes, for a project with many quality criteria being met tends to give little bad job. For poor job meant last minute corrections, redeploys, unnecessary stress. Tends, not necessarily you will get rid of it.
Why not? Good software practices are not easily measured. For example: as you know you are using DDD looking at the code? And Object Calisthenics? and SOLID? E Design Patterns in general? You are applying well? I may be committing a great blunder here, but outside some practices of Object Calisthenics, which can be measured via style analysis, there is no “SOLID-Adherence-Detector” or “D4″ (Domain Driven Design Detector) – which in prevents, at first, to measure how we are adhering to these practices.
These practices / standards are essential to make sustainable code. That code base can grow smoothly. It also avoids common problems in maintaining code. It also allows several people to interact in the code within certain standards in order to avoid conflicts of understanding. This kind of care when developing shows me whether software is good or not, as I mentioned at the beginning.
While there is no D4 or SAD, unfortunately we can not use them directly as metrics. But the implementation of these best practices, architectural precepts etc. brings benefits and these but can be quantified and applied to quality management – number of bugs for release, reducing conflict and product development, new features for release, etc.
In short:. make a good software, apply best practices as is possible and have a good and sustainable application. Meanwhile, study which metrics are relevant to the project and to measure them continually, giving a quality control him. Expand these “advice” beyond code:. Make your team, your project, your best company and understand and improve quality
Until the next
No comments:
Post a Comment