Какой процесс работы в моей компании следует улучшить в первую очередь?

Ответ 1

Я бы посмотрел на это вот так:

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

Поэтому у вас должно быть следующее (по моему мнению):

• 7 - Перезапуск сервера после компиляции
• 5 - Инкрементная скорость сборки.
• 6 - Только удаленная отладка
• 8 - Компиляция из командной строки
• 12 - Интеграция Subversion (вид в той же лиге, что и выше)
• 2 - Сгенерированные файлы
• 11 - Неправильное использование дженериков.

Тогда

• 1 - svnignore
• 9 - Зависимости проектов (это займет много времени, я уверен)
• 10 - Смешивание Maven + Ant
• 3 - Предупреждения IDE
• 4 - Соглашения

Причина, по которой у меня есть порядок в этом смысле, - время и преимущество. Если для компиляции и проверки их кода требуется 16 минут, это чертовски плохо, если честно. Скажем, разработчик составляет 5 раз в день, мы занимаем около 80 минут, ничего не делая.

После этого это производительность. Если вы ускорите скорость, с которой ваши разработчики могут выполнять свою работу, оборот выполненных работ значительно возрастет. (Profitability++)

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

Ответ 2

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

• Сделайте это медленно. Вероятно, они делали это на протяжении веков и могут сопротивляться изменениям.
• Получить команду (и, возможно, менеджера (ов)), участвующих в изменениях. Проведите собрание, чтобы обсудить, какие улучшения вы видите (пусть это просто, несколько), что они думают о них, и если они считают его разумным для реализации. Затем, если это будет согласовано, попробуйте кого-нибудь, чтобы получить улучшение на месте.
• Предложите презентации о рабочих методах, которые легко изменить. Например. покажите им в живой настройке разницу загрузки динамического класса во время сеанса отладки.
• Приоритет списка выше и сосредоточьтесь на нескольких за раз.
• Будьте осторожны. Изменить сложно! Многим сразу будет потенциально отчуждать или разъединять людей.
• Начните с быстрых побед, которые сделают немедленную и позитивную разницу с разработчиками в команде. Это создаст уверенность в принятии более сложных изменений.

Удачи...

Ответ 3

Комментарии к проблемам

1) Не использовать svnignore. Это означает, что svn stat не может использоваться, и разработчики забывают добавлять файлы и прерывать сборку.

Мне не кажется очень важным для меня - я полагаю из вышеизложенного, что у вас есть CI или ночная сборка (если нет, это будет серьезной проблемой). Цель сборки CI заключается в том, чтобы поймать такие проблемы, поэтому ИМХО это не катастрофа, если она прерывается время от времени. Конечно, если это происходит ежедневно, это другая история: - (

2) Сгенерированные файлы переходят в те же папки, что и зафиксированные файлы. Нельзя использовать простые maven clean, их нужно искать один за другим. Maven clean не удаляет все из них.

Это плохо, и его довольно просто исправить (при нормальных обстоятельствах: -)

3) Не исправление IDE анализа предупреждений. Анализ кода возвращает около 5000 предупреждений разных видов.

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

4) Не следуют соглашения: spring beans имена иногда начинаются с прописных и иногда нет, ant свойств иногда с подчеркиванием, а иногда с разделителями точек и т.д.

Не катастрофа, OTOH легко исправить.

5) Инкрементная сборка занимает 6 минут, даже если ничего не изменилось.

Это плохо, и (учитывая случаи 9 и 10 ниже) может быть довольно сложной задачей для исправления.

6) Разработчики используют только удаленный отладочный файл и не знают, как запустить сервер Tomcat из среды IDE.

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

7) Разработчики всегда перезапускают сервер после каждой компиляции, вместо того, чтобы динамически перезагружать класс и сохранять состояние сервера. Для начала проверки изменений кода требуется не менее 10 минут.

То же, что и выше.

8) Разработчики только компилируются из командной строки. Когда есть ошибки компиляции, они вручную открывают файл и идут в проблемную строку.

То же, что и выше.

9) Полный беспорядок в зависимостях проекта. Из 200 открытых источников зависит, и никто не знает, что действительно нужно и почему. Они знают, что не все зависимости необходимы.

Это плохо, и это огромная задача для исправления.

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

То же, что и выше.

11) Не использовать дженерики должным образом.

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

12) Разработчики не используют интеграцию Subversion с IDE (Eclipse, Intellij Idea).

См. случай 6.

Приоритеты

Я бы попытался упорядочить задачи на основе соотношения затрат и выгод. Мой заказ:

Во-первых, задачи, которые упрощают и ускоряют повседневную работу, и повышают ваш авторитет и авторитет в команде: 7, 6, 8, 12, 2

Затем основные, но сложные и трудоемкие задачи, для которых вам нужна дополнительная поддержка от команды: (непрерывная интеграция в случае, если ее еще нет), 5, 10, 9

Остальное можно ввести постепенно: 1, 3, 4, 11

Ответ 4

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

Только со всем этим вы должны начать работать над своей продуктивностью, показывая им, как быстро развертывать, отлаживать, использовать среду IDE и т.д....

И удачи:)

Ответ 5

В общем, я думаю, что сначала нужно позаботиться о том, что нужно тратить время для разработчиков. Чем меньше простаивает разработчик, тем больше польза.

1) Это вместе с 12) должно быть приоритетным выше, так как сломанные сборки требуют времени.

3) Предупреждения IDE не так важны, поскольку они являются просто предупреждениями и могут быть такими же простыми, как неиспользуемые импорты.

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

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

7) Похоже, что много времени тратится на всех разработчиков, это должно быть высокоприоритетным.

11) Это может вызвать много предупреждений в 3), должно быть исправлено, но не самым высоким приоритетом.

12) Интеграция с Subversion с IDE должна много помочь, я думаю, разработчики посчитали бы это очень полезным.

Ответ 6

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

Если вы начнете с мест, где, по вашему мнению, вы сможете получить максимальную производительность. Я думаю, что вы можете сэкономить значительное количество времени:

• Загрузите tomcat в IDE.
• Исправить любую конструкцию script, возможно, также проверить, проблемы, чтобы сборки выполнялись быстро.
• Компиляция в среде IDE и hotdeploy (hotswap/jrebel) также сэкономит вам много времени.

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

Ответ 7

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

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

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

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