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

Привет!

Если вы уже определились с целью проекта и написали список требований, то пора приступать к разработке архитектуры вашего проекта.

Следующие контрольных список советов поможет вам правильно составить архитектуру вашего сайта, при чем речь идет больше о коде приложения, чем об общей структуре, но думаю правила для общего случаю будут очень похожи.

Итак приступим:

• Ориентируйтесь на правило 80/20: описывайте 20% процентов классов, которыми на 80% определяется поведение системы.
• Прямой доступ к данным обычно следует предоставлять одной подсистеме или классу. Не надо вставлять sql запросы в шаблоны :)
• Архитектура должна быть модульной, чтобы GUI можно было изменить, не затронув бизнес-правил и модулей программы, отвечающих за вывод данных.
• Архитектура должна определять подход к безопасности системы на уровне кода. Если модель угроз до сих пор не разработана, это следует сделать при проектировании архитектуры.
• Масштабируемостью называется возможность системы адаптироваться к росту требований. Архитектура должна описывать, как система будет реагировать на рост числа пользователей, серверов, сетевых узлов, записей в БД, транзакций и т.д. Если развитие системы не предполагается и ее масштабируемость не играет роли, это должно быть явно указано в архитектуре.
• Основной проблемой характерной для крупных систем, является поддержка ее концептуальной целостности – архитектура должна быть концептуально целостной, ничего лишнего и все на своем месте.
• Хорошая архитектура должна соответствовать проблеме.
• В архитектуре должны быть обоснованы важнейшие принятые решения.
• Архитектура должна включать описание системы с разных точек зрения.

Возможно стоило бы включить в этот список и такие важные для архитектуры пункты как:

• Ввод-вывод
• Организация данных
• Бизнес правила
• Производительность
• Взаимодействие с другими системами
• … и т. д.

список можно продолжить в комментариях..:)

Если не будет проведено хоть какое-нибудь проектирование архитектуры, то во время написания кода вы можете решать верную проблему неверным способом. По мере написания кода для неверной архитектуры цена изменений архитектуры возрастет, так что перед началом программирования вы должны проверить и правильность архитектуры.

Привет, сегодня приведу цитату из книги Д. Полья “Как решать задачу”.

Д.Поля разработал подход к решению математических задач, который полезен и при решении проблем, связанных с проектирование ПО.

1. Понимание постановки задачи.

Нужно ясно понять задачу. Что неизвестно? Что дано? В чем состоит условие? Возможно ли удовлетворить условию? Достаточно ли условие для определения неизвестного? Или недостаточно?

Сделайте чертеж. Введите подходящие обозначения. Разделите условия на части. Постарайтесь записать их.

2. Составление плана решения.

Нужно найти свзязь между данными и неизвестными. Если не удается сразу обнаружить эту связь, возможно, полезно будет рассмотреть вспомогательные задачи, в конечном счете необходимо придти к плану решения.

Не встречалась ли вам раньше эта задача? Хотя бы в несколько иной форме? Известна ли вам какая-нибудь родственная задача? Не знаете ли теоремы, которые могли бы оказаться полезными?

Рассмотрите неизвестное! И постарайтесь вспомнить знакомую задачу с тем же или подобным неизвестным. Вот задача, родственная данной и уже решенная. Нель ли воспользоваться ею? Нельзя ли применить ее результат? Нель ли использовать метод ее решения? Не следует ли ввести какой-нибудь вспомогательный элемент, чтобы стало возможно воспользоваться прежней задачей?

Нельзя ли иначе сформулировать задачу? Еще иначе? Вернитесь к определениям.

Если не удается решить данную задачу, попытайтесь сначала решить сходную. Нельзя ли придумать более доступную сходную задачу? Более общую? Более частную? Аналогичную задачу? Нельзя ли решить часть задачи? Сохраните только часть условия отбросив основную часть:насколько определенным окажется тогда неизвестное, как оно может меняться? Нельзя ли извлечь что-то полезное из данных? Нельзя ли придумать другие данные, из которых можно было бы определить неизвестное? Нельзя ли изменить неизвестное, или данные, или, если необходимо, и то и другое так, чтобы новое неизвестное и новые данные оказались ближе друг к другу?

Все ли данные вами использованы? Все ли условия? Приняты ли вами во внимание все существующие понятия, содержащиеся в задаче?

3. Осуществление плана.

Нужно осуществить план решения. Осуществляя план решения, контролируйте каждый свой шаг. Ясно ли вам, что предпринятый вами шаг правилен? Сумеете ли доказать, что он правилен?

4. Взгляд назад.

Нужно изучить найденное решение. Нельзя ли проверить результат? Нельзя ли проверить ход решения? Нельзя ли получить тот же результат иначе? Нельзя ли усмотреть его с одного взгляда? Нельзя ли в какой-нибудь другой задаче использовать полученный результат или метод решения?

Привет.

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

read more »

При создании или модифицировании таблиц используя MyISAM, вы можете запросить MySQL хранить строки в фиксированном или динамическом формате. Если таблица не содержит BLOB и TEXT полей, то фиксированный формат выбирается по умолчанию, который автоматически конвертирует VARCHAR в CHAR. Иначе, если выбрать динамический формат, то MySQL конвертирует все колонки из типа CHAR в VARCHAR.

Для MySQL, фиксированный формат легче в доступе, кешировании и обновлении информации. Также этот формат менее подвержен порче данных. Если дисковое пространство не является критическим, то фиксированный формат будет хорошим выбором.

Динамический формат использует меньше дискового пространства, но более подвержен риску фрагментации и/или порче данных.

Но давайте сначала посмотрим, на тесты и потом сделаем окончательное заключение.

read more »

Недавно наткнулся на интересную Late Static Bindings Explained, описывающую новую возможность OOP в PHP6, так называемое Late Static Binding (LSB).

Позднее статическое связывание также стало доступно, начиная с версии PHP 5.3.

Зачем нужен LSB

Сейчас, статическая ссылка на текущий класс, такая как self или __CLASS__ распознается используя класс в которому текущая функция принадлежит, например:

<?php
class A {
public static function who() {
     echo __CLASS__;
}
public static function test() { 
    self::who();
}
}
class B extends A {
public static function who() {
     echo __CLASS__;
}
}
B::test(); // A
?>


LSB пытается решить эту проблему используя новое ключевое слово static::, которое будет ссылкой на тот класс, который был вызван в текущий момент времени.

<?php
class A {
public static function who() {
     echo __CLASS__;
}
public static function test() { 
    static::who();
}
}
class B extends A {
public static function who() {
     echo __CLASS__;
}
}
B::test(); // B
?>


Такая конструкция вызовет метод A::test, но static:: будет ссылаться на класс B, при не статическом связывании, будет выщван метод A::who, так как $this-> следует правилал наследования, а static:: нет.

Примеры

Наиболее распостраненный случай:

read more »