Как я могу сделать свой рабочий процесс разработки более "корпоративным"? - PullRequest
10 голосов
/ 05 января 2009

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

  • Я выполняю большую часть своей разработки в Eclipse на своем ноутбуке. Все хранится локально на моем ноутбуке, и я не использую VCS, и при этом я не делаю резервную копию своего кода (за исключением того, что время от времени отправляю его по электронной почте, чтобы увидеть его на другом компьютере - да, я рассказал вам о своей среде разработки) нужна работа).

  • Когда я закончу с проектом и хочу развернуть его или если я просто хочу его протестировать, я использую встроенный инструмент Jar в Eclipse, чтобы создать исполняемый файл .jar моего проекта. Если я использую внешние библиотеки .jar, я использую плагин Fat-Jar, чтобы включить эти .jars в мой исполняемый файл .jar.

  • После того, как я создаю .jar, я вручную загружаю его на сервер через SFTP и проверяю что-то вроде java -jar MyProject.jar.

Ах да, я уже говорил, что я не тестирую юнит?

Самая очевидная проблема, которую я хотел бы решить в первую очередь, это отсутствие контроля над исходным кодом. Мне нравится git из-за его распределенной природы, но, похоже, он плохо интегрируется с Eclipse, и я слышал, что он не очень хорошо работает в Windows, которая является моей основной ОС для разработки. Итак, я склоняюсь к SVN, с которым у меня есть некоторый опыт. У меня есть свой личный сервер, и я думаю, что я буду использовать его для контроля над исходным кодом, потому что я предпочел бы быть моим собственным администратором, чем иметь дело с университетской бюрократией. У меня были некоторые проблемы с настройкой SVN однажды, но я сделаю это еще раз. Может быть, я также установлю что-то вроде Trac или Redmine для отслеживания ошибок, списка задач и т. Д.?

А как насчет сборки и развертывания? Должен быть лучший способ, чем использовать Fat-Jar и вручную загружать мой jar на сервер. Я слышал о таких инструментах, как Ant и Maven - применимы ли они к тому, что я хочу сделать? Как я могу начать использовать их?

Я полагаю, что в конечном итоге мне бы хотелось интегрировать модульное тестирование и с JUnit. Хотя, вероятно, так и должно быть, это не моя главная задача сейчас, потому что пока мои приложения не очень сложны. Мне бы очень хотелось поработать над упрощением и рационализацией моего рабочего процесса прямо сейчас, а затем я упросту модульное тестирование.

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


edit: Спасибо за отличные ответы. Я не хотел сказать, что хочу сделать свой рабочий процесс «корпоративным» только ради этого, но чтобы упростить свою работу и получить несколько технологий, которые обычно используются в средах разработки предприятий. Это все, что я имел в виду.

Ответы [ 13 ]

9 голосов
/ 05 января 2009

Мне кажется, у вас есть довольно хорошее представление о том, что вам нужно делать.

Использование Subversion (или другой VCS) является обязательным. Хотя, возможно, было бы разумно настроить отдельный репозиторий SVN для своего кода, связанного с работой, а не использовать персональный.

Вы можете интегрировать Subversion с Eclipse, используя такой плагин, как Subclipse, который, как я обнаружил, работает довольно хорошо.

Я бы определенно использовал Ant или Maven - я предпочитаю Ant, потому что он более гибкий, и я думаю, что он бы больше подходил вашему стилю разработки, чем Maven. Но вы также можете захотеть взглянуть на Apache Ivy , который обрабатывает управление зависимостями.

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

.

Что касается модульного тестирования - его можно постепенно наращивать с помощью модульного тестирования. Я бы порекомендовал использовать JUnit в сочетании с инструментом покрытия кода, таким как Cobertura (который легко настраивается) - он поможет вам понять, какой объем кода охватывают ваши тесты, и является индикатором эффективности ваши тесты.

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

Другими словами, все это звучит так, как будто вы находитесь на правильных линиях, вам просто нужно начать использовать некоторые из этих инструментов!

2 голосов
/ 05 января 2009

Я думаю, что вы ответили на большинство своих вопросов.

  • Управление исходным кодом: выберите SVN - простая установка, отличная интеграция с Eclipse (subclipse).
  • Использование Ant для создания и развертывания проекта (задача SCP / SFTP)
  • Сохраните все свои настройки (настройки проекта Eclipse, build xmls и т. Д.) В SVN.
  • Используйте Bugzilla, чтобы отслеживать ваши ошибки / проблемы / запросы / идеи.
2 голосов
/ 05 января 2009

Использовать контроль версий. Период. SVN имеет отличную интеграцию с Eclipse и Windows. Получите клиент TourtisSVN для Windows и используйте плагин subclipse с Eclipse.

Я бы порекомендовал получить внешний жесткий диск или использовать один из серверов вашей компании для установки репозитория и частого выполнения резервного копирования. Subversion отлично работает с развертыванием и обновлением. Просто научись это делать и ты никогда не оглянешься назад:)

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

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

Но обязательно попробуйте SVN! Если в вашей компании есть сервер LINUX с Apache, посмотрите, можете ли вы настроить свой сервер там, используя DAV-SVN.

:)

2 голосов
/ 05 января 2009

Если вы действительно настроены на управление распределенным источником, я бы рекомендовал вам взглянуть на Bazaar . Его GIT-подобный распределенный источник контроля, который разработан для выполнения слияний очень высокого качества. Из коробки он работает на всех платформах, включая Windows, и у них есть TortoiseBZR клиент.

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

Что касается модульного тестирования, вам следует ознакомиться с JUnit . Тот факт, что вы знаете о модульном тестировании и знаете, что вам следует его проводить, еще на несколько шагов опережает большинство специальных разработчиков.

1 голос
/ 05 января 2009

Посмотрите прагматический прагматический комплект Pragmatic Starter Kit .

В нем вы узнаете о важных основах разработки программного обеспечения, которые существуют в университетах и ​​т. Д. кажется, что он не работает, как контроль версий, модульное тестирование и автоматизация проектов (в таком порядке), и делает это очень доступным образом.

Это даст вам прочную основу для дальнейшего развития.

1 голос
/ 05 января 2009

Было бы ОЧЕНЬ выгодно начать работать с контролем версий. Начните сейчас, не откладывайте! Git ДЕЙСТВИТЕЛЬНО быстро движется, и TortoiseGit уже разрабатывается. SVN по-прежнему отличный стандарт для работы. И я не работал с Mercurial, но это еще одна VCS, на которую стоит обратить внимание.

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

0 голосов
/ 16 июля 2014

Все предыдущие комментарии охватывали почти все, что вам может понадобиться :-)

Я хочу добавить еще один подход к разработке (рабочий процесс разработки).

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

http://nvie.com/posts/a-successful-git-branching-model/

0 голосов
/ 05 января 2009

Если вы используете Windows Server, на котором вы хотите разместить свой SVN-сервер, используйте Visual SVN в качестве сервера. Он очень прост в настройке и использовании, поддерживает как базовую аутентификацию, так и аутентификацию Windows. Это также свободно использовать.

Eclipse имеет довольно много модулей для интеграции с SVN-сервером, поэтому используйте один из них или уже предложенный Tortoise SVN.

0 голосов
/ 05 января 2009

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

0 голосов
/ 05 января 2009

Как уже говорили другие, вы уже ясно знаете, что вам нужно делать. VCS является обязательным, CI или отслеживание ошибок может быть излишним (для одного разработчика может быть достаточно электронной таблицы для отслеживания ошибок).

Одна вещь, которая может принести вам большую пользу, - это организованное отставание продукта. В одиночной разработке я считаю, что одной из моих самых больших проблем является сосредоточение внимания на высокоприоритетных функциях и предотвращение ползучести функций. Хранение отставания очень помогает. Это не должно быть чем-то большим, чем список функций по приоритетам с некоторыми примечаниями по объему каждой из них. На моем рабочем месте мы храним эту информацию в Trac, но и здесь вам может понадобиться электронная таблица.

И я хочу вставить штекер для модульного тестирования, в частности, Test Driven Development (TDD). Книга Кента Бека - хорошее место для начала. Я считаю, что TDD помогает мне быть честным и сосредоточенным на том, что мне действительно нужно делать, особенно на проекте для одного разработчика без QA. Иногда кажется, что код пишет сам.

...