--Originally published at Hackerman's house

Code review (also called peer review) is a software quality assurance activity in which one or more developers check a program by reviewing and reading parts of its source code. At least one of the reviewers must not be the code’s author, the purpose of this is to have another point of view, and different ideas to judge the code in a more objective way. The people performing the checking (except for the author of the code) are called reviewers.

The main objective of this process is to detect quality problems, although it can be used to reach more goals. Better code quality: improve the readability, maintainability and understandability. Finding defects: finding performance problems, security vulnerabilities among other flaws. There are many more goals that can be achieved through this process, but the general idea is to create better software and to avoid errors.

Types of review processes

Formal inspection

This is the traditional method of review. Software developers attend a series of meetings where the code is reviewed line by line. This method has been proven to be very effective in finding defects in the code.

Regular change-based code review

This is a more lightweight type of code review. This type uses something called Version Control, it is basically a system that records changes to a file or a set of files over the time. Github is one of the most popular applications that does this; the developers are constantly checking the changes made by every member of the team. They can see who is the responsible for the code and they can check it, but they do not dedicate the time to read it line by line.

Source:

https://en.wikipedia.org/wiki/Code_review

--Originally published at Hackerman's house

Test Driven Development is a software development process that repeats very short development cycles, the requirements are turned into specific test cases, and the software is improved in order to pass these new tests. This way all the software is proven to meet the requirements set. One of the main responsibles for this methodology is Kent Beck who rediscovered the technique.

A Test Driven Development cycle consists of a series of steps. According to the book Test-Driven Development by Example these are the steps.

Add a test

Each new feature begins writing a test. The test defines a function or the improvement of an existing function. The developer must start by fully understanding the feature and its requirements. Some of the tests can be updates of an existing test. The use of tests before starting to write code lets the developer to focus on the requirements while writing code.

Run all tests and see if the new test fails

In this step the existing code is proven to see if the new test is passed. If the existing code passes the new test it means that the test is useless or flawed. The new test should always fail because there should not be code that fulfills the requirements yet.

Write the code

The next step is to write the code to pass the test. It is not that important that the code is elegant or really well written. The most important thing is to pass the test. One thing you should consider is that the code must only fulfill the test and not add more functionality beyond that.

Run tests

If all test cases now pass, then the new code meets the test requirements and doesn’t break any existing features.

Refactor code

The last step in the cycle is to

--Originally published at Hackerman's house

These are two different processes utilized to test if the software we are producing satisfies certain characteristics. Both are directly related with what the client wants to build. Let’s see the differences between them and why both or them are important in the process of building great software.

Verification

Verification is the process of evaluating work-products of a development phase, this doesn’t evaluate the final product. The evaluation done decides if the software satisfies the specified requirements of that phase.

Are we building the product right?

Verification is done trough reviews, walkthroughs and inspections. These check if the software satisfies each of the requirements it should.

Validation

Validation is the process of evaluating software at the end of the development process to determine if it satisfies specified business requirements. It basically evaluates if the software does what the client needs, it is directly related to the specifications done at the beginning of the project, if these were wrong in the first place then the software won’t be validated.

Are we building the right product?

There are two ways to perform software validation, internal and external. In the internal way it is assumed that the goals of the stakeholders were correctly understood, and if the software meets the requirement specification then it is internally validated. External validation happens when you ask the stakeholders if the software meets their needs.

Source

http://softwaretestingfundamentals.com/verification-vs-validation/

--Originally published at Hackerman's house

If you have read my blog up until now, you should know the basics about software design, and specifically about the use of UML in this area. Let’s see how to take advantage of all the analysis and design we have done. The class design that we already know how to do can be converted into code that will be the actual implementation of the system.

The quality of the diagrams used has a direct implication on how to translate it into code. Diagram classes are object oriented, so it may be convenient for you to convert these diagrams into a object oriented language; this will allow you to keep the identity and functionality of the system you design; if you consider that using a non-object oriented language is more appropriate in your own case feel free to do so.

It is important for you to have a profound understanding of your system and your diagrams before starting to code. You will be able to see that the class diagrams offer you a lot of information to that you can take advantage of; the first example is the attributes you will need to initialize in your code. The method’s name gives you a basic understanding of what you have to program. Even the inheritance is specified within the diagrams, all you have to do is implement all the design you already have. Just take your time and select a language you are familiarized with.

As we can see, the hard part is already done when the analysis and design is finished. The implementation is just a translation of what we already know about the system.

--Originally published at Hackerman's house

When you have to map objects to relational databases, the place where you have to start is with the data attributes of the class. It is important to define in how many columns these attributes will be mapped, it can be from zero columns to many more. Not all attributes are persistent, this means that they are used for some temporal calculation in the application, this has a direct impact in the way the database is designed because it’s possible that this attribute is not necessary in your database. In the case that an attribute is an object in their own, the attribute will map into several columns in the database.

The easiest mapping is when each attribute goes into a single column. In this case the class model and the physical data model can be very similar; the main differences will be that the data model needs at least one primary key, and in case there are more classes interrelated you need to add the foreign keys for the occasion.

Inheritance

Inheritance is a big deal when mapping a class into a table. The issue is figuring out how to organize the inherited attributes in your model. There are three fundamental solutions for this.

This class hierarchy will be modified using the three approaches.

Using one data entity for an entire class hierarchy.

This means that you will map an entire class hierarchy into just one data entity that contains all the attributes of all the class in the hierarchy. It is important to add the primary key to the data entity. The advantage of this approach is that you have all the information available in just one table; this supports polymorphism in an easy way. The cons are that has a high level of coupling and an error