awakedeveloper.xyz - admin

admin, autor en AwakeDeveloper

Awakedeveloper.xyz Spined HTML

admin, autor en AwakeDeveloper AwakeDeveloper Linus Torvalds: "Most good programmers do programming not considering they expect to get paid or get unctuousness by the public, but considering it is fun to program"   Skip to content HomeSix weightier blogs well-nigh programming and wiryTragedianArchives: admin No comments How to reservation an Exception with Spock   By admin October 12, 2017 October 16, 2017LawmakingQuality, Unit Testing How to use Spock library First of all, Spock is a unit-testing library which is usually used with Grails and Groovy. So you have to import the spock dependency in the Build.groovy or Pom.xml: ‘org.spockframework:spock-core:1.0-groovy-2.4’ group: ‘cglib’, name: ‘cglib-nodep’, version: ‘2.2.2’ (* Cglib library, it is necessary for mocking objects) How to reservation Exceptions with Spock With Spock you can trammels everything you think, but in this vendible we are going to focus on Exception and its management. In addition, you can reservation an exception as follows:ReservationException test specimen Java void "paymentService throws ServiceException if paymentId is null"(){ given: "An external payment service" PaymentService paymentService = new PaymentService() PaymentExternalService paymentExternalService = Mock(PaymentExternalService) and:"it receives a paymentId null" Long paymentIdNull = null paymentExternalService.retrievePaymentInfo(paymentIdNull) >> {throw new Exception()} when: paymentService.retrievePaymentInfo(paymentIdNull) then: thrown ExternalServiceException } 123456789101112 void "paymentService throws ServiceException if paymentId is null"(){        given: "An external payment service"        PaymentService paymentService = new PaymentService()        PaymentExternalService paymentExternalService = Mock(PaymentExternalService)        and:"it receives a paymentId null"        Long paymentIdNull = null        paymentExternalService.retrievePaymentInfo(paymentIdNull) >> {throw new Exception()}        when:        paymentService.retrievePaymentInfo(paymentIdNull)        then:        thrown ExternalServiceException    } In the test lawmaking you can see, the external service has been mocked in order to throw a NullPointerException, so our Payment service reservation it and it will throw the final ExternalServiceException, as follows: PaymentService Java package test.service matriculation PaymentService { PaymentExternalService paymentExternalService List retrievePaymentInfo(Long paymentId) throws ExternalServiceException{ List paymentsInfo = [] try{ paymentsInfo = paymentExternalService.retrievePaymentInfo(paymentExternalService) }catch (Exception exception){ throw new ExternalServiceException("External Payment Error","PaymentService","Payment") } paymentsInfo } } 1234567891011121314151617 package test.service class PaymentService {     PaymentExternalService paymentExternalService     List retrievePaymentInfo(Long paymentId) throws ExternalServiceException{        List paymentsInfo = []        try{            paymentsInfo = paymentExternalService.retrievePaymentInfo(paymentExternalService)        }catch (Exception exception){            throw new ExternalServiceException("External Payment Error","PaymentService","Payment")        }        paymentsInfo    } } It is very common, the consumer exception thrown has some attributes, for example: ExternalConsumerException Java package test.service matriculation ExternalServiceException extends Exception { private String operation private String service ExternalServiceException (String message, String operationAfected, String serviceThrownError){ super(message) operation = operationAfected service = serviceThrownError } String getOperation() { operation } String getService() { service } } 12345678910111213141516171819 package test.service class ExternalServiceException extends Exception {    private String operation    private String service    ExternalServiceException (String message, String operationAfected, String serviceThrownError){        super(message)        operation = operationAfected        service = serviceThrownError    }     String getOperation() {        operation    }     String getService() {        service    }} How to trammels Exception attributes’ Threfore, you would be worldly-wise to trammels all of the nature which the Exception thrown had, as follows: Test well-nigh exception nature Java void "paymentService throws ServiceException whose operation is PaymentService and Date is the current moment if paymentId is null"(){ given: "An external payment service" PaymentService paymentService = new PaymentService() PaymentExternalService paymentExternalService = Mock(PaymentExternalService) and:"it receives a paymentId null" Long paymentIdNull = null paymentExternalService.retrievePaymentInfo(paymentIdNull) >> {throw new Exception()} when: paymentService.retrievePaymentInfo(paymentIdNull) then: final ExternalServiceException externalPaymentServiceException = thrown() "PaymentService" == externalPaymentServiceException.getOperation() "Payment" == externalPaymentServiceException.getService() } 1234567891011121314 void "paymentService throws ServiceException whose operation is PaymentService and Date is the current moment if paymentId is null"(){        given: "An external payment service"        PaymentService paymentService = new PaymentService()        PaymentExternalService paymentExternalService = Mock(PaymentExternalService)        and:"it receives a paymentId null"        Long paymentIdNull = null        paymentExternalService.retrievePaymentInfo(paymentIdNull) >> {throw new Exception()}        when:        paymentService.retrievePaymentInfo(paymentIdNull)        then:        final ExternalServiceException externalPaymentServiceException = thrown()        "PaymentService" == externalPaymentServiceException.getOperation()        "Payment" == externalPaymentServiceException.getService()    } You can read other interesting wares like Defensive Programming and Resilient Systems.Moreoveryou can visit flipside interesting blogs like Mrhaki’s blog.WeightierRegards   No comments Javascript weightier practices: Good tutorials   By admin December 23, 2016 December 23, 2016 Javascript Yesterday, I was thinking what it should be the next post for the blog and I started to do a brainstorming, in wing the pursuit ideas were got: Lambdas Java 8 vs Groovy Vaadin frameworkDiamondpatterns Javascript Why hibernate should not be used to generate reports In this list of ideas, it appeared one of the most important weakness of my programming skills, Javascript. So I have started to study the weightier practices of Javascript and I have joined to an weedy js undertow in order to modernize my level. In my search, the pursuit tutorials were found: 24 JavaScriptWeightierPractices for Beginners Javascript BEST PRACTICES JavaScriptWeightierPractices: Tips & Tricks to Level Up YourLawmakingI strongly recommend these articles, considering they show the differences between the good and bad practices moreover they provide a lot good examples and tricks. If you internalise all the points of the both posts, you will modernize a lot your javascript level. Tagged   Javascript No comments Defensive Programming and Resilient Systems   By admin December 15, 2016 December 19, 2016LawmakingQuality Although you have ripened your software with TDD and your using has 100% coverage. It is likely which there will be some bugs in production environment, due to Murphy’s Law: “Anything that can possibly go wrong, does” As pragmatic programmers, we have to be hair-trigger with our lawmaking and our programming way, but sometimes this is not enough, and we have to try to baby-sit our using of the production bugs, in wing our system should survive failures. In my opinion, It is increasingly important goof quick than the user or consumer is waiting for any response of our using which never happens, besides it is very important to snift when the system fails, due to the error can be unprotected and fixed, moreover an email or flipside kind of alarm could be sent  in order to start to research what problem has happened. Assertions In my wits as developer in variegated Companies, when you have to do a report for some people, you have to create a file, you have to save it in some directory and perhaps, that directory is not still created or the using did not have permissions to write in it. So the process will goof and an issue will be opened. For this reason, the unexpected conditions should be checked and Assertions (asserts) can be used. In our case, with an interjection or flipside kind of verification well-nigh the directory and permissions would have avoided the previous issue. In the bookLawmakingComplete Second Edition, there are some rules regarding assertions that you should take in account: That an input parameter’s value falls within its expected range (or an output parameter’s value does) That a file or stream is unshut (or closed) when a routine begins executing (or when it ends executing) That a file or stream is at the whence (or end) when a routine begins executing (or when it ends executing) That a file or stream is unshut for read-only, write-only, or both read and write That the value of an input-only variable is not reverted by a routine That a pointer or element is non-null That an variety or other container passed into a routine can contain at least X number of data elements That a table has been initialized to contain real values That a container is empty (or full) when a routine begins executing (or when it finishes) That the results from a highly optimized, complicated routine match the results from a slower but unmistakably written routine An example of a groovy interjection would be the following:InterjectionExample Java public void riseWrongReportAssertion(){ File emptyReportDirectory = new File(DIRECTORY_NAME) log.info "Before assert..." try{ predicate emptyReportDirectory.canWrite() }catch (AssertionError ex){ log.warning "Directory can not be write" // First option: Fix the problem emptyReportDirectory.setWritable(Boolean.TRUE) // Second option: Raise a precondition exception //throw new PreconditionException("Directory can not be written") } log.info("After assert...") } 123456789101112131415      public void riseWrongReportAssertion(){         File emptyReportDirectory = new File(DIRECTORY_NAME)        log.info "Before assert..."        try{            assert emptyReportDirectory.canWrite()        }catch (AssertionError ex){            log.warning "Directory can not be write"            // First option: Fix the problem            emptyReportDirectory.setWritable(Boolean.TRUE)            // Second option: Raise a precondition exception            //throw new PreconditionException("Directory can not be written")        }        log.info("After assert...")    }   On the one hand, if you want to use assertions in variegated places of your code, you can generalize your solution, this is an specific example. On the other hand, be shielding with the assertions in production environment, they can reduce the performance of your application.Full-lengthdisablingFlipsidesituation, that I have seen during my career, has been when you deploy a particular minutiae which has been included in a  key component. If it is not working properly and you can not deactivate it. A good practice, which you can use to stave downtimes in your system, is full-length disabling, although it is not the clearest solution. This technique consists in including an if statment in order to excute or not a part of lawmaking depends on any configuration. Example:Full-lengthDisabling Example Java // do first deportment if(genericDao.retrieveConfigurationProperty("activateNewDevelopment")){ //do some deportment } else { //do flipside deportment } // do increasingly deportment 12345678910111213 // do first actions if(genericDao.retrieveConfigurationProperty("activateNewDevelopment")){     //do some actions } else {    //do flipside actions } // do increasingly deportment   If you ask me, the configuration should be in the database, considering you can transpiration it without deploying the using again. The other possibility is to use a properties file, but in this specimen you would need to reboot your using server, which  would produce a downtime.Zestfulsystems Other problem, which you can find in production environment, is when you have a process which never finishes and you have no alarms or alerts. So… How can I know that the process has failed? Maybe somebody reminds you which you have a report who nobody has received or maybe not. Hence It is very important to manage if a process should have finished. In this way, you can add an zestful or timeout, when the process is running although it should have achieved successfully. Then you can research quickly, what it happens so as to fix the problem and restore the service. During this article, we have talked well-nigh alarms, alerts and reports systems. All of them should be out our using to work when our system has failed, otherwise the IT team would not visualize whether the system is working or not.Flipsidefeatures of the Logs should be: Readeable (By human or machine) Do not indulge unravel lines (New appenders Log4j2 or Logback can be configured to show the info in one line) Do not mix variegated information Show the important information (user ids, emails….) Split the logs well-nigh the variegated services Use daily rollings Integration with other systems Currently, scrutinizingly all the using or sites are working with microservices or they have to connect to other services or databases. For these cases the health checks are very important, due to they snift whether the provider services are falling or not. Depending on their responses, the using will be deployed or not. In addition, when your are unfluctuating with a provider service or database, you are going to slosh their responses, and perhaps the data, which they provide, are not the weightier for your using or they are wrong, so you can create a vallation where you can validate and transform the data. With the new data your system will work properly scrutinizingly always. If your system detects an error data, you must decide what the system does with that data. In theLawmakingComplete book, the tragedian proposes some techniques which can help you to decide : Return a neutral value: Sometimes the weightier response to bad data is to protract operating  and simply return a value that’s known to be harmless. Substitute the next piece of valid data: When processing a stream of data, some circumstances  call for simply returning the next valid data. If you’re reading records  from a database and encounter a corrupted record, you might simply protract reading  until you find a valid record. Substitute the closest legal value: In some cases, you might segregate to return the closest  legal value, as in the Velocity example earlier. This is often a reasonable tideway  when taking readings from a calibrated instrument. The thermometer might be calibrated  between 0 and 100 degrees Celsius, for example. Log a warning message to a file: When bad data is detected, you might segregate to log a warning message to a file and then protract on. This tideway can be used in conjunction with other techniques.Undeniabilityan error-processing routine/object:Flipsideapproach is to centralize error handling  in a global error-handling routine or error-handling object. The wholesomeness of this  approach is that error-processing responsibility can be centralized, which can make  debugging easier. Display an error message wherever the error is encountered: This tideway minimizes  error-handling overhead; however, it does have the potential to spread user  interface messages through the unshortened application, which can create challenges when  you need to create a resulting user interface. Shut down: Some systems shut lanugo whenever they snift an error. This tideway  is useful in safety-critical applications. In conclusion, we have to know which there will be bugs in production environment, but as pragmatic programmers we have to try to reach a system without downtimes and bugs, for these goals, the defensive programming tools are very important. However, if the bugs happen, try to solve it as soon as possible. Although you use defensive programming,please you do not forget to alimony on using  S.O.L.I.D, lawmaking reviews, tests and TDD. References: Joaquín Engelmo – Programación defensiva y sistemas resilientes en el mundo real 8 formas de mejorar tu vida gracias a los LogsLawmakingComplete Second Edition Tagged   Defensive programming No comments Software engineer and knowledge   By admin November 26, 2016 December 11, 2016LawmakingQuality Usually when you finish your Software Engineering degree, you are a software engineer, but sometimes you are hired for a visitor as a developer and perhaps you do not just develop variegated tasks of an application. However it does not unchangingly happen in this way.Consideringyou are not only developer, you are increasingly than a developer. You can do increasingly tasks, for instance designing how to program this issue or task or anything that you want. We are software engineers and we have a lot of knowledge well-nigh developing, designing application, testing, deploying and other concepts.Moreoverwe have to modernize our knowledge everyday since our world is unchangingly waffly and improving, so that it is our duty in order to transpiration and modernize with it. This blog has been created to research variegated concepts such as software patterns, wipe lawmaking rules and variegated programming languages, and modernize them. Currently, I am developing in Groovy and Java, moreover I try to use unit testing, S.O.L.I.D. principles and flipside good practices. In internet there are a lot of sites where you can find unbearable information in order to learn a new rule or technique that you will use in your job or your own applications. I strongly recommend the following:WipeCodersLawmakingCriticon Groovy Mrhaki Groovy Stack Overflow Finally, in the next weeks I expect to publish a new vendible well-nigh StructuralDiamondPatterns. I hope this vendible and the followings help you in order to became a largest software engineer. No comments Refactoring and GoodLawmaking  By admin November 26, 2016 December 11, 2016LawmakingQuality Our lawmaking is not unchangingly the weightier one which we can do, and we have to seem this fact. Sometimes our solutions, designs, algorithms are not good, because they have been implemented with pressure due to a deadline. So it would be a good option in a tropical future to make a refactor in our lawmaking as part of our development. The main reasons are the following:  Modernizelawmaking readability Reduce complexityModernizethe maintainability of the source lawmakingModernizeextensibility ¿What is maintainability? It is how difficult to fix a defect or add new resurgence over one functionality which it has been created.     ¿What is extensibility? It is a system diamond principle where the implementation takes future growth into consideration. It is a systemic measure of the worthiness to proffer a system and the level of effort required to implement the extension   Wikipedia – Extensibility definition   ¿How can I know if my lawmaking bad smells? If your source lawmaking have some of the pursuit symptoms or features, likely you lawmaking bad smells:Lawmakingwithin classes Long methods The platonic length of a method has variegated opinions. In the Clean Code: A Handbook ofWirySoftware Craftsmanship, Robert Martin claims: “The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that. Functions should not be 100 lines long. Functions should whimsically overly be 20 lines long“.Also Kent Beck claims that “Every function in his program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!“, so both have the same opinion. Comments On the one hand,  comments should not be necessary considering the lawmaking should read as natural language and easy to understand.On the other hand, this does not unchangingly happen and comments would be necessary in order to sieve some speciality of the code, however you should not use these ones in every line since it would distract of the most important the code. There is a good quote abouts comments of Robert Martin: “A long descriptive name is largest than a short enigmatic name. A long descriptive name is largest than a long descriptive comment.” Excessive number of arguments The number of numbers of a function or procedure should be as few as possible. If your function have a lot of parameters, maybe you are doing something wrong and you have to pinpoint your method in flipside way or perhaps you have to split it in increasingly methods.Regarding the number of arguments Robert Martin has personal in the wipe lawmaking book: “The platonic number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible.Increasinglythan three (polyadic) requires very special justification — and then shouldn’t be used anyway.“ Dead lawmaking It ways unnecessary, inoperative lawmaking that can be removed. Indistinguishablelawmaking It is when the same lawmaking is used increasingly than once. This problem is very important in the software minutiae and we have to try to stave it in order to increase the quality of the source code. DRY (Don’t repeat yourself) principle can be a good solution in order to stave the indistinguishable code, if you want to know increasingly information well-nigh this principle you can take a squint this conversation among the Pragmatic Programmers Andy Hunt, Dave Thomas and Bill Venners well-nigh maintenance programming.Also you can trammels the pursuit vendible DRY PrincipleProvisionaryhuge complexityProvisionarystatements tend to be very complex, so that we have to try to simplify them. To simplify them, you can decompose the ramified condition in some methods with proper names or you can use logic rules to reduce the complexity of the condition. Wrong names When a developer is writing source code, he has to segregate the proper names for methods, variables and constants.  Usually, we want to save some time and we do not spend unbearable time to segregate the proper names, considering the names have to meet the pursuit criteria: Names have to reveal your intentionsStavedisinformation Good names length Use one word per conceptUnchanginglylawmaking in one notation Regarding the names of methods,  variables, classes and other elements Robert Martin in the CleanLawmakingBook says the following:“The proper use of comments is to recoup for our failure to express our self in code“Also he claims other statements well-nigh the names:“Functions should do something, or wordplay something, but not both.““Methods should have verb or phrase names.”“One way to know that a function is doing increasingly than ‘one thing’ is if you can pericope flipside function from it with a name that is not merely a restatement of its implementation.“Goods examples of name for methods would be the followings: “handleXYZ”, “getXYZ”, “calculateXYZ” Large matriculation A matriculation should be small, as small as it would be possible. Regarding the Refactoring in Large Software Projects,  Martin Lippert and Stephen Roock talk well-nigh the Rule of 30:If an element consists of increasingly than 30 sub-elements, it is highly probable that there is a serious problem:a) Methods should not have increasingly than an stereotype of 30 lawmaking lines (not counting line spaces and comments).b) A matriculation should contain an stereotype of less than 30 methods, resulting in up to 900 lines of code.c) A package shouldn’t contain increasingly than 30 classes, thus comprising up to 27,000 lawmaking lines.d) Subsystems with increasingly than 30 packages should be avoided. Such a subsystem would count up to 900 classes with up to 810,000 lines of code.e) A system with 30 subsystems would thus possess 27,000 classes and 24.3 million lawmaking lines.Maybe the Rule of 30 is a good guide in order to create wipe classes. Speculative generality You should write lawmaking for the problem which you have found and you do not worry well-nigh tomorrow’s problems when these ones definitely happen. And you should not lose between “what if…”  and “in a future if …”.Within the Extremeprogramming practices, it exists a principle or good practice whose name is YagNi (YouArentGonnaNeedIt) and it talks well-nigh fixing the current problem and you do not think in unlikely flows. Between Classes Message villenage It happens when there are a lot of method calls in order to get some data or information of a object. These villenage of methods undeniability do the lawmaking depends on the relationship between unrelated object. Middle man Sometimes a full-length of model can be used in bad way. For instance, in Object Model you can consul the behaviour of a matriculation in variegated classes, however it might be possible that one of these delegated classes do not have any responsibility, so it was wrong considering it can not exist a matriculation without responsibility. Be enlightened with the classes which are simply wrappers. Shotgun surgery It happens when you have to transpiration a lot of pieces of your source lawmaking in variegated places to add a new functionality in your application. LazyMatriculationEvery classes have a forfeit of money and time to understand and maintain them, so that if there are classes that they can not pay for your attention. Theses classes should be removed,  considering they increase the complexity and maintainability of the project. Alternative classes with variegated interfaces It happens when it exists two variegated classes with variegated interfaces, but they have similar behaviour so you would make a refactor  using an connector pattern to unify both interfaces. Primitive obsession The main rationalization for this problem is: “Use primitive data types to represent domain ideas”. It used to happen in a weakness moment, when the programmer decides to take the simple option instead of thinking flipside kind of solution increasingly difficult than the previous one (For example: create a new matriculation to represent the new field).Primitives are often used to “simulate” types. So instead of a separate data type, you have a set of numbers or strings that form the list of mandated values for some entity. Easy-to-understand names are then given to these specific numbers and strings via constants, which is why they are spread wide and far. Data matriculation When it exists classes with only nature and getters and setters methods, these classes are merely stored data for other classes, and these ones do not contain any spare functionality to work for they own. It’s a normal thing when a newly created matriculation contains only a few public fields (and maybe plane a handful of getters/setters). But the true power of objects is that they can contain behaviour types or operations on their data. Data clumps Sometime in variegated parts of the lawmaking there is the same group of variables tropical to the same object, so it is likely that this group of variables vest to the matriculation of that object. Therefore you should to pericope that variables to that class.The main reason of this problem is “the copy-pasta programming” and an poor data structure. RefusedThrowbackIt smells when you have a matriculation which inherits of flipside matriculation but you do not use all the functionality provided by the bequest. So the hierarchy is off-kilter and the unneeded methods might go unused. Indecent Exposure Encapsulate is one of the most important features of the Software Design, in wing this one is not used properly and as a programmer when we diamond and develop a class, we publicity nature or functionalities that they do not be shown. This fact contributes to increase the complexity of the design.Full-lengthEnvy This error helps to increase the coupling and duplicity lawmaking of the using which we are developing. It happens if a matriculation makes huge calls to other matriculation or classes so as to obtain data or functionality. In that case, it may move the functionality on data to this matriculation as well. Divergent changes It occurs when somebody has made changes to matriculation and the developer has included new behaviours that are very variegated that the previous ones. Therefore it contains too much unrelated functionality, so the developer should isolate that changes in other class. Parallel Inheritance Hierarchies While you are developing, you making a subclass of one class. Instead of making a subclass of another. So when you have defining the inheritance of a application, this structure has to be thought pretty well to stave errors like that. Solution sprawl Sometimes, we have implemented a solution in order to solve a problem or perform a responsibility, which it has wilt sprawled wideness several classes. This fact is the result of implementing a quick solution or full-length without spending unbearable time simplifying and consolidating the design.     ¿What can I do in order to modernize our legacy code? Refactoring would be a good answer, in fact there are some techniques which it can be used to get largest our source code. The most important are the following: Composing methods Moving features between objects Organizing data Simplifying provisionary expressions Simplifying method callsMoreoverthere is some practices such us S.O.L.I.D principles, DRY principle, Boy Scout rule and others, which you can use in order to modernize your quality lawmaking and may stave doing a refactor.   Finally, in pursuit wares we will delve into the variegated symptoms of the smell lawmaking to study why this happens, how we can fix it and how we try to stave it.   References: http://blog.codinghorror.com/code-smells/ https://sourcemaking.com/refactoring http://www.aivosto.com/vbtips/deadcode.html http://blog.goyello.com/2013/05/17/express-names-in-code-bad-vs-clean/ http://alvinalexander.com/programming/clean-code-quotes-robert-c-martin http://blog.codinghorror.com/code-smells/ http://www.industriallogic.com/wp-content/uploads/2005/09/smellstorefactorings.pdf No comments Why should you use theLawmakingReview?   By admin November 26, 2016 December 11, 2016LawmakingQuality First of all, I’m going to try to pinpoint what the Code  Review is. What is theLawmakingReview? “Code Review is a phase in the software minutiae process in which the authors of code, peer reviewers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the increasingly expensive process of handling, locating, making a refactor and fixing bugs during later stages of minutiae or without programs are delivered to users.“Moreoverthere are other definition or comments well-nighLawmakingReview, one of the most important was washed-up by Karl Wiegers in his article Humanizing Peer Reviews: “Peer review – an worriedness in which people other than the tragedian of a software deliverable examine it for defects and resurgence opportunities – is one of the most powerful software quality tools available. Peer review methods include inspections, walkthroughs, peer deskchecks, and other similar activities.Withoutexperiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them.“ Opinion and data… From my point of view,LawmakingReview is necessary within a minutiae cycle, considering you can take a lot advantages: Reduce number of bugs of a minutiae task, and make easier the QA of this task. It’s an opportunity to make a refactor and add improvements, considering perhaps you have thought a solution but this one is not the weightier solution and perhaps, the peer reviewer has a good idea to modernize that development, in wing to increase the quality of the code. Besides you can learn a new way to do the variegated develops. Sharing the information among whole the team. In this way, all the team members will be worldly-wise to do any task related to the project. Furthermore, the importance of theLawmakingReview is not only supported by my opinion, otherwise the bookLawmakingComplete , which has been written by Steve McConnell, provides objective data based on big companies experiences: The stereotype effectiveness of diamond and lawmaking inspections are 55 and 60 percent. In a software-maintenance organization, 55 percent of one-line maintenance changes were in error surpassing lawmaking reviews were introduced.Withoutreviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time without reviews were introduced.Surpassingreviews were introduced, under 20 percent were correct the first time. In a group of 11 programs ripened by the same group of people, the first 5 were ripened without reviews. The remaining 6 were ripened with reviews.Withoutall the programs were released to production, the first 5 had an stereotype of 4.5 errors per 100 lines of code. The 6 that had been inspected had an stereotype of only 0.82 errors per 100. Reviews cut the errors by over 80 percent. The Aetna InsuranceVisitorfound 82 percent of the errors in a program by using inspections and was worldly-wise to subtract its minutiae resources by 20 percent. IBM’s 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only well-nigh 1 percent of the errors that would normally be expected. A study of an organization at AT&T with increasingly than 200 people reported a 14 percent increase in productivity and a 90 percent subtract in defects without the organization introduced reviews. Jet Propulsion Laboratories estimates that it saves well-nigh $25,000 per inspection by finding and fixing defects at an early stage. Conclusions of a big study…   Some time ago,  IBM conducted a largest study on lawmaking review. It encompassed 2500 lawmaking reviews, 50 programmers, and 3.2 million lines of lawmaking at Cisco Systems. For 10 months, the study tracked the Meeting Place product team, which had members in Bangalore, Budapest, and San José. They got the pursuit weightier practices: Review fewer than 200–400 lines of lawmaking at a time Aim for an inspection rate of fewer than 300–500 LOC per hour Take unbearable time for a proper, slow review, but not increasingly than 60–90 minutes Be sure that authors enucleate source lawmaking surpassing the review begins Establish quantifiable goals for lawmaking review, and capture metrics so you can modernize your processes Use checklists, considering they substantially modernize results for both authors and reviewers Verify that the defects are unquestionably stock-still Foster a good lawmaking review culture in which finding defects is viewed positively Beware of the Big Brother effect Review at least part of the code, plane if you can’t do all of it, to goody from The Ego Effect   Eventually, there is flipside way to do a lawmaking review, from my point of view, this is the pair programming. While one of the programmers develops the task, the other one corrects, helps and thinks to get the weightier solution. It is share information and get weightier solutions that the main target of lawmaking review is. References: http://searchsoftwarequality.techtarget.com/definition/code-review http://blog.codinghorror.com/code-reviews-just-do-it/ Search for: Search Últimos TweetsNew vendible has been published: awakedeveloper.xyz/en/code-qua… I hope that it likes you Please provide your feedback! :D pic.twitter.com/puChPxDBLrOctober 15, 2017 2:05 pmGood tutorials for improving your javascript skills awakedeveloper.xyz/javascript/…December 23, 2016 4:30 pmMy new post well-nigh defensive programming and resilient system has been published: awakedeveloper.xyz/code-qualit… I expect your feedback!! :DDecember 15, 2016 5:45 pm Recent Posts How to reservation an Exception with Spock Javascript weightier practices: Good tutorials Defensive Programming and Resilient Systems Software engineer and knowledge Refactoring and GoodLawmakingCategoriesLawmakingQuality Javascript Unit Testing Martin Fowler: "Any fool can write lawmaking that a computer can understand. Good programmers write lawmaking that humans can understand." Powered by Parabola & WordPress.