Как бороться с еще не реализованным методом, который будет сделан со-программистом?

Это вопрос о том, как работать в команде.

Недавно я работал над моим первым большим (~ 80 классами, Java) проектом программирования с командой из 6 человек, хотя только 4 из нас постоянно работали над кодом. Мы распределили работу, которая должна была быть сделана рано, и в какой-то момент мне нужно было вызвать метод, который еще не был реализован одним из моих со-программистов. Как рекомендуемый способ справиться с этим?

Варианты, которые я видел, хотя мне не очень нравятся какие-либо из них:

Пишу себе a //TODOи пересматриваю эту строку кода позже, чтобы проверить, был ли метод реализован за это время.
Попросить соответствующего члена команды осуществить это сейчас .
Создание пользовательского исключения runtimeException с четким описанием того, что еще не реализовано. (По крайней мере, нам не нужно долго искать, чтобы выяснить, чего не хватает)
Добавление необходимого метода в их класс и запись их //TODOв теле сообщения, возможно, также отправит им быстрое сообщение об этом изменении. (Теперь это не моя проблема, но это может вызвать раздражающие конфликты слияния, если они в то же время работали над этим методом)
Определение абстрактных классов или интерфейсов для всего перед тем, как писать код, выполняющий эту работу. (Не слишком хорошо работал, потому что эти интерфейсы часто менялись)

teamwork

— lucidbrot
источник

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

— Euphoric

@Euphoric Несколько раз я сталкивался с ситуацией, когда за относительно короткий период времени должна была быть разработана довольно большая новая функция, и как таковой пользовательский интерфейс, бизнес-логика и уровни API должны были быть разделены на различные задачи для одновременной работы, в противном случае срок не может быть соблюден. Именно там, где человек, работающий с пользовательским интерфейсом, должен только объявлять методы и команды доступа к данным BL в качестве интерфейсов и разрешать другим людям работать над реализацией, работая исключительно над пользовательским интерфейсом.

— Энди

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

— Euphoric

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

— Энди

как насчет того, чтобы поговорить с ним, как он хочет справиться с этим?

— Aganju

Ответы:

Это интересный вопрос, и ответ может быть проще, чем вы думаете.

Проще говоря, напишите тесты, которые подтвердят ваши предположения. Неважно, если вы делаете реализацию или ваши коллеги-программисты

Длинный ответ.

Любой из перечисленных вами вариантов несколько пассивен и требует , чтобы вы вернулись и пересмотрели код (если он существует) рано или поздно.

Комментарии должны быть прочитаны и обработаны вашим партнером, ответственным за реализацию. Ваш код не может быть скомпилирован в то же время. Если вы проверите такое состояние в репозитории кода, ваш конвейер непрерывной интеграции не будет работать, и в любом случае это плохая практика ... никогда не проверяйте взломанный код
Исключения во время выполнения выглядят лучше, но они все еще токсичны, потому что ваш коллега-программист может предположить, что реализация уже выполнена без проверки, что также приводит к нестабильной работе системы. Если метод вызывается не так часто, это может привести к поломке производственного кода ... также к плохой практике ... никогда не проверять "не реализованные" исключения
Ожидание ваших коллег-программистов для реализации методов или заглушки также пугает. Это нарушает ваш рабочий процесс и рабочий процесс ваших коллег-программистов. Что произойдет, если они болеют, на встрече, во время перерыва на кофе, вы хотите провести время в ожидании? ... не ждите кого-то, если вам не нужно
Реализация недостающих методов определенно лучший путь для продвижения вперед. Но что произойдет, если ваша реализация не удовлетворяет весь вариант использования, и ваши коллеги-программисты должны изменить или изменить его? Как вы и они убедитесь, что он по-прежнему совместим с вашим намерением? Ответ снова прост. Напишите тесты, которые подтверждают, описывают и документируют ваши намерения. Если тесты прерываются, это легко заметить. Если необходимо внести изменения в этот метод, которые нарушают вашу функцию ... вы видите это немедленно. У вас обоих есть причина общаться и решать, что делать. Разделить функционал? Измените свою реализацию и т.д ... никогда не проверяйте код, который недостаточно документирован тестами

Чтобы достичь достаточного уровня тестирования, я бы посоветовал вам взглянуть на две дисциплины.

TDD - разработка, основанная на тестировании - это поможет вам описать свое намерение и в достаточной степени протестировать его. Это также дает вам возможность имитировать или подделывать методы и классы (также используя интерфейсы), которые еще не реализованы. Код и тесты будут по-прежнему компилироваться и позволять вам тестировать свой собственный код в изоляции от кода ваших коллег-программистов. (см .: https://en.wikipedia.org/wiki/Test-driven_development )
ATDD - разработка, основанная на приемочных тестах - это создаст внешний цикл (вокруг цикла TDD), который поможет вам протестировать функцию в целом. Эти тесты станут зелеными только тогда, когда будет реализована вся функция, что даст вам автоматический индикатор, когда ваши коллеги завершат свою работу. Довольно аккуратно, если вы спросите меня.

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

Это позволит вам поместить свой код в конвейер непрерывной интеграции и создать высоконадежную реализацию.

Если вы хотите получить дальнейшее в этой теме, проверьте следующие ссылки:

— Йеско Р.
источник

103

Спросите окурки.

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

— svidgen
источник

^^ Это. Если вы правильно используете интерфейсы, вам не нужны реализации, пока другой парень не закончит их написание.

— Роберт Харви

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

— corsiKa

Обидно, что у Java нет заголовочных файлов. В мире C / C ++ вы можете разрабатывать свои API и сначала записывать все свои заголовки, а затем отсутствие компоновки становится проблемой для компоновщика. (Небольшое упрощение, ABI также должен оставаться постоянным, чтобы он был просто вопросом компоновщика).

— Уэс

@WesToleman Забавно, но одна из моих любимых вещей в Java - отсутствие заголовочных файлов. Упоминаемые Робертом и CorsiKa «интерфейсы» прекрасно справляются с этой ролью. Сначала вы разрабатываете свои API, пишете интерфейсы, и отсутствие конкретной реализации не является проблемой для компилятора.

— GrandOpener

@WesToleman Это хорошо для вас? В моих ушах это звучит чертовски похоже на стиль водопада, и я предполагаю, что вам придется обновлять интерфейс дальше, когда вы понимаете, что пропустили этот «важный параметр»?

— netigger

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

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

— Пит
источник

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

— Торбьерн Равн Андерсен