Як я можу переконати члена команди використовувати веб-фреймворк? [зачинено]


10

Питання в цьому, і деталі випливають: чи є щось, що я можу сказати / піднести, як програміст, щоб привернути його до себе?

Я хотів би почути обґрунтовані аргументи для обох сторін на цьому, але в основному пропозиції щодо того, як поговорити з ним.


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

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

Як група, ми вирішуємо, які технології використовувати для впровадження веб-сайту; конкретно, використовувати рамку PHP (Code Igniter) чи ні.

Я стверджую на користь, цитуючи:

  1. Не винаходити колесо
  2. Добре написана і перевірена база коду для роботи
  3. Початок роботи (термін ближче, ніж ми хотіли б)
  4. Швидкість розвитку
  5. Здорові та стійкі дизайнерські зразки та передовий досвід

Він заперечує за те, щоб працювати так, як звик:

  • Одноразове записування одноразово функціонує у файлі "бібліотеки" так, коли він їм потрібен
    • Функції для доступу до даних та надання цих даних на сторінку, отримання / налаштування на сеанс і з нього, а також отримання / розміщення даних тощо
  • Маючи по 1 файлу на сторінці (внаслідок чого не виникає поділу проблем між контролем, презентацією та даними)

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

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

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

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

TL; DR Недосвідчений член команди впертий, як я можу його перемогти?


2
Дуже важко знайти актуальне питання у своєму дописі в блозі :) Будь ласка, перегляньте так, що підкреслює технічні аргументи, які ви висуваєте. Хоча ми не можемо сказати вам, як спілкуватися з людиною, яку ми не знаємо, ми можемо допомогти вам підійти до ситуації з точки зору програмістів. Здається, є хороший питання щодо еволюційного складання прототипів, але я не можу бути впевнений ...
yannis

4
Частини цього, напевно, краще підходять для: area51.stackexchange.com/proposals/30887/professional-matters
Карлсон

3
he doesn't want to use code he hasn't personally written.Йому краще викинути свою операційну систему, IDE, телефон, світлофори тощо
StuperUser

4
@AndyBursh I want to know exactly how everything worksє вагомим аргументом під час навчання, коли було винайдено колесо, що насправді прийнятно. Може, просто, можливо, ви могли б прочитати це як крик про допомогу, а не як впертість.
янніс

4
since the project is only a prototype and will never be maintained Останні слова :) Я хотів би, щоб я мав долар кожен раз, коли я робив це припущення і з'ясовував, що нетерплячість і короткострокова жадібність вищих вершин вирішили, що прототип є продуктом зараз.
maple_shaft

Відповіді:


20

Ви не зможете поговорити з ним. Це називається ефектом Даннінга-Крюгера . Він занадто неосвічений, щоб знати те, чого не знає, і занадто боїться втратити те, що він вважає перевагою.

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


3
+1, оскільки це інколи трапляється в реальному світі. Я був на робочих місцях, де не міг погодитися з іншим розробником, щодо якого було найкращим підходом. Тож ми обоє відхилили POC, а потім вивчили плюси та мінуси кожного. 9 разів з 10 ми в кінцевому підсумку прийняли рішення, яке було замішуванням двох POC, і кожен дізнався щось із цього процесу.
Тімоті Болдрідж

1
+1 для навчання про Даннінг-Крюгер! Усі повинні знати про це ..
Стівен Гросс

Ба. Це занадто просто цитувати Даннінга-Крюгера, коли ти з кимось не погоджується - занадто легко назвати їх дурними. Може бути, товариш по команді вважає, що рамки порушують дух завдання, можливо, він хоче вирішити з перших рук проблеми, які вирішує рамка, можливо, він хоче уникнути дискусій CodeIgniter, Cake, Symfony ... Перше моє припущення було не те він був ідіот.
Корбін березня

1
@ Корбін, Даннінг-Крюгер не в нестачі інтелекту, це в недосвідченості. Дві дуже різні речі. Я згоден, ваші причини можуть бути справедливими, але ОП заявила, що це не аргументи, які він висуває. Натомість він "не бачить сенсу" використовувати фреймворки, оскільки він може написати щось так само добре з нуля за коротший проміжок часу. Недосвідчена людина, що завищує власну компетентність, порівняно з рішенням, про яке він, правда, майже нічого не знає, є прикладом підручника Даннінга-Крюгера. Таких людей не можна щось "обговорювати", вони повинні бути показані.
Карл Білефельдт

7

Один аргумент на вашу користь - повторне використання знань. Усі члени команди, які вивчать добре відомий та широко використовуваний фреймворк (наприклад, CodeIgniter), зможуть повторно використовувати свої знання на наступному проекті. Тоді як знання про випадкові, власні "бібліотеки" не можна використовувати повторно. Це може добре резонувати з іншими членами команди, оскільки вони, мабуть, вважають за краще отримувати якісь корисні, багаторазові знання в цьому проекті.

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

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

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


Мені подобається ідея швидкого випробування, щоб продемонструвати це. Які тести прийняття ми могли б запустити? Я, безумовно, запропоную це, але я не впевнений, що він буде добре сидіти з ним (або з групою), оскільки у всіх нас є інші терміни управління, і я сумніваюся, що хтось особливо прагне написати специфікацію або "витрачати час" (як Я впевнений, що це буде поставлено) щодо цього.
Енді Хант

1
Наука, це працює: xkcd.com/54
StuperUser

5

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

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

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

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


Я не замислювався над тим, як це відображається на інших у групі, чесно. Я обов'язково зазначу це.
Енді Хант

1

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

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

А для недосвідчених членів команди їхні шанси працевлаштуватись / краще працевлаштуватися збільшаться з такою основою, як CodeIgniter, щодо їх резюме (власне знання для обгрунтування цього резюме).

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.