В последнее время я много размышлял о всех небольших служебных приложениях, которые я программировал на протяжении многих лет, и о том, как я мог бы разработать их лучше.
Я свободно определяю утилиту как любой проект, предназначенный для решения особой и конкретной проблемы для определенной ситуации или бизнес-процесса.
Например, я создал небольшое приложение PHP, которое принимает экспорт из магазина электронной торговли и анализирует данные в другом формате, необходимом для определенного бизнес-процесса.
Как я мог спроектировать это лучше?
Обычно я создаю утилиту, имея представление о проблеме, которую нужно решить, и сразу же переключаюсь в редактор и начинаю печатать.
Некоторое время спустя я захочу украсть функциональность из старых утилит, но когда я собираюсь повторно использовать некоторый код, я узнаю, насколько плохо я его запрограммировал! Обычно я не трачу много времени на небольшие утилиты, поэтому они программируются без классов, пространств имен и даже ООП. Процедурный FTW!
Это заставило меня думать, что я должен быть более организованным, даже в крошечных проектах.
Вот некоторые вопросы, которые я сейчас рассмотрю перед началом любого нового проекта.
1) Основы обязательны!
Независимо от крошечной утилиты, попрактикуйтесь в хорошем программировании ! Используйте правильное исходное форматирование, соглашения об именах и комментарии. Другой разработчик должен иметь возможность увидеть, что происходит в коде, без особых усилий.
Избегайте процедурного кодирования, где это возможно.
Я больше не позволяю себе писать неаккуратный код, даже если проект крошечный или ограниченного использования.
2) Определить проект
Не имеет значения, должна ли утилита выполнять одну функцию: она должна быть четко определена до начала кодирования. Определение приложения будет включать в себя базовые объявления, например, кто будет его использовать, какие данные он ожидает и какой вывод он должен предоставлять.
Определите источники данных, вопросы безопасности и то, будет ли приложение со временем расширяться с помощью большего количества функций.
Где будет находиться утилита?
Чем более подробное определение, тем легче выбрать инструменты и оставаться в области его действия при программировании. Это особенно верно, если вы программируете для кого-то другого!
3) Будут ли другие работать над этим?
Если будут участвовать другие программисты, увеличьте вашу документацию и комментарии. Используйте контроль источников и сосредоточьтесь на разделении проблем в ваших классах и методах.
Если никому из программистов не понадобится читать ваш код или работать над ним, кроме вас , придерживайтесь основ и не перегружайте себя. Просто убедитесь, что вы все еще можете понять это!
4) Исходный контроль?
В зависимости от контекста утилиты, например, если это внутренний проект для организации, которая будет владеть работой, код может быть размещен в общедоступном хранилище. Если так, увеличьте документацию; добавить файл readme.md добавьте DocBlocks для определения владельца кода и используйте семантическое управление версиями .
Если есть сомнения по поводу интеллектуальных прав и того, кому принадлежит код, для этого потребуется добавить туда лицензию .
5) Должен ли я поддерживать его в течение длительного времени?
Если вы предвидите будущее развитие, предположите, что другие будут работать над приложением, и поэтому для него требуется контроль версий, улучшенная документация и прилагаемая лицензия .
Вы не можете быть человеком, который будет поддерживать будущие версии, если приложение является внутренним для организации. Лучше потратить дополнительное время на эти хлопоты, чем на то, чтобы будущие программисты уволили вас с должности плохого программиста .
Если вы пишете хорошо документированный код, вы можете вернуться позже и получить рекомендательное письмо. (Вы не можете взять с собой принадлежащий компании код, но по крайней мере у вас будет письмо, подтверждающее, что вся ваша работа была хорошей!)
6) Должен ли я создать API, библиотеку или ни то, ни другое?
Определение API и библиотек выходит за рамки этой статьи, но это все же важное решение, потому что оно изменит всю методологию вашего кодирования.
Будет ли инструмент автономным , или вы будете распространять его в виде библиотеки, или вы хотите, чтобы другие могли получить доступ к функциональности через интерфейс API?
Если вы идете по маршруту API, вам понадобится надежная обработка всех входов и выходов, проверка данных, преобразование данных, безопасность, маршрутизация HTTP, конечные точки и так далее. Шифрование и аутентификация тоже становятся проблемой.
7) CMF, бэкэнд, конфигурация?
Нужна ли самой утилите свой собственный интерфейс управления, отдельный от внешнего интерфейса?
Нужен ли вам сервер для доступа администратора к управлению утилитой?
Самая большая проблема заключается в том, что любая инфраструктура управления контентом (CMF), вероятно, даст вам много раздувания и функций, которые вам не нужны, просто для запуска небольшой утилиты. Но опять же, CMF, скорее всего, предоставит вам свой собственный API и вспомогательные инструменты, которые могут пригодиться.
Кроме того, вы можете хранить всю информацию о конфигурации в одном файле, к которому имеют доступ только администраторы.
В большинстве случаев я просто создаю файл config.php
8) Управление пакетами?
Управление пакетами — это крутой ребенок, но это не значит, что нам нужно общаться и дружить!
Легко включить несколько библиотек без использования управления пакетами.
Я обнаружил, что использую его только тогда, когда мне нужно более двух или трех модулей, или если эти модули сложны.
Если вы решите использовать модули Composer (для PHP), то я также предлагаю построить вашу утилиту в соответствии с правилами Composer, чтобы вашим проектом можно было управлять через Composer. Используйте спецификацию PSR-4 , имена папок и соглашения об именах для классов и так далее.
9) Front-end Framework?
Сложный интерфейс может возникнуть, когда пользователь должен выполнить много шагов, загрузить файлы, заполнить формы, просмотреть данные, визуализировать данные и т. Д. Поскольку интерфейс становится более сложным, вы можете рассмотреть возможность использования инфраструктуры интерфейса.
Под фреймворком
я на самом деле имею в виду CSS-фреймворк, такой как Bootstrap, Foundation или даже что-то большее, включающее в себя больше визуальных модулей и виджетов JavaScript, таких как jQuery или другие.
Я обычно пишу весь CSS с нуля, но если проект станет слишком большим, я, возможно, переписываю Foundation .
10) мне нужно войти?
Требуется ли вам какая-либо историческая запись действий, предпринятых утилитой? Вам понадобится контрольный журнал того, кто что, когда, откуда и в течение какого времени делал?
Опять же, если мы находимся в корпоративной среде и утилита предназначена для использования несколькими людьми, для отслеживания может потребоваться журнал.
Хорошие библиотеки журналов доступны в менеджерах пакетов, поэтому при необходимости это может быть причиной для использования управления пакетами.
11) Нужна ли мне усиленная обработка ошибок?
Большую часть времени я создаю утилиты, не задумываясь об обработке ошибок. Я склонен программировать со всеми показанными ошибками, и как только все работает, и в моем тестировании ошибок нет, я вообще отключаю показ ошибок.
Вам следует подумать о том, нужна ли вам сложная обработка ошибок, внешние сообщения, функции отмены
, управление кнопками назад, кнопка автосохранения и сохранения, всплывающие окна и модальные окна, и будет ли это связано с системой ведения журнала.
Обратите внимание, что регистрация, аудит, управление ошибками должны быть частью ранних спецификаций. Это должно помочь вам принять решение об использовании управления пакетами и инфраструктур с самого начала.
12) Нужна ли мне дополнительная безопасность?
Если ваша утилита выполняет деструктивное управление данными или требует аутентификации пользователя, то дополнительная безопасность не составляет никакого труда.
Я склонен думать, что как только вам понадобится надежная защита, используйте платформу со встроенными функциями. Вы можете использовать платформу без интерфейса управления, такую как Laravel, Kohana, Slim, Silex и многие другие. Или используйте фреймворк с таким интерфейсом, как MODX, ProcessWire или Bolt. Просто убедитесь, что у фреймворка есть нужные вам функции.
Изобретать колесо просто не нужно. Не пишите свои собственные журналы, безопасность, аутентификацию пользователя, абстракцию базы данных и т. Д. Просто используйте на этом этапе фреймворк.
13) Это публично?
Один большой вопрос, который нужно задать, заключается в том, предназначен ли инструмент только для внутреннего использования, или вы разрешите доступ из общей сети. Если первое, то оно все еще открыто для организации, где десятки или сотни людей будут иметь трещину?
Вы должны будете убедиться, что ваши конечные точки четко определены, и что вы защищаете все вспомогательные файлы и сценарии по мере необходимости.
Если вы подозреваете высокий трафик, вы говорите о механизмах кэширования, особенно там, где создаются базы данных или высокодинамичные данные. Мы также говорим о безопасности, регистрации, аутентификации и так далее.
Как правило, я бы сказал, что если вы создаете небольшую утилиту для предоставления планете в целом, используйте все общие библиотеки, инструменты, методы, документацию и даже каркас.
Не стоит возиться, когда дело доходит до раздачи публичного доступа: все ставки сняты, так что просто делайте все по книгам с современными, хорошо протестированными модулями и фреймворками!
Как насчет тебя?
Вот некоторые вещи, о которых я думаю, прежде чем открывать Sublime или Netbeans для запуска проекта.
Может быть, у вас уже есть набор общих инструментов, которые вы используете для служебных приложений? Я хотел бы знать, что это такое, потому что большие фреймворки, такие как Laravel или полные CMF / CMS, могут быть излишними для коммунальных услуг. У вас есть несколько небольших микро-
фреймворков, которые имеют достаточно
функций, чтобы быстро сделать утилиту?