My two cents

Coding

Before start coding

Firstly, read existing code and plan what you are going to make
- Research how it's working, what kind of value the valuable should have
- Ensure what you have to do, and what you should not do
Secondly, identify where to change

Thirdly, comment your plan into the code:

<?php
// TODO: Connect to database
// TODO: Select the data if it's connected
// TODO: Close the DB connection
// TODO: Convert the data into JSON and return
?>

Finally, start coding

It will be great if you get rid of TODO: and leave the rest of the comment

<?php
// Connect to database
$db = new DB();
// Select the data if it's connected
if(!$db->connect_error) {
    $result = $db->query(sprintf('SELECT * FROM bar WHERE %s', $var));
}
// Close the DB connection
$db->close();
// Convert the data into JSON and return
return json_encode($result);
?>

Making changes

Use Git locally

When you develop the existing site, you have to work with non version controlled files. Here is what I do.

Create a directory locally

$ mkdir YYYYMMDD_01_ticketXXXX_identicalName

Download files you want to change and save into the directory
Move to the directory, start managing files by git, so you can easily see what you changed, rollback the changes, stash and so on
Before upload those changed files, git commit
Download the same files from the server, and override files you changed
So you can see changes if other developers did
Merge the changes if applicable, then upload your files

Write harmless code

As the code is not fully object oriented, and huge. You may create a variable which is used already in somewhere but not the file you are viewing. This is stressful.

For example:

file1.php

<?php
$var = 1;
?>

file2.php

<?php
// Your change START
$arr = array(1, 2, 3, 4);
for($var = 0; $var < count($arr); $var++) {
    echo $arr[$var]."\n";
}
// Your change END
?>

index.php

<?php
include_once 'file1.php';
include_once 'file2.php';
echo $var;  // expected 1, but 4
?>

To prevent this, I would make like this.

file2.php

<?php
// Your change START
$doSomething = function($array) {
    for($var = 0; $var < count($array); $var++) {
        echo $array[$var]."\n";
    }    
};

$arr = array(1, 2, 3, 4);
$doSomething($arr);
// Your change END
?>

$doSomething is an anonymous function. The $var in the function is in a different scope. This change is harmless.

Commenting

Since the code is not managed by Git or any other version control tools, I tell myself to leave comments for other developers, and also myself. Because I tend to forget why I made the changes after months.

Some examples:

When I change / add / remove lines

<?php
// YYYY/MM/DD Name #TicketNumber START
Some code here
// YYYY/MM/DD Name #TicketNumber END
?>

When I add a new function or class

<?php
/**
 * functionName()
 *
 * Description containing YYYY/MM/DD Name #TicketNumber
 *
 * @param $arg description
 * @return $ret description
 */
private function functionName($arg) {
    return $ret;
}
?>

On the other day, somebody tried to hack our server using one of the developers name. This is because his name is revealed in html code everybody can see. It is great leaving your name into the code so other developers can ask even though it's not documented well. To prevent those hackers, I encourage you to comment in HTML, CSS, and JS carefully.

For example:

<!-- YYYY/MM/DD YourName #xxxx START -->
<div>something</div>
<!-- YYYY/MM/DD YourName #xxxx END -->

If you comment in PHP, it's not rendered.

<?php // YYYY/MM/DD YourName #xxxx START ?>
<div>something</div>
<?php // YYYY/MM/DD YourName #xxxx END ?>

Minimizing CSS, JS will be great to remove your comments. Maintain non-minimized one in development, then publish minimized one.

https://atom.io/packages/atom-minify
https://atom.io/packages/uglify

I personally use grunt or gulp to do so. And webpack is the trend in 2015. Front-end dev world changes so quick.

http://gruntjs.com/
http://gulpjs.com/
https://webpack.github.io/

Testing

Testing is the most important part of coding. If the code is not tested, it is just a crap. I don't want you to create garbage, so please test. When I code, I want to use my time; 50% for researching and planning, 20% for coding, 30% for testing.

When you test, please make sure:

Your changes don't affect where they should not affect (regression test)
Your changes are working properly in multiple patterns of data (Single/Multiple)
Exception is catchable

I don't say you have to test every single code, but please test every chunk of code you have changed at least.

I think the code you are changing is surrounded by IF statement. e.g., if($isDeveloper). And when you make it live you remove the statement. Please test if it works properly when you remove the statement. Basically, please test the code when you change in any kind.

This is what I do for testing/debugging for example.

<?php
error_log("\n [".date('Y-m-d H:i:s')."] File:Class:Method:UniqueID:".json_encode($var), 3, $logFilePath);
?>

File:Class:Method:UniqueID is a string for identifying where the log is created. You don't have to follow the rule. json_encode() is for when $var is an array or an object. $logFilePath should be somewhere others cannot access. Don't forget the file permission of the log file is set properly. I store the log file under a directory where nobody can access but us.

Also creating a test module is recommended. Unfortunately the code we maintain is messy, so it is difficult to make the module. But try to make your code testable. I recommend you to google what testable code is. I am studying it, too.

Deploying

Technically we don't have this process, but let me state uploading a file onto the production server is deployment for this time.

Do not create dev file

While you are developing, you want to test on the server. YES, I understand. We don't have neither test env and staging env. But do not create dev file such as index_dev.php.
- It is indexable
  
  As you know that search engine bots are crawling in the Internet. If index_dev.php returns 200, the page potentially can be indexed by Google and other search engines. In the worst case scenario, someone can find the dev page on Google.
- It is accessible
  
  Simply everybody can access even though it is under development.
- It makes possibility of overriding the original file
  
  When you finish development with the dev file, you want to override the original file. It could override changes other developers made.

Documenting

Leave notes what you are thinking, where you changed, etc. Maybe you can see that the tickets I was working on have too many notes ;P

Tools

Shell script

I often make an alias of the command I frequently use. For example:

alias tarc='tar -zcvf'
alias tarx='tar -zxvf'
alias remote='ssh -p 2222 username@servername.com'
alias gst='git status'
alias cnsl='sudo php app/console'

You can chain commands/your aliases with &&. Be lazy!

Atom editor

Shortcut keys

Use shortcut keys

Packages for productivity

remote-ftp: Only use when the remote is my own environment
emmet: If you know ZEN coding and [Emmet](https://en.wikipedia.org/wiki/Emmet_(software) it's a must

Packages for code quality

linter and linter-xxx: Validate the code automatically
script: Run your code in Atom. I use it often to make sure my code works as I expect
atom-beautify: Beautify the code to make it more legible

https://github.com/mgrenier/remote-ftp
https://atom.io/packages/atom-beautify
https://atom.io/packages/emmet
https://atom.io/packages/highlight-column
https://atom.io/packages/highlight-line
https://atom.io/packages/jquery-snippets
https://atom.io/packages/linter
https://atom.io/packages/linter-eslint
https://atom.io/packages/linter-php
https://atom.io/packages/minimap
https://atom.io/packages/script
https://atom.io/packages/php-twig

wataruoguchi/myTwoCents.md

Select an option

No results found