На протяжении всей своей карьеры я работал над несколькими заданиями, где мне поручали убирать за коллегой-разработчиком, который — после написания нескольких строк кода для автоматизации процесса до написания полноценного приложения — исчезал, оставляя компанию-клиента в одиночестве. отчаянные нужды. Хотя у меня иногда возникало искушение «наказать» клиента за его невежество, после оценки ситуации я обычно понимал, что виноват не клиент, а скорее разработчик, который не смог должным образом сформулировать ожидания и предоставить готовый продукт. заказчику.

На моей нынешней штатной должности я трачу более 50% своего времени на написание кода для поддержки нашего собственного приложения для управления проектами. Текущая версия (с некоторыми значительными изменениями за эти годы) была запущена в производство в 2010 году и до сих пор прекрасно работает. Тем не менее, мир тем временем изменился, поэтому большая часть моих усилий по разработке на данный момент посвящена переписыванию приложения, чтобы привести его в современную эпоху.

Смысл всего этого в том, что я питаю очень низкое мнение о тех давно ушедших разработчиках, о которых упоминал в первом абзаце. Те, кто не удосужился предоставить исходный код (где это уместно), использовать систему контроля версий или даже подготовить самую простую документацию; и хотя я команда из одного человека, я поклялся, что любой, кто придет за мной, не будет страдать так, как я. Итак, в этом посте я опишу шаги, которые я предпринял, чтобы сделать мой маленький мир разработки лучшим местом для тех, кто когда-нибудь пойдет по моим стопам.

Шаг 1 — Контроль версий

Прежде чем писать какой-либо код, вы должны определиться с системой контроля версий и внедрить ее. Лично я предпочитаю Subversion, так как он содержит все необходимые мне функции — различия файлов между версиями, простые возможности ветвления/тегов и совместимость со всеми операционными системами. В Windows я использую клиент TortoiseSVN, а в Linux — клиент командной строки. Если вы предпочитаете размещать свои репозитории в Windows, VisualSVN Server предоставляет удобный графический интерфейс для управления вашими репозиториями (хотя это и связано с затратами). Кроме того, Проект WebSVN предоставляет красивый веб-интерфейс для ваших репозиториев. При этом подойдет любая хорошо зарекомендовавшая себя VCS, от CVS до Git. Как правило, я структурирую свои репозитории кода с каталогом tags/, содержащим мои выпускные версии, и каталогом trunk/, содержащим мою текущую рабочую версию. Новый выпуск получает собственную папку с номером версии в tags/. Я обнаружил, что обычно этого достаточно; однако не стесняйтесь использовать любую структуру, которая имеет смысл. Выбранная вами структура гораздо менее важна, чем тот факт, что вы используете контроль версий. Я также документирую каждую фиксацию, максимально связывая ее с моим программным обеспечением для отслеживания ошибок/проблем (следующий раздел).

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

  • Сценарий SQL для воссоздания схемы базы данных
  • Резервная копия базы данных с любыми начальными записями, которые необходимы для выполнения установки приложения «по умолчанию», например. учетная запись пользователя «admin» в таблице пользователей, предварительно заполненных таблицах количества/измерений и т. д., а также сценарии SQL для ее создания
  • Любые разные сценарии SQL, относящиеся к проекту, такие как сценарии импорта данных, сценарии производительности/устранения неполадок и т. д.

Наконец, я также держу репозиторий «devops» с копиями всех моих общих файлов конфигурации сервера и рабочей станции, различных сценариев, журналов обновлений сервера и всего остального, что я считаю важным. Это дает мне простой способ хранить сценарии, файлы, документацию и журналы изменений вместе.

Шаг 2 — отслеживание проблем

Даже будучи индивидуальным разработчиком, рекомендуется поддерживать базу данных отслеживания проблем в качестве дополнения к документации в вашей системе контроля версий. Моим личным фаворитом за последние несколько лет является Redmine, однако я также добился успеха с Mantis и The Bug Genie (теперь известный как Pachno, так YMMV). Redmine обеспечивает простую интеграцию с моими репозиториями Subversion; установить ссылку на проблему так же просто, как добавить Ошибка № 123 в мой журнал коммитов, который обеспечивает автоматическую ссылку на проблему при просмотре репозитория в Redmine. Redmine также позволяет мне отслеживать время, затрачиваемое на проблему, настраивать категории и приоритеты, а также автоматически создавать журналы изменений и записи вики. Используя Redmine и документацию моего репозитория, я могу легко сказать, когда функция была добавлена, а также связать функцию с конкретным изменением в моем исходном коде. Благодаря поддержке нескольких проектов я также могу использовать одну установку Redmine для отслеживания работы нескольких клиентов.

Шаг 3 — IDE

Не затевая священной войны по поводу того, какая IDE предпочтительнее, я думаю, можно с уверенностью сказать, что для разработки на C#/.NET Visual Studio обеспечит наилучшую отдачу от вложенных средств, особенно учитывая, что мой выбор — Visual Studio. Сообщество (бесплатно). Поскольку мое приложение для управления проектами состоит из нескольких библиотек классов C# на серверной части и веб-интерфейса .NET MVC, полной версией Visual Studio является моя основная среда разработки. Однако практически для всего остального — включая Python, PHP, сценарии оболочки и Powershell и многих других — я теперь использую Visual Studio Code. С его постоянно расширяющимся набором плагинов и тем, синхронизацией настроек через Microsoft, поддержкой Git и других систем контроля версий, а также межплатформенной совместимостью, его трудно превзойти! В качестве запасного варианта в моих системах Windows у меня всегда установлен Notepad++. От редактирования файлов конфигурации до просмотра фрагментов кода и отладки JSON из браузера, вы действительно не можете победить. Я также использую его для быстрого редактирования скриптов и HTML.

Независимо от того, какую IDE вы предпочитаете, суть в том, чтобы найти ту, которая делает то, что вам нужно, и поддерживает нужные вам функции. Изучите его сверху вниз и придерживайтесь его. За эти годы я перепробовал почти все, от Атома до Джетбрейнс, и у всех у них были какие-то функции, которые мне нравились. Однако, в конце концов, у меня просто не было причин переключаться, тем более что большая часть моего кода приходится на мир Microsoft.

Шаг 4. Разные приложения

Наконец, я хочу упомянуть некоторые из приложений, которые я использую, которые являются неотъемлемой частью моего набора инструментов. Существует много, много других инструментов, которые заслуживают такой же похвалы, как и эти, и я призываю вас, как одиночного разработчика, всегда искать приложения, которые могут повысить вашу производительность, автоматизировать повторяющиеся задачи или предоставить те потрясающие функции, которые вы не можете получить в другом месте. У большинства — если не у всех — этих приложений есть альтернативы, некоторые из которых, вероятно, лучше, но я очень верю в простоту и стабильность. Опять же, как говорится, я всегда слежу за новинками; постоянное обучение является одним из основных требований этой работы. Если вы не готовы тратить время или усилия на постоянное обучение и совершенствование своих навыков, вы выбрали не ту профессию!

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

  • OpenDBDiff — инструмент сравнения для баз данных SQL. Я часто использую это, чтобы убедиться, что мои изменения синхронизируются между моими базами данных разработки и производства. Быстро, просто и работает как заявлено.
  • Почтальон — инструмент для тестирования API. Недавно я работал над проектом по созданию API, и Postman был именно тем, что мне было нужно для тестирования как локально, в разработке, так и в производстве. Мне достаточно бесплатной версии, но платная версия предоставляет дополнительные возможности.
  • pgAdmin — единственный графический интерфейс, необходимый для работы с базами данных PostgreSQL.
  • HTTPToolkit — относительный новичок в наборе инструментов, HTTP Toolkit позволяет перехватывать трафик HTTP и HTTPS из браузера. Подобно Fiddler Classic, еще одному замечательному инструменту, который я использовал на протяжении многих лет.

Шаг 5. Философия

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

  • Независимо от того, работаете ли вы полный рабочий день или работаете по контракту или внештатно, заранее определите, что от вас ожидается в плане сроков, шкалы/ставки заработной платы и результатов работы. Следует заранее решить, кому будет принадлежать созданный вами исходный код; как правило, в ситуации фриланса документированный исходный код (включая репозитории VCS) является частью моего окончательного результата. Если это не так, подумайте о том, чтобы предложить какой-то тип условного депонирования исходного кода, чтобы будущие разработчики могли улучшать и улучшать ваш исходный код в случае, если вы недоступны.
  • Документ, документ, документ! Используйте свою систему контроля версий и средство отслеживания проблем для создания «документов для разработчиков» в дополнение к документации по использованию, которую вы предоставляете клиенту. Будущие разработчики, которым придется работать над вашим материалом, будут вам за это благодарны.
  • Создайте надежную и стабильную среду разработки. Это больше личная рекомендация. Как я уже говорил, в нашей профессии мы всегда должны учиться и искать инструменты, которые могут повысить нашу производительность или облегчить нашу жизнь. Тем не менее, я обнаружил, что выбор основного набора инструментов и изучение их внутри и снаружи значительно повысило мою производительность. Особенно ваша IDE — выясните, как вы работаете лучше всего, и придерживайтесь этого. Если вы предпочитаете VIM и терминал, то идите туда. Если вы больше любите графический интерфейс, тогда идите в этом направлении. В каком бы направлении вы ни шли, придерживайтесь его и учитесь.

Вот некоторые из советов и методов, которые я разработал за годы работы в качестве одиночного разработчика. Я уверен, что есть много других способов выполнить ту же работу, и в этом суть — выберите то, что лучше всего подходит для вас, и придерживайтесь его! Если у вас есть какие-либо вопросы по этому посту, пишите мне — [email protected].