Эта тема относится к веб-разработке/программной инженерии; однако этот вопрос может быть связан с другими областями знаний, в которых более младший сотрудник обладает более техническими навыками, чем старший с большим опытом.
Я работаю в команде, где абсолютным пределом использования объектно-ориентированного программирования является наследование . Процедурный код размещается в методах класса. В сигнатурах методов практически нет подсказок типов, нет пространств имен или интерфейсов (я знаю, верно)? - Это привело к устаревшему коду, который трудно поддерживать, а новым сотрудникам (младшим) очень трудно подобрать и работать с ним. Только тот, кто это написал, знает, как это работает.
Я ожидаю, что на техническом совещании по новому проекту любое обсуждение хороших методов объектно-ориентированного программирования (шаблоны проектирования и т. д.), скорее всего, будет встречено словами «это слишком сложно». Слишком сложный - 5 классов и более.
Я вежливый, спокойный, уважительный и честный, как и старший разработчик - он друг. В результате он искренне считает, что все, что выше наследования в программировании, «слишком сложно», а я искренне верю, что это не так, поскольку в прошлом я писал код, который «просто работал», поскольку он был полностью протестирован мной и безупречно работал на день релиза, и код старшего требовал нескольких исправлений.
Как я могу предложить хорошее объектно-ориентированное решение, которое является архитектурно обоснованным и «имеет смысл» на этой встрече, но при этом избежать проблемы «это слишком сложно» (когда на самом деле это не так, просто он привык программировать в процедурном стиле) . Я очень уважаю своего старшего, но я хочу избежать ужасного процедурного кода (в классах), который теперь есть в нашем унаследованном приложении.
Как может человек помоложе, с гораздо меньшим опытом, но значительно более целеустремленный (усвоивший эти понятия и неоднократно применявший их на практике), убедить старшего в том, что это лучший путь, с должным уважением и тактом?
Вы показываете их.
Я был во многих местах, где мне нужно было обучать людей, и с годами я обнаружил, что разговоры о вещах не помогают. Люди будут опираться на свой опыт, и в их опыте объектно-ориентированное программирование (ОО) делает вещи слишком сложными. Что вам нужно сделать, так это показать им ценность .
Возьмите проблему, которую они знают и знают, и решите ее так, как решили бы вы. Покажите им, как ваше решение обеспечивает дополнительную ценность по сравнению с тем, что они знают. Это дает им основу для обучения, а вам обоим — конкретную основу для обсуждения, а не теоретическую, которую многие сразу отбросят.
Но этого недостаточно (для большинства людей). Ваше решение по-прежнему будет выглядеть слишком сложным, потому что новые/новые концепции всегда больше работают для людей, чем то, что они знают. Следующий шаг — взять относительно простой пример и заставить их использовать его . Если бы вы были старшим разработчиком, я бы посоветовал реализовать некоторый объектно-ориентированный код и позволить другим исправлять в нем ошибки. Как младший разработчик, я не уверен. Для некоторых людей попытка уговорить их пойти в лагерь программистов или поработать над каким-нибудь хобби-проектом может быть достаточно интересным стимулом. Но вам может понадобиться просто реализовать некоторые функции в стиле OO и заставить старших работать с ними (исправления ошибок, расширения и т. д.).
По моему опыту, люди действительно верят в то, насколько простым/хорошим может быть что-то, только когда они действительно использовали это сами.
SJuan76
скрежет729
DJClayworth
Джеймс
кешлам
Джеймс