Bi-Weekly Report #2 — Tatag Aziz Prawiro

Hello! As usual, I will be posting about what I have been doing in the current PPL Sprint. In this article, I will cover Development using Version Control (Git) as a team, Clean Code, Persona, and Agile Implementation in our team.

Development using Version Control (Git) as a team

Git is a tool to be used to do version controlling. It is very useful because it lets us save history and checkpoints in our projects. Git is similar to things like Google Drive, but Git is more suited to be used by programmers because you need to use a terminal to use Git efficiently. There are many features of Git, but this article will only cover the basics of it.

Git Flow

In Git, you basically work your code in a branch. A branch is like a tracker, it saves the history of changes you type in your code. In a single Git project, there can be multiple branches. The default and the root branch is called the master branch. You can merge branches to a single branch. Merging makes the changes in one branch to be applied in the other branch. Sometimes, there could be merge conflict, which is caused by different changes caused by branch A and branch B that is merged on the same part of the code.

When you work in a branch from your local computer, in order for Git to track changes in your code, you first need to add them to Git using git add <file_name>. Then, to save the current progress as a checkpoint in Git, you use git commit. Commit will save the current progress of the tracked files only. Untracked files will not be saved, so don’t forget to use git add. After that, to push your local commits to a repository, you use git push. You can also take the commits that are in the online repository to your local environment by using git pull. You can manage the online repository of your local project by using git remote. You can clone an online repository using git clone <repo_ref>.

To create a new branch, you can use git branch <new_branch_name>. It will create a branch from the current branch. You can change branch using git checkout <branch_target>. You can use git stash in order to temporarily move the current branch changes to a stash, then you can apply the changes using git stash pop, this is useful when you want to apply the change not in the current branch but in another branch. You can use git revert to revert staged changes. You can merge the current branch with a target branch by using git merge <other_branch_name>. You can also use git rebase <other_branch_name> in order to apply changes from another branch to current branch, but unlike merge, this one will actually “transfer” the change commits to current branch, not just apply the changes with one merge commit.

Clean Code

Clean code is a code that is clean (duh!). What clean means roughly is the code that is easy to read and understand, and also easy to be developed further by developers other than the initial creator. Here is a definition of clean code by Grady Booch.

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

Grady Booch, author of Object Oriented Analysis and Design with Applications

Clean code makes the code easily maintained. It will truly boost productivity indirectly to the team. Clean code does not mean code that’s short, sometimes writing it cleanly will make it longer. But the purpose of the clean code is not to shorten the code, but to make it clearer to the reader. There are several things that can be done to make a code cleaner.

Formatting

When you code, using a standardized format will help you to make your code cleaner. For python, the formatting standard that is used is PEP-8.

Meaningful Names

When you name variables, function, and classes, everything must make sense. You should not (generally) name a variable as just a,b,c or x,y,z. You name the variable with the intended use of the variable. The same goes for function. You should name a function with the action that the function is doing, not just function_x or something. The same of course goes for classes too. Here is an example of a good name and a bad name:

# Good function with meaningful name
def add_books_to_member(member, books):
    for book in books:
        member.add_book(book)
# Bad function with less meaningful name
def func_book_add(m, b):
    for x in b:
        m.add(x)

Single intention function

When you write a function, makes sure that function only does a single action. Do not clump multiple intentions into a single function. Doing so will make the function uglier, longer, harder to read, and looks like spaghetti.

Comments

You should write less comment in your code. You might think that the more comment there is, the better your code. This is actually not true. A good code should be understandable without the need to read the comment. Although, there are some cases where the code is not easily understandable even with clean code application. In cases like this, it’s ok to use comments but write it briefly. Comments for code license are also mandatory and you can’t really leave that out of your code.

The usage of Clean Code in our Project

Our project tries to incorporate clean code. The section that I write, the section that uses Google Adwords API to create and manage ads applied the clean code. I used the PEP-8 format and also meaningful function names.

A snippet of my code:

def get_campaign(payload):
    client = adwords.AdWordsClient.LoadFromStorage()
    if payload['customer_id']:
        client.SetClientCustomerId(payload['customer_id'])
    campaign_service = client.GetService('CampaignService', version='v201809')
    selector = {
        'fields': ['Id', 'Name', 'Status']
    }
    result = campaign_service.get(selector)
    return result

I used meaningful names and single intention in that function.

Persona

A persona, (also user persona, customer persona, buyer persona) in user-centered design and marketing is a fictional character created to represent a user type that might use a site, brand, or product in a similar way.[1] The term persona is used widely in online and technology applications such as software engineering. Persona has a detailed explanation about their personality and background, and also how they would use your application. A persona is used as a guideline to make the product. It is very handy especially if you do not have communication access to the real user.

There is only one persona for our product, AdHub. Our persona is a UKM businessman that wants to advertise online but they couldn’t get past the complexity of online ad platforms such as Google and Facebook. They tend to not have adequate capability in English in order to comprehend the not-so-easy tutorials and guides for said platforms. Our platform is being developed with that kind of user in mind. We try to make every UI uses the Indonesian language, and tries to simplify the form that is needed to be filled to post ads.

Agile in our team

Our team uses Scrum as it’s development methodology. Because we are not a “full-time” team, we do our daily meeting twice a week, on Tuesday and Friday. We usually do our sprint planning on Tuesday too, every two weeks.

Because we use Agile, every time we do our sprint planning, we take PBI to be tackled during the sprint. The PBI should be small enough that it can be finished within one sprint. Every daily meeting, we also take tasks to tackle on. Tasks are part of the actions/development steps in order to complete a PBI.

Almost every end of a sprint, we also do a sprint retrospective. During sprint retrospective, we try to list all the good things and bad things in the previous sprint. We try to embrace the good things and also find the solution for the bad things that happened during the previous sprint.