Просто про веб технологии

Привет.

Как часто мы пишем код и потом замечаем, что его невозможно не только читать, а и сопровождать. Чем больше наращивается функциональности, тем меньше мы хотим продолжать работать с этим кодом. И в данной ситуации есть два решения: первое оставить все как есть и второе изменить код к лучшему, поработать над читабельностью, архитектурой, провести рефакторинг, написать тесты и т.д. В этой статье я хочу дать несколько хороших советов, как создавать приятный и легко сопровождаемый код.

1. Форматируйте свой код придерживаясь одного стиля

• Легко написать код для компьютера, но тяжело сделать его понятным человеку
• Код читают более часто, чем пишут
• Код должен быть читаемым

Плохо читаемый код:

<?php
$bool = ($i<7&&$j>8||$k==4);
if ($a == $b) {
if ($b > 4){
do_something(); }
} else {
do_something_else();
}
?>

• Форматируйте свой код придерживаясь одного стиля
• Придерживайтесь стандарта кодирования
  • Как делать отступы
  • Где ставить пробелы
  • Когда писать заглавными
• Воспользуйтесь одним из существующих стандартов кодирования

2. Придерживайтесь одному стилю наименования

• Придерживайтесь одной схеме наименования
• Давайте простые имена файлам
• Ставьте префикс в глобальном пространстве имен

processData()
doIt()
innerLoop()
$del_pos
checkConnection() vs. isConnected()
$filename vs. $fileName
open_connection($a, $b, $c, $d);
ftp_connect($server, $port, ...);

3. Пишите документацию к API

• Документируйте public интерфейсы
• Читаемый код вместо комментариев
• Используйте PHPDoc
  • Специальный блок комментария
    /**
    *
    */
  • Специальные @tags (@author, @version, @param, @returns)

/**
* This is what the class does.
*
* @package PackageName
* @author Your Name
* @version 1.0.0RC2
*/
class myFooClass
{
/**
* @param $aBar the Bar
* @param $aBaz the Baz
* @return bool success
*/
public function doFoo($aBar, $aBaz)

4. Не создавайте повторяющийся код

• Не создавайте повторяющийся или похожий код
• Цель: делать изменения в коде в одном месте
• Создавайте параметризированные функции и методы “helper functions”
• Много не обобщайте, пользуйтесь рефакторингом

До:

if (isset($_REQUEST['action']))
{
if ('add' == $_REQUEST['action'])
{
$q = $db->query('SELECT quantity FROM data WHERE item=\'' . $_REQUEST['item'] . '\'');
$quantity = $q->current(SQLITE_NUM);
$quantity = $quantity[0];
$quantity++;
$q = $db->queryExec('UPDATE data SET quantity=' . $quantity . ' WHERE item=\'' .
$_REQUEST['item'] . '\'');
}
if ('remove' == $_REQUEST['action'])
{
$q = $db->query('SELECT quantity FROM data WHERE item=\'' . $_REQUEST['item'] . '\'');
$quantity = $q->current(SQLITE_NUM);
$quantity = $quantity[0];
if ($quantity > 0) $quantity--;
$q = $db->queryExec('UPDATE data SET quantity=' . $quantity . ' WHERE item=\'' .
$_REQUEST['item'] . '\'');
}
}

После:

if (isset($_REQUEST['action']))
{
if ('add' == $_REQUEST['action'])
{
$quantity = get_quantity($_REQUEST['item']);
$quantity++;
update_quantity($_REQUEST['item'], $quantity);
}
if ('remove' == $_REQUEST['action'])
{
$quantity = get_quantity($_REQUEST['item']);
if ($quantity > 0) $quantity--;
update_quantity($_REQUEST['item'], $quantity);
}
}

5. Короткие блоки кода

• Разбивайте код на мелкие кусочки
• Метод или функция должны поместиться на экране без прокрутки
• Когда код нуждается в комментариях (много комментариев), то возможно он слишком сложный
• Пишите код с не более чем 3 уровнями вложенности
• Если вы не понимаете функцию или метод за 30 секунд, то возможно код слишком сложный

6. Разделяйте разные концепции

• Трех-уровневая архитектура
  • Представление
  • Бизнес логика
  • Данные
• Функциональность (add, remove, modify)
• Ввод (пре)обработка
• Никакого SQL рядом с HTML
• Создавайте Unit тесты простыми, потому что логика отделена от презентации и данных
• Код должен максимально пере-использоваться
• Код становиться легче читать, когда вы сконцентрированы на одном аспекте

7. Исправляйте реализацию

• Используйте PHP вместо старых расширений
• Используйте компоненты (PEAR, Zend Framework, ezComponents)
• Используйте PHP расширения (XMLWriter, SOAP)
• Перепишите плохие методы и функции
• Придерживайтесь API
• Если вы не изменяли глобальные переменные, то изменения не должны повлиять на остальной код

Что такое рефакторинг

• Изменение кода
  • Для улучшения читабельности
  • Для упрощения структуры
• Без изменения поведения
• Без добавления функциональности
• “Чистый” код
• Улучшенный дизайн
• Важная часть Agile методологии
• не только для OOP
• интересный опыт
• и это классно делать это!

Зачем рефакторинг

• Мир постоянно меняется
  • окружение меняется
  • терминология меняется
  • требования меняются
• Проектирование ПО меняется со временем
• Мы никогда не делаем все правильно в первый раз
• До того, как добавить новую функциональность
  • Рефакторинг, до того пока не будет ясно как добавить новую функциональность
• Когда вы непонимаете код
  • Делая код более читабельным
• Когда исправляете баг
• После пересмотра кода

Как делать рефакторинг

• Запустите тесты, чтоб убедиться, что все работает
• Рефакторите по одному шагу за раз
• Перезапустите тесты, чтоб убедиться, что все еще, все работает

Тестирование

• xUnit Framework for PHP
  • PHPUnit (www.phpunit.de)
  • SimpleTest (www.simpletest.org)
• Не только для объектно ориентированного кода
• Если у вас нет тестов, создайте их
• На крайней случай, запускайте проверку:
  • php -l <filename>

Слайды Stefan Priebsch на английском: The Seven Steps to Better PHP Code (PDF)

Tags: OOP, phpunit, unit test, код, метод, рефакторинг, тесты, функция, читабельный код

This entry was posted on Wednesday, March 19th, 2008 at 5:35 pm and is filed under Development, PHP. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.