Speedy and accurate!
Coding tips for website operation

Hello. This is Iida from the Creative Department.

This may seem sudden, but coding for operational projects is scary... One wrong step can lead to mistakes after release.

In fact, even though we use the word "coding," there is a big difference between building a new site and updating (operating) an existing site. Unlike building a new site from scratch, updating an existing site means that each site has different specifications (which are difficult to understand) and is published immediately (which requires speed and accuracy).

In my previous article , I covered what I do for operational projects. This time, I'd like to focus on the coding portion of those operational projects and share some tips for coding that are unique to operations (= operational coding) that I have gained from having mainly worked on the operation of existing sites up until now.

What is operational coding?

The main tasks I perform as part of operational coding are as follows:

• Adding or replacing content (replacing text, replacing banners)
• Creation of LP (landing page)
• CMS registration operation

etc.

Unlike building a new site, operational coding involves updating something that is already publicly available, which is the major difference between operational coding and new site coding.

Things to be aware of when coding for operations

For example, let's say you've been asked to create a landing page for a certain website. Unlike building a new website, it's only one page, so it's easy! You might think so from the outside. Don't be fooled.

Certainly, it may be easy to simply code according to the design, but there are many points to be careful about when it comes to production. I will explain the process from when a request is received to when it is released, and tell you the points to be careful about when coding for production. *As an example, I will give a site that does not have a collection of site parts.

1. Check the specifications of the entire site and the page to be modified

First, we check the overall specifications of the requested site. Is it a PC site, a SP (smartphone) site, a responsive site? Does it have any moving parts? Will Javascript or other implementations be required? Do headers and footers need to be created? Is it just the content part that needs to be created? We check these specifications.

2. Understand the overall structure of your site

Once we understand the specifications, we will actually slice the image and proceed with coding, but before that, let's check the directory structure.

3. Go live

There are several ways to publish to a live site. Publishing with a CMS, uploading to a server via FTP, creating delivery data and publishing on the client's side, etc. Among these, publishing via CMS registration is particularly common in operational projects.

A CMS is an extremely useful form of site management, allowing anyone to easily update pages once they learn how to use it; however, large-scale corporate sites often have very complex CMS designs, and even simply updating a page can lead to unexpected publishing errors if you do not properly understand how to do it.

As you can see, there are certain checkpoints that are specific to operation. There are many different websites and their respective operation methods, but if you understand these checkpoints at a minimum, you will be able to operate the website without making any mistakes.

Important points to note about "how to give instructions to coders"

Usually, the director of each project does not know the detailed specifications or how to put together the coding, so the coder is responsible for coding, but recently, I have been involved in more projects as a liaison between the director and the coder (production direction). In production direction, it is necessary to convey the director's instructions regarding coding and maintain the quality of the finished product, but the difficult part is "how to give instructions to the coder."

I have made mistakes in the past because of my carelessness in the way I communicated.

I was asked to code to revise the content of an existing website, and the director instructed me to "revise the layout of one of the target pages." I simply told the coder the target page and the details of the revisions, and after registering it in the CMS, I had it delivered.

Just when I thought I had safely delivered the work, a few hours later I received a complaint from the client through the director that other pages that had not been requested were broken.

We immediately investigated and found that the CSS used on the page we had just modified was also used on other pages, and that the same class name had been modified. (We quickly restored the CSS to its previous state from the backup and added new class names.) Fortunately, this was a mistake in a test environment that had not yet been made public, so nothing serious happened, but if it had been a mistake on the live site, it would have been disastrous.

I think a major factor in this was a mistake in instructions on my part.

• Not realizing that other pages existed in the directory of the page that was requested to be addressed
• I assumed that the CSS was just for the target page, so I changed the CSS and instructed the user that there was no problem.

Therefore, we have decided to implement the following measures in the future:

• When modifying an existing CSS layout, instead of updating the existing class, assign a new class name and modify the layout.
• Check whether there is any other HTML in the target directory, and whether the CSS is used on other pages. *You can avoid this by adding a new CSS class name, but
  If it is a site you are visiting for the first time, it is a good idea to be thorough.
  If you use an editor to manage your site, you can search all the information at once using the search function.

If someone else had done it and noticed it, it may not have been a mistake. However, as someone involved in operational coding, it is necessary to ensure that no mistakes are made, no matter who is in charge, and it is not acceptable for a new person to not understand the site specifications.

I think that while creating a system that prevents mistakes, quickly finding the cause and dealing with it when a mistake does occur is an important point that is unique to operational coding. Also, rather than just finding the cause and dealing with it, I think it is important to find out at the time whether the method you are using is really okay and deal with it.

summary

In operational coding, the work is done with the site specifications already in place, so you have to understand those specifications before you start working. This is what makes it difficult, unlike building a new site. You have to understand everything, respond quickly, and do it without making any mistakes... That may sound like a lot of work. In fact, we sometimes feel it's difficult, but I think that by being involved in coding for various operational projects, we can code and make suggestions that suit the problem or situation. Nowadays, new sites are constantly being born into the world, and it has become essential to keep updating those sites, so I think the importance of operational coding to support those updates will increase. I would like to continue to sharpen my perspective, which is not visible just by building new sites, and continue to release operational projects quickly and without mistakes.