Работа с фундаментальным недостатком дизайна, когда вы новичок в проекте [закрыто]

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

Даже если вы уверены, что это «фундаментальный недостаток дизайна», помните, что вы посторонний. Это может быть там по уважительной причине. Или, в зависимости от того, сколько лет проекту, он мог быть помещен туда по какой-то веской причине в то время, а сейчас он все еще существует по историческим причинам.

Вместо того, чтобы «взрывать это в списке рассылки», попробуйте задать вопрос. Что-то вроде:

«Эй, я только что натолкнулся на X, и это не имеет никакого смысла для меня. Кажется, что правильным способом реализовать это было бы Y, но опять же я знаю, что я новичок здесь, и я не хочу поспешите к каким-либо выводам. Это ошибка в дизайне, или я что-то упускаю? Может, кто-то напишет меня? Спасибо. "

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

Один из 48 законов власти :

Выиграй через свои действия, а не через аргумент

Любой кратковременный триумф, который вы считаете достигнутым в результате спора, на самом деле является пирровой победой: обида и недоброжелательность, которую вы разбудите, сильнее и длится дольше, чем любая мгновенная смена мнения. Гораздо сильнее заставить других согласиться с вами через ваши действия, не говоря ни слова. Продемонстрируй, не объясни.

Это тот, который я выучил нелегко после многих бессмысленных споров.

В этом конкретном случае я бы посоветовал придумать очень простой и конкретный кусок кода, который должен работать, но не будет работать из-за этой ошибки проектирования. Как гласит старая поговорка: «Вы не можете спорить с компилятором / интерпретатором».

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

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

Тебе, вероятно, это не понравится ... но, здесь идет ...

Я работаю над исправлением некоторых ошибок, чтобы попасть в «цикл» и стать постоянным участником проекта. Проблема в том, что я обнаружил фундаментальный недостаток дизайна, который вызывает одну из ошибок, над которой я работаю.

Нет, нет, ты не сделал. Если бы ты это сделал, ты бы не стал так сомневаться. Тот факт, что вы сами не уверены в «фундаментальном недостатке дизайна», означает, что вы его не обнаружили. Когда вы пытаетесь указать на чужую ошибку, вам не выгодно использовать превосходную степень (например, «фундаментальную»).

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

Но я чувствую, что если я расскажу об этом в списке рассылки, я откажусь от высокомерия

Назвать это «фундаментальным недостатком дизайна» определенно покажется высокомерным. В этом отношении даже указание, что это может быть ошибкой, не лучшая идея. Если вы точно не знаете (и можете подтвердить это), что это проблема, тогда вам нужно смиренно задавать вопросы и исследовать, пока вы не поймете это полностью . Лучше, чем тот, кого вы пытаетесь убедить.

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

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

Затем, не указывая пальцем и не называя ничего сломанным, смиренно выдвигайте предложение улучшить дизайн для группы. И вам лучше продумать все последствия и пути их решения, иначе вас застрелят за «наивность». Будьте готовы к спору о том, почему ваш дизайн лучше. Будьте готовы проиграть и проиграть изящно.

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

...

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

«Привет, спасибо, что приняли меня в свой дом. Когда я иду через дверь, я хочу, чтобы все в семье знали, что их ребенок уродлив, а кто-то забавно одел его».

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

Ненужное и контрпродуктивное. Я предлагаю:

«Что касается вопроса #blah, я думаю, что могу исправить это, выполнив XY и Z, но я не уверен, как это повлияет на остальную часть проекта. Это будет нормально?»

Где XY и Z исправить проблему. Пусть они скажут вам, что это был недостаток дизайна; может быть альтернативное решение. Или предположения, лежащие в основе «изъяна», могут быть настолько глубокими на протяжении всего проекта, что его изменение исправит ошибку, но сломает все остальное!