Усунення з принциповою вадою дизайну, коли ви новачок у проекті [закрито]

Я щойно почав працювати над проектом з відкритим кодом, в якому працює близько 30 розробників. Я працюю над виправленням деяких помилок як способу потрапити в "цикл" і стати постійним довірителем проекту. Проблема полягає в тому, що я думаю, що я виявив фундаментальну ваду дизайну, яка викликає одну з помилок, над якими я працюю. Але я відчуваю, що якби пробув це в списку розсилки, я зійду як зарозумілий, і деякі дискусії, які я проводив з цього приводу, - забиваючи голови з деякими людьми. Як мені це робити?

Навіть якщо ви майже впевнені, що це "основна вада дизайну", пам’ятайте, що ви стороннє підприємство. Це може бути з поважної причини. Або, залежно від того, скільки років проекту, його можна було помістити туди, що було вагомою причиною в той час, а зараз воно все ще існує з історичних причин.

Замість того, щоб "пробувати це в списку розсилки", спробуйте задати питання. Щось на зразок:

"Гей, я щойно наткнувся на X, і це не має для мене ніякого сенсу. Здається, що правильним способом втілити це було б Y, але потім я знову знаю, що я тут новий, і я не хочу перейдіть до будь-яких висновків. Це помилка в дизайні, чи щось мені не вистачає? Може хтось заповнить мене? Дякую ".

Інжиніринг - одне з небагатьох місць у світі, де смирення досі вважається справжньою чеснотою, а задавати питання про "очевидні проблеми" таким чином - це дійсно хороший спосіб отримати хороші відповіді та дізнатися нові речі.

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

Перемагайте через свої дії, ніколи через аргумент

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

Це я навчився важким шляхом після багатьох безглуздих аргументів.

У цьому конкретному випадку я б радив придумати дуже простий і конкретний фрагмент коду, який повинен працювати, але не буде через цей недолік дизайну. Як свідчить стара приказка, "Ви не можете сперечатися з компілятором / інтерпретатором".

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

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

Вам, мабуть, це не сподобається ... але ось ось ...

Я працюю над виправленням деяких помилок як способу потрапити в "цикл" і стати постійним довірителем проекту. Проблема полягає в тому, що я думаю, що я виявив фундаментальну ваду дизайну, яка викликає одну з помилок, над якими я працюю.

Ні, ні, ви цього не зробили. Якби ви це зробили, ви б не ставилися до цього. Той факт, що ви самі не впевнені в "фундаментальній ваді дизайну", означає, що ви її не виявили. Намагаючись вказати на чужу помилку, вона не купує вам жодних друзів для використання суперлативів (наприклад, "фундаментальних").

Можливо, ви виявили, що це дещо кращий дизайн, що стосується проблеми. Ви, мабуть, повинні випробувати це ретельно, оскільки - ви новачок у проекті, є кращий, ніж навіть шанс, що ви не маєте поняття, про що говорите.

Але я відчуваю, що якби я обдула це у списку розсилки, я зійду як зарозуміла

Називаючи це «принциповою вадою дизайну», безумовно, натраплятимеш як нахабний. З цього приводу навіть вказуючи на те, що це може бути помилка, не найкраща ідея. Якщо ви фактично не знаєте (і можете зробити це резервним), що це проблема, то вам потрібно смиренно задавати питання та дослідження, поки ви не зрозумієте це повністю . Краще, ніж кого б ти не намагався переконати.

... і деякі дискусії, які я проводив з цього приводу, - це забиття голови з деякими людьми. Як мені це робити?

Стій. Це не моральне питання, і це нікого не вбиває (я припускаю). Якщо ви маєте намір бути довгостроковим членом проекту, спочатку ви повинні заслужити довіру, перш ніж допитати їх. Виправте помилки, виконайте дивовижну роботу (за будь-якими показниками групових значень), спроектуйте кілька функцій та заробіть місце за столом.

Потім, не вказуючи пальцями і не називаючи нічого зламаного, покірно підкажіть пропозицію щодо вдосконалення дизайну для групи. А вам краще продумати всі наслідки та рішення для них, або ви будете збиті за те, що ви "наївні". Будьте готові до аргументу про те, чому ваш дизайн краще. Будьте готові до програшу і програйте граціозно.

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

...

Якщо ви здатні, альтернативою є просто зашифрувати прокляту річ настільки криваво, що вони здригнуться від здивування від вашої майстерності кодування та не матимуть іншого вибору, окрім як прийняти елегантну простоту та вічну правду вашого дизайну. Розробники роблять повагу компетенції, але ви повинні бути обережні , - покарання за некомпетентності (або необгрунтоване зарозумілість) досить важка. Оскільки ви задаєте це питання, однак, я здогадуюсь, блискучий і непривабливий шлях зарозумілості насправді не є варіантом. ;)

"Вітаю, дякую за те, що ви прийняли мене до вашого будинку. Коли я проходжу через двері, я хочу дозволити всім у родині знати, що їхня дитина некрасива і хтось смішно одягав його".

Помилка - це помилка, і це нормально так називати. Скажіть, що це спричинено "недоліком дизайну" - це вказівкою пальцем на хлопця перед вами (найбільше подобається "татові") і каже йому, що він ідіот.

Непотрібне і контрпродуктивне. Я пропоную:

"Що стосується випуску #blah, я думаю, що я можу це виправити, виконуючи XY та Z, але я не впевнений, як це вплине на решту проекту. Чи це буде нормально?"

Де XY і Z виправляють проблему. Нехай вони скажуть вам, що це був недолік дизайну; може бути альтернативне рішення. Або припущення про "недолік" можуть проникнути так глибоко протягом всього проекту, що його зміна виправить помилку, але зламає все інше!