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

Я разработчик программного обеспечения для крупной фирмы около 5 лет, так как я был начальным уровнем. Недавно у меня появилась возможность поработать над крупным проектом.

Моя большая команда из 27 человек разделена на 3. Другие члены моей команды имеют более 10 лет опыта.

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

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

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

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

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

Все кодировали так сорок лет назад. Десять лет назад так кодировали только ленивые некомпетентные люди.
Такой открытый вопрос не очень хорошо подходит для этого сайта (и, вероятно, будет закрыт из-за отсутствия ответа), я думаю, вам больше повезет в общей дискуссионной группе, такой как одна из команд Slack, перечисленных здесь techbeacon .com/46-slack-groups-разработчики
@Kilisi нет, хорошие разработчики уже существовали в девяностых. Даже если бы GoF не существовало, вы все равно могли бы взять дерьмо с программным обеспечением для бумаги / диаграмм и подумать о том, как вы будете что-то делать, прежде чем переходить к коду. То, что сказал Куинси Адамс, можно было бы резюмировать как «отсутствие / отсутствие разработки программного обеспечения» и отсутствие тестирования. Хорошие команды тестирования уже существовали в XX веке (однако хорошая команда тестирования всегда должна быть отделена от разработчиков, и точка).
Если бы вас спросили, смогли бы вы с уверенностью доказать, что ваши методы более продуктивны, чем их? Возможно ли, что один старший член команды навязал свои методологии остальным?
Спрашивайте, обсуждайте, предлагайте и мотивируйте улучшения или игнорируйте, не критикуйте.
@Kilisi Помните, что все, что сделал GoF, это дал имена существующим шаблонам, а не изобрел их.

Ответы (2)

Здесь нет стандартов кодирования и реального процесса/цикла разработки — кажется, что ваши товарищи по команде просто переводят требования в код.

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

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

Конечно, все это зависит от мышления руководителя команды и компании в целом (их могут вполне устраивать просроченные/неэффективные проекты).

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

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

Обычно это сводится в первую очередь к отсутствию автоматического тестирования в самой «раздражающей» части вашего приложения, под «раздражающей» я подразумеваю: (либо, либо оба)

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

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

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

Запомните два следующих принципа: «Будьте проще и глупее» и «Вам это не понадобится».

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

Как я могу исправить плохие стандарты кодирования моих более опытных товарищей по команде? [закрыто]
СпросиСетьПолитика конфиденциальности1y, 0v