ColdFusion позволяет легко начать написание кода. Это не так уж и хорошо в том смысле, что нет ничего хуже отсутствия предварительной продуманности работы. Планированию следует уделять больше времени, чем написанию кода.
Планирование заставляет задуматься над каждым аспектом вашего приложения: от разработки базы данных до пользовательского интерфейса, от списка возможностей до типа языка. Вы никогда не сможете построить дом без подробных чертежей (впрочем, вы можете попытаться, но никто вам не даст необходимых разрешений начать работу) и построение приложений основано на том же принципе.Меня постоянно просят взглянуть на какие-либо приложения и я постоянно удивляюсь, что у них нет сопроводительной документации. И это случается не только с маленькими фирмами, но и с очень серьезными корпорациями. Проблема в масштабируемости? Без сомнений. Я удивлюсь, если такое приложение будет расширенно. Проблемы развития, отсутствия ошибок, возможности управления зависят от разработчиков.
Конечно, иногда клиенты просто хотят, чтобы работа была выполнена. Конкуренция может потребовать: «Срежь углы или потеряешь заказчика» - и планирование всегда является той частью работы, которую обходят стороной. Так что же делать? Вы можете все сделать так, как от вас требовалось и, вероятно, оставить клиента недовольным и, тем самым, создать для себя еще больше работы. Или вы можете отказаться от работы (идеалистично или, возможно, даже не всегда реалистично). Тяжело принять такое решение, но что бы вы ни делали, помните, что клиент всегда заинтересован в получении именно того, что он хочет и, вместе с этим, не упускайте возможности отойти от точных требований, чтобы оградить себя от неприятностей в будущем.2. Организуйте ваше приложение.
Следствием планирования вашего приложения можно считать его организацию. Приложения состоят из множества маленьких частей, которые необходимо содержать в организованном виде.
Организация включает структуры директорий и определения, где должны находиться общие файлы, перемещение картинок в отдельные директории, разделение больших файлов на несколько маленьких и даже налаживание последовательной организации между различными приложениями.Целью организации является обеспечение более легкой работы с приложением как для разработчика, так и для того, кто будет заниматься им потом. Все организационные моменты должны быть детально документированы.
3. Следуйте стандартам написания кода.Этим интересуются наиболее часто. Макромедия не публикует формальные рекомендации о стандартизации кода, да и не должна этого делать, т.к. ее задачей является создание хороших продуктов для нас разработчиков, а нашей задачей является использовать эти программы как можно эффективнее для нас. Конечно, определенный набор стандартов не подойдет для всех разработчиков, но, в то же время, разработчики не должны не придерживаться каких-либо стандартов.
Стандарты написания кода включают в себя все: от создания имен для файлов или директорий до создания имен для переменных, соблюдение последовательности использования кода, управления ошибками, разработки компонентной модели и т.д. (Например, если все имена переменных даты начинаются с dt, то обращение к переменной dtOrderDate будет интуитивно понятно).Использование стандартов кодирования предполагает некоторый уровень последовательности в вашем коде. Определенный стандарт написания кода предполагает наличие механизма, при котором код сам себя описывает и объясняет.
Не существует каких-то определенных стандартов в кодировании. Единственная неправильная вещь в кодировании – это отсутствие и не использование стандартов. Перед разработкой своего стандарта рекомендую ознакомиться со статьей www.corfield.org/coldfusion/coding_standards/.Не пытайтесь следовать современным тенденциям. То, что хорошо для других может вам не подойти и то, что хорошо для одного вашего приложения может не подойти для всех ваших приложений.
4. Комментируйте ваш код.Этот пункт очевиден, но, тем не менее, не многие из нас уделяют этому внимание. Как бы там ни было весь код должен быть комментирован. (к слову, я бы заставил сотрудника расставить комментарии в коде, т.к. это очень важный момент в кодировании).
В любых файлах с исходным кодом должны быть заголовки: описание программы, информация об авторе, дата создания, хронологический список изменений, все связи с другим кодом и т.д. Также любая проверка условий (cfif ... cfelse …), любой цикл (cfloop), любые обозначения переменных, любые подключения внешних файлов (cfinclude) и вызовы компонент должны сопровождаться простым комментарием о том, что происходит и почему.Знаю, что это неприятно, но, открыв свой код спустя некоторое время, вы оцените свои усилия.
5. Сначала функциональность, потом возможности.Это еще один очевидный пункт, где наиболее часто встречаются ошибки. Да, уделять в первую очередь внимание эффектам пользовательского интерфейса гораздо приятнее, чем составлять бизнес правила, но последний пункт куда более важнее для успеха вашего приложения. Концентрируйтесь на создании полностью рабочего приложения, потом по необходимости улучшайте его эффектами.
Но в то же время, не пренебрегайтесь опытными пользователями. Некоторый из самых лучших приложений «провалились» (и продолжают «проваливаться») потому, что ими неудобно пользоваться. Ошибочно начинать разработку с меню и подбора цветовых схем, но еще более ошибочно не уделить этому должное внимание потом.Все должно быть сбалансировано. Конечный результат может быть не так хорошо, как хотелось бы, но печально может быть то, что даже в плохо выглядящем состоянии приложение действительно работает. Более того, очень трудно отладить логические проблемы, когда код содержит слишком изысканные форматирование и особенности.
6. Производите дополнительное тестирование.Часто бывает так, что основной код никогда не тестируется в отдельности от приложения. Тем не менее, если вы, например, разрабатываете общие компоненты для всего приложения, то предварительно тестируйте их в отдельности. Тяжело прилагать дополнительные усилия для написания дополнительных тестовых участков кода, но это нужно делать, делать, делать. Очевидно, создав приложение полностью и протестировав его, вы обнаружите проблемы, которые раньше не появлялись, но чем больше вы будите тестировать отдельные участки кода в отдельности, тем лучше.
7. Никогда "не изобретайте колесо".Создавайте код так, чтобы потом можно было повторно использовать его в других проектах. При разработке кода старайтесь, чтобы он был прост, только в крайних случаях зависел от специфики приложения и никогда не делайте ссылки на переменные вне этого кода.
Польза? Использование универсальных участков кода позволит сократить время разработки приложения. Также в коде гарантированно не будет ошибок, т.к. он уже предварительно был опробован и протестирован. К тому же, отдельно взятые компоненты можно легко дорабатывать, не затрагивая приложение в целом.ColdFusion разработчики имеют множество много раз повторяющихся опций и им следует обратить внимание на ColdFusion компоненты (CFC).
8. Для реализации проекта используйте все возможные инструменты, а не только ColdFusion.ColdFusion приложения обычно не самодостаточны. Они зависят от серверов баз данных, почтовых серверов и т.п. ColdFusion может быть рычажной силой для Java, Веб служб, COM, CORBA, C/C++. Используйте эти инструменты столько, сколько нужно, всегда выбирая лучшее из них для конкретной работы. Самые лучшие ColdFusion приложения не те, которые написаны только на ColdFusion, а те, в которых используется лучшая подходящая для поставленной задачи технология.
Если вы серьезно занимаетесь разработкой приложений, то в ваших же интересах расширять круг своих навыков. Это позволит вам стать более «гибким» разработчиком и на четверть улучшить ваши ColdFusion приложения.
9. Уважайте (и бойтесь) производственные сервера.Создавайте свой код, тестируйте его, при необходимости отлаживайте, поместите его на тестовый сервер, еще раз тестируйте и тестируйте и только потом, наконец-то, размещайте его на производственном сервере. И не повторяйте этот процесс слишком часто. Вместо того, чтобы каждый день обновлять слегка измененный код, лучше собирайте изменения, тестируйте их еще и еще и обновляйте все изменения разом раз в неделю, месяц или с той периодичностью, которая вам подходит.
Эта часть относится к уважению. Бояться нужно потому, что производственные сервера уязвимы. Они неизбежно доступны публично и неизбежно используются людьми совершенного разного сорта.Небольшое чувство паранойи можно считать нормой, если дело касается публично видимых серверов. Представьте, что ваш сервер будет скомпрометирован и все, что на нем есть (или все, к чему он имеет доступ), будет либо украдено, либо частично изменено. Отсюда вывод – никогда не вставляйте пароль в исходный код, не храните базы данных на веб сервере, не используйте учетные записи, у которых есть доступ к другим ресурсам.
Для большей убедительности следует повторить, что все, что есть на вашем сервере или все, к чему ваш сервер имеет доступ, может быть украдено или изменено. Будьте напуганы, очень сильно напуганы и, находясь в борьбе со своим страхом, будьте разумны и осторожны.Главное, что можно подчеркнуть, это то, что производственный сервер священен. Вообще не прикасайтесь к нему без необходимости (и чем реже, тем лучше) и никогда не делайте на нем изменения (даже самые незначительные). Кроме того, никогда не оставляйте уязвимые места открытыми и никогда не храните на сервере то, что не должно попасть в чужие руки.
10. Будьте проще.Простота – хорошая штука, а сложность нет. Это относится ко всему: от пользовательского интерфейса и построения схем баз данных до документирования архитектуры приложения.
Мне приходилось видеть относительно простые приложения (приложения, которые можно разработать за несколько дней), которые были превращены в гигантские проекты, предполагая, что все приложения являются MVC приложениями. Я не имею ничего против MVC, но мы не живем в мире, где все имеет один размер. Если более простой дизайн эффективен, то этого уже достаточно.И наоборот, нельзя сильно упрощать, что какая-то работа может быть выполнена только с помощью ColdFusion, а какая-то только с помощью Java. Есть вещи, которые требуют участие обеих технологий одновременно.
© 2002-2005 г. Вадим Пушкарев