1. How can I break this?
2. Where’s Murphy hiding?
3. Who do I trust?
4. What’s dangerous?
5. What are the real limits?
6. Who is this for?

For example, what could go wrong with this example?

<?php _e( 'What could go wrong here?' ); ?>

Well, it turns out, a lot.

Have you ever tried breaking this by adding malicious scripts in language file? Turns out an innocent function, like this, opens a huge opportunity for people to break things. This was my own revelation a few weeks ago, and it dawned on me that I do not spend enough time trying to break things and learning the skills I need to detect these hidden opportunities in my code. The first step was simply realizing that with every new feature, comes new opportunities, but the following are a few steps I’ve been taking before I complete and turn in any new feature.

How can I break this? (Go break it)

During the drudge of daily tasks and code commits, we often can overlook the need to go in and actually break things we build. The definition of hacking isn’t necessarily malicious; it’s simply taking something and re-purposing it for a different reward. MacGyver was famous for this kind of hacking! That said, hacking is commonly used to break things, and that’s what we’re looking to fix, which is why we should try to break our own stuff.

It takes more than just trusting functions and methods to get the job done. You have to actually get in there and try and break what it is you just made. I feel we aren’t encouraged enough to go in there (and especially spend the time) and be a hacker. But I call all developers out! Become a hacker daily! Break your stuff! In doing so, you are going to build better products, serve your clients better, increase the reliability of your company, and, ultimately, become a better developer.

I also encourage CEOs, business owners, leads, and project managers to change the rhetoric behind security to go beyond just coding, but making the actual act of hacking your own solutions a part of the development process. Tell your developers to ask themselves, before turning in a task or pull request, “How can I break this?” And give developers permission to take the time to become a hacker.

Where’s Murphy hiding?

Anything that can go wrong, will go wrong. – Murphy’s Law

So we’re trying to hack our new feature, and we find a way that a user can pass a combination of query arguments, and somehow, logged in as a subscriber, could possibly run a server-intensive script we just built over and over. I feel (admittedly, through my own experience) we tell ourselves too much that they would never figure out how to do that, and we move on. But someone will!

I’ve just created a problem that will happen in the future. Thinking of these findings as problems that will undoubtedly happen, no matter how unlikely we think it is, will help us keep the internet and clients safe. It allows us to strategize.

Who do I trust?

Developers can be too trusting, and we shouldn’t be. Never trust anyone.

<?php _e( 'What could go wrong here?' ); ?>

In our example here, we might admit that the only one who could really cause a problem are the people who translate. Maybe they’re our own people, maybe they’re strangers, or maybe they’re future translators that a client hired six months down the road that know nothing about WordPress. Whoever it is, I say, they automatically get the “I don’t trust you” stamp of non-approval. It’s strange, but developers have to live in a very untrustworthy world, and we’re better developers for it! Having an skeptical approach will lead you to creating more secure code and features. Take your paranoia and make something rock solid.

What’s dangerous?

In the spirit of Murphy’s Law and trusting no one, you have to see information itself as a potential transmitters for viruses, illnesses, and things that cause bad things to happen and blow up the Internet. Data and information are dangerous! By shifting your view of information to something dangerous, and hiding some disease inside, we can be better devs.

An example.

$image = get_the_post_thumbnail();
echo $image;

In this example, we might view $image as completely innocent and trustworthy.

But it’s not.

Did you know that get_the_post_thumbnail() has a filter? Yeah, it’s post_thumbnail_html and anyone can filter the output and push out a harmful script! $image is dangerous; variables are dangerous! How do you know someone with server access didn’t inject a Must-Use plugin that filters that output?

If we put on our Hat Of Mistrust, we’ll be aware that leaving that variable alone is risky, and take action:

$image = get_the_post_thumbnail();
echo wp_kses_post( $image );

This should allow img tags that are allowed in the WordPress post editor, and if anyone tries to inject a harmful script, it won’t let them. We need to start seeing information as potentially dangerous, and ask ourselves if it is, because we don’t know all the filters or ways people can turn information against us. Using critical thinking and strategy in the ways we work helps us stay one step ahead of people who either don’t know or possess malintent.

If we were really paranoid, we might write something like:

$image = get_the_post_thumbnail();
echo ( is_string( $image ) && stristr( $image, '<img' ) ) ? wp_kses_post( $image ) : '';

What are the real limits?

Another question I think developers rarely ask themselves are, “What are the real limits?”

Really thinking about this question can produce interesting answers.

For instance, what is the limit of get_posts? At first, you might think, well -1 (I did). Set that posts_per_page to -1 and we’ll get all the things, yeah baby! But, a smarter developer might find that…

• The server’s execution time is a limit
• The server’s memory is a limit
• 15, the limit is 15; there will always be 15

We should be thinking about real limits, not just limits in code, and what happens when these limits are reached. Like the server’s execution time or memory limits resulting in a 503. Or, getting fifteen posts–no harm there, right? Have you ever asked yourself how many posts_per_page actually result in a timeout or a 503 on your server? It’s a good question.

Our job as developers is to eliminate the harmful effects of reaching real limits and we need to be aware of what these limits are and make sure we’re not breaking them.

Who is this for?

The last question I pose developers to ask is,

“Who is this for?”

I think every feature should have a name associated with it. Is it all administrators, or all authors? Is it just Jane or Joe? Is it the United States? Are they English speakers or Spanish speakers? Who are these people!?

Knowing (or even guessing at) who will be using our features, by giving our features ownership, helps make sure we’re prepared to create features with privilege in mind.

Even if your answer is “everyone,” we probably should be looking hard at the detailed, real time answers. For instance, “everyone” includes many languages; how many Spanish speakers need to use your product? Do you have a plan to have your content translated? What about A11y? That includes everyone too! Thinking of your features as privileged and belonging to someone helps us take more responsibility with our features, who has access, and who shouldn’t. This also allows you expand your reach and make sure that people who might otherwise be excluded in a generic “everyone” can access what you made.

What about you?

Do you have any tactics that help you build more secure features? What are some ways you work secure features into your build?

The post The Six Questions Developers Need to Ask Before Turning in Tasks appeared first on WebDevStudios.

How do we consistently create and maintain a high level of quality code? Through peer code reviews.

All developers at WebDevStudios are encouraged to request code reviews and to provide their own feedback to others on their code review requests.

Peer code reviews have enhanced the code quality at WebDevStudios by leaps and bounds. Now instead of coding in a hole, all the developers are actively striving to write good, clean code that will pass a code review the first time. Instead of feedback coming in the form of correction from a (busy) lead it has become a game amongst the developers to see who can write the most elegant and bug free code the first time out the gate. As a result, the coding standards and practices at WebDevStudios have grown and enhanced.

This all sounds good, but how does it work in practice?

When we receive a new project, it goes through an architecting phase that identifies all the key elements that will be required. These elements are then further broken down into their respective features. We utilize the Git code versioning system and its branching model to create a unique branch per feature, which we have detailed in a previous post titled An Alternative Git Flow for Client Work.

After a developer has finished a feature and before merging it back into the main branch, a code review is requested. Doing the code review at this step allows the reviewer to see all of the changes made on the feature branch compared to the main branch quite easily. The reviewer can then switch between branches to verify the feature code works and, if so desired, merge the feature into other branches to review against.

Reviews may be done by more than one other developer and have sometimes spurred incredible conversation and debate on the merits of performing an operation this way versus that way.

Code reviews promote healthy culture

As developers we are very proud of our code. Code is our form of art–where we express our inner Rembrandt. As such, critique of our artistry can be a stinging blow to our egos. I have seen instances where developers have nearly come to (virtual) blows when one suggests a change to the other’s code. Creating a healthy culture for code reviews counters any negative feelings that may arise.

We are all on the same team and we all have the same goal: To deliver the highest quality product to the client. When I was young my mother used to tell me, “If you do not have anything nice to say do not say anything at all.” We have applied the same motto to our code reviews. Feedback is never negative, but always constructive. By using positive language and helpfully showing each other new tricks and techniques, the skills of WDS devs have increased across the board and we have grown closer as a team.

Code reviews enhance security

Let’s admit it: All of us have written some code with a vulnerability issue. The most common of which is SQL injection points through unsanitized input. While coding, it is easy to become wrapped up in getting the feature done and lose sight of all the security implications of what you are writing. Having another set of eyes review the code can help to identify weaknesses.

This is further backed up by looking at a few of the major exploits that have been found in the WordPress ecosystem this year alone. Many of them were not found by probing the application, but by looking at the released source code and finding some place allowing unsecured input.

Code reviews increase social recognition and a feeling of self-worth

This may sound strange but there is powerful psychology behind code reviews. Providing code reviews causes us to feel good about helping out another, and receiving a code review that does not indicate anything needs to be updated in your code becomes almost a drug unto itself. Developers tend to amp up their game to “beat” the reviewers. Even us lead developers have our code reviewed, and I can tell you that nothing excites the team more than poking holes in code of the “best” developers on the team. (…Yeah, I had a code review only critiquing my use of white space…).

Is it really worth the extra time?

When working on client projects time is of the essence, so we had to ask ourselves, “Is this worth the extra time it will take to develop a feature?”

The resounding answer is YES!

The increase in code quality and skills of the developers alone makes code reviews worth it, and the added benefit is finding bugs to be squashed well before being introduced in production.

According to a 2002 report by the National Institute of Standards and Technology a bug found post-production takes 18.7 hours to find and fix while a bug found during a code review takes just 3.2 hours to fix! That is 15.5 hours saved! What “extra time” are you worried about!?

Go forth and review thine code

As you can see, the idea behind code reviews is a simple one but it has BIG benefits. I want to encourage you to begin integrating code reviews into your workflow.

You may not have a team like we do here at WebDevStudios, but if you are reading this, you are part of the team of the community. WebDevStudios is just one fish in this pond that we call WordPress. Together, we are all striving to enhance this product that we use and love. Now get out there and start doing those code reviews!

I would love to hear about your experiences with code reviews in the comments and how your company or organization has implemented them.

The post Winning With Code Reviews appeared first on WebDevStudios.