Что касается менеджмента, то мы с ними общаемся, и они не понимают моих претензий. Они видят ситуацию так, что есть разные способы реализации одного и того же, и человек уже что-то сделал - оно работает, значит переделывать нет смысла.
Именно так. Если оно работает, тесты проходят - значит так автор видит и это нормально.
Если хочешь доказать иначе - должны быть другие требования к выполняемой задаче. Либо какие-то тесты на перформанс/качество/требование использовать конкретную библиотеку или не использовать.
Мне неудобно читать их код. У них часто нарушается инкапсуляция, не соблюдается SOLID, именование не соответствует конвенциям и договоренностям, бывает дубляж, просто странные решения; в общем, мне категорически не нравится, как они пишут.
За именование не по конвенциям - бить по рукам. Это однозначно. Конвенции описать в документе и просто режектить скидывая ссылку на документ с конвенциями. Без подробного разжевывания. Через небольшое время все выучат конвенции. Убедить менеджмент что нужно поддержать идею о конвенции легко, ибо не только общеизвестные практики, но еще и очень легко объяснимые с точки зрения удешевления последующей поддержки этого кода.
Ну и если конвенции соблюдены, то читать код должно быть удобно.
В конвенциях - правила именования функций, переменных, файлов, переноса строк, оформление комментариев и коммитов (например хорошее именование коммитов в мастере - возможность автоматизации отчетов, релиз ноутс, а также интеграция CI с код ревью по заголовкам коммитов). Также необходимо контролировать использование библиотек. Если кому-то для реализации задачи нужно подключить еще одну библиотеку, это надо согласовать - какую, где, краткий инвестигейшн кто эту библиотеку делает. Вдруг она уже устарела, никто ее не саппортит и через год-два придется ее менять на что-то новое. В идеале иметь внутренний репозиторий куда подтягивать то, чем пользуетесь в проекте и регулярно но контролируемо его обновлять.
Нарушение инкапсуляции, солид, и все такое - это грамотность и понимание зачем оно нужно уже на более высоком уровне. Но вряд ли твоя задача учить всех как писать код.
Тут уже сам решай, есть у тебя время и желание пояснять и возможно нарываться на конфликты, либо принимать как есть и забить на качество кода.
Можно попробовать решение, чтобы одну фичу реализовывало два человека, или один реализовал, второй тут же провел рефакторинг. Времени займет естественно раза в два больше, но пересмотрят реализацию друг и друга и со временем прийдут к чему-то среднему.
Если не лень, можешь писать комменты опциональные к исполнению. И собирать статистику кто переделал согласно комментариям, кто нет. Потом, когда возникнут проблемы из-за кривой реализации, добавить это в статистику и через полгода посмотреть насколько твои комментарии потенциально могли бы принести пользу.
Например в процессе эксплуатации выявлялись проблемы, которые были исправлены. Но по статистике 90% этих проблемы ты комментировал еще в момент реализации, и если бы изначально тебя послушались, то проблем бы не возникло, и не надо было бы переписывать - это прямая экономия времени и денег.
Или наоборот, 5% комментариев были бы полезны, остальные - практически никак не повлияли на работу в пролакшене. Сам сделаешь тогда выводы.
Простой
Сложный
