1
edit
Changes
m
no edit summary
*Look for uncommented code bits
*Look for code which was changed recently or something that has being undergoing consistent change<br>
<br>
Benjamin also told us about checking version control systems, if I remember correctly, these are systems that are in place that people can use to go back in time and look through the code changes as they progressed through time. Then we moved on to “Reading to Learn” or reading to code to learn its layout, structure, and purpose. The objective of this reading to learn method is to understand the big picture, the technologies, functions, object models and function names being used in the system. Benjamin also suggested a programmer should read the unit tests if it is available.<br>
<br>
Another part of learning the code is to learn to write test programs that will work with or add to the main code base. These little test programs or code inserts will help the user get a better grip over what a certain function or code set does. Mr. Smedberg repeatedly stressed in this community and this type chaos it is crucial to ask questions. Not everyone can understand the programming style or the purpose behind a certain code set or functions; so in order to clarify the doubts or misconceptions it is best to ask questions and get an answer from the community. Another point Benjamin stressed on was that code reading should be a “social exercise”; it should not be viewed as a process or in the word of Mr. Smedberg himself “It should not be just some geek, sitting in his basement reading code and understand it, people should take a general interest in it and move beyond just coding by themselves but do it in groups or as an activity with friends”.<br>
<br>
Mr. Smedberg then got into the reasons why people bother with code reading. These reasons are as follows:
*Code reading is necessary to insure quality in code
*It creates a culture of responsibility where people who participate in any form or nature are responsible for whatever they contribute; good or bad.
*Reviewing code allows for mentoring of newer programmers and allows for more participation of others by inviting people into the community.
*Gets more involvement. When multiple people get to know about the code, it removes the dependencies on one person alone knowing the intricacies of the code.
*The main purpose being for code reading and reviewing is for better human comprehension, better readability and better maintainability.<br>
<br>
Mr. Smedberg completed these reasons by saying something that really stood out in my opinion. He said everyone is going to have problems therefore never try to solve everyone’s problems because there are some problems that are too complex or too trivial to be solved. He also cautioned to be on the watch out for what he termed as “Code Astronauts” people who try to do too much or try to be perfectionists. He (Benjamin) later on went on to the types or code reviewing and reasons behind it. Some of the major types of reviews he discussed were: (in no order)<br>
<br>
'''Goal Review:''' What is the problem with code in the system? Is it worth solving the problem? Should an entire system be rebuilt in order to sort out one bug? What are the tradeoffs in achieving the goals? These were some of the questions Mr. Smedberg addressed under the goal review criteria.<br>
<br>
'''Maintainability Review:''' the main concern under this review is coder understanding of the already existing code base. Documentation is key in this stage and every piece of code should be documented well. Making sure the code is consistent or correct through out the system and ensuring there are no warnings or errors in the code.<br>
<br>
'''Security Review:''' If the code is being exposed to unknown and or un-trusted people; make sure there are proper function wrappers in order keep the data well protected.<br>
<br>
'''UI Review:''' Make sure the user interface does what the user expects it to do and is well placed in areas where users will check for it. Make sure the font size and type of text used is consistent through out the UI layers and is easy to understand.<br>
<br>
'''Integration Review:''' Make sure the modules work with each other properly, and make sure all the dependencies are addressed in the integration review. Also check to see if the final product is localizable and do a review of the documentation at this stage to make sure everything is documented well for the user. This documentation is more of help documentation not code documentation as end user will be highly unlikely to be looking at code documentation more so at documentation on what the systems key functions are and how they can be executed or called.<br>
<br>
'''Testing Review:''' In this type of review a check is done to see if there are tools to evaluate the code. Check for code inconsistencies and or incorrect function calls, placements, or other code related issues.<br>
<br>
Mr. Smedberg also talked about “using the experts” which correlates to the previous mention of asking questions in this report. Always ask the experts if something is confusing or beyond a beginners understanding. From his talks I gathered Benjamin Smedberg’s opinion of the best thing that is part of Mozilla is the extension infrastructure which is in place.<br>
<br>
To finish off I would say many important points were covered by this speaker; especially the reasons for the reading code, the purpose of reviewing and the constant inference on quality of the code. Documentation was yet another major emphasis made by this speaker and in my opinion I believe this is a very important thing for any coder to practice. Documentations is the only link that other have sometimes when people are trying to understand and decipher some other persons code. Nothing that happened in this talk changed my view of open source or what the entire community is all about.
<br>
