Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

cst438 Midterm

Download as pdf or txt
Download as pdf or txt
You are on page 1of 7

Roland Bernard

Prompt 1:

You are working as a software engineer on a team of 12 developers. You have been asked

to write a proposal for how the team should use GitHub for source code control for the project.

Explain what procedure you would recommend to the team and the rational for it. How should Git

branches and pull requests be used?

GitHub for version Control

To understand the best way to work with GitHub for a project, first it is important to

understand what it is, what can be done with it as well as how to use the version control, which is

a very important piece that will be used on the project.

What is GitHub?

GitHub is a place where programmers can collaborate on multiple types of programming

projects while using git version controls. It is a hosting place that has a user interface for users to

interact with contents. Projects in GitHub can be public or private. To get started with Git, a Git

repository must be created.

What is a Git Repository?

A git repository is a place on GitHub that contains a collection of files that belong to a

specific project. Those files are updated whenever a change is made to a file or files on a project

and ready to be deployed to production. Also, the git repository needs to be created by an

individual from the group, and an invitation to collaborate needs to be sent out to the other

members of the team in order to contribute to the project.

After learning about GitHub, it is the time to learn about how to use it and to collaborate

on the project. The team member that is going to create the repository for the team needs to go to
github.com and create an account first. After creating an account, the repo can be created usinf

the plus sign on the page and fill the page with some info about the repo. The repo will need to

have more than one branch. The main branch is the primary branch, or it can be called the

production branch where things go live. Another branch is the development branch, or the dev

branch where things can be pushed to, worked on and perform code reviews to make sure things

are working properly before moving to production.

Depending on the scale of the project, two branches can be enough, or more branches can

be added for each different part of the project. Each member of the team will receive an

invitation from the person who created the group to be added to the repository in order to

collaborate. If a user doesn’t already have a Git account, he or she will need to do so in order to

access the repository especially if the repository is private. The team members are called

collaborators.

Git Navigation:

GitHub provides great documentations on how things can be added to a repository. Most

importantly, Git provides users with the info of what needs to be done after the repository is

created. Overall, it comes down to three steps: Git add, Git commit and Git push.

Those three important steps will be done using command lines. Git command lines can be

executed almost the same way in most operating system. If a MAC computer is being used, the

terminal will be the place where the command lines will be executed. After navigating to the

appropriate folder and the repository is already created, git clone command line will need to be

executed to clone the reposition so that the files can be added there.
If a window computer is being used, the command prompt will be used the same way as the

terminal in MAC. Some users prefer to use git bash, which can be downloaded online for any

operating system.

Git Add

Each user will have to create a folder in their local computer with the files that need to be added

to git after working on them. After that, the collaborator will use Git command lines to navigate

through the folder as well as to add it to GitHub.

Git Commit

After adding the files to git, they have to be committed using the git commit command line. As

stated, it is just git commit -m “Description of what is being added”.

Git Push:

Git push is the final step to make sure the files transfer from the previous location to the git

repository. This step requires the user to login using their Git credentials to so. The command to

do so will be git push and follow the instructions on the screen.

Files in Git:

When the files are in git, users can create pull requests for code reviews to be done and other

things as well. As a group, it will be very important for that to be done before committing the

changes to the main branch. Tutorials will be provided on how to do that.

Pull Request:
A pull request is used mostly for others to see the changes that other developers make on files

that are being worked on. They can acknowledge the changes and perform code reviews if

needed. The command to do so will: git pull “the remote_name” and “the branch_name” that the

work was done on. According to experts, this command is a combination of git merge and git

fetch to show what was fetched and merged. The other term that is used during this process is

forking. That allows collaborators to work on a copy without affecting the main branch.

Therefore, that can be used as well while working on projects.

Overall, this is a simple version of how to get started with GitHub on a project where

collaborators know how to use environment but not GitHub.


Prompt 2:

Summarize what you have read so far in the textbook “Software Engineering at Google”. Pick

what you consider to be the most important things in the book. Explain why they are important

and whether they are applicable to teams outside of Google.

The software engineering book is a great book that covers a lot of important materials

related to the many different topics within software engineering. First, the book provides detailed

information about what software engineering is. Based on the information provided, readers can

understand that the software engineering is not only building a piece of software, but also it

includes the whole cycle from writing the requirement documentation to provide maintenance

until the software is discontinued or replaced by a different one. In addition to that, the book

provides great information about how to work on teams. This is very critical when it comes to

software engineering because the process involves working with multiple team members and

sometime working with multiple teams. It provides details about what can happen when team

members hide errors or mistakes that create bigger issues later that could have been prevented

early if known. Talking about the three pillars of social interaction was great for teams and can

be taught at any level where they are teams.

In addition to those, the book talks about how important it is to share knowledge among

other team members. Also, how Google uses mentorships to help its employees to grow for the

good of the company. Google provides many ways that employees can continue to learn as well

as sharing knowledge with both internal and external audience. One of my favorite chapters

from the book was how to lead a team. In many industries, the managers don’t really have a good

understanding of the products that their team members are producing. However, the position is
offered to them based on their ability to manage a team. Consequently, managers are acting like

parents and their employees are like their kids. According to that chapter, at Google, it is a little

bit different. Managers should have background on what their teams are working on. Also,

learning that managers should focus on both social and technical aspects of their team is great to

learn from the book. Furthermore, I have learned about many other materials that include how to

perform code reviews, why it is important, as well as the code review flow followed at google.

Learning the importance of good documentation on code was great because some time, I

personally forgot why I did something on the code. Therefore, other programmers will not know

why I did it either. Also, documentation is everything that engineers can use to make their life

easier, which include regular documentation and comments on codes as well. Testing was a very

good and important topic that I enjoyed from the book as well. I learned about the purpose and

the benefits of performing them throughout the development process. I also learned about how to

break testing down into manageable pieces in order to catch errors that could have been missed if

testing was performed in big pieces.

There are many benefits when testing codes that many people didn’t really think about.

Those benefits include less debugging, increase confidence in changes, improved documentation

as well as thoughtful design to name this few. The sizes of the test matter based on the size of the

project as well as what is being tested for.

Based on my opinion, I think the leadership portion from chapter five and the all the

chapters that talk about testing were important. The reason is that great managers make great

teams. Managers who value employees tend to have a better relationship with their employees,

which is very important at any job place. That chapter also reminds me of the very first

conversation my boss had with me when I was hired as a business analyst a couple years ago. He
said that all his employees will always be valued more than what they do because they are more

important than the job they do. That was great. The chapters that are related to testing are

important because they teach users the importance of performing them as well as which levels

throughout the process to perform them. Some programmers tend to test things during the

development process and push changes to a test environment for users to test. That sometimes

work well, but sometime if different unit tests were performed at the code level, some of the

bugs could have been caught early on. Therefore, they are very important to me.

I believe the knowledge shared in the book can certainly be used outside of google. As a

current employee working in the education system in California, I have seen many similarities on

the work that our IT team is doing compared to what I read from the book. When it comes to

technology, I truly believe the book can and should be embraced by other companies upon

approval. That will benefit employees as well as companies as well.

You might also like