Чи повинен розробник сперечатися проти зайвих чи шкідливих особливостей?

Яке хороше ставлення до розробників під час обговорення нових функцій, а саме, некритичних / сумнівних функцій?

Скажіть, ви розробляєте якусь мову на зразок Java, а бос каже: "Нам потрібні вказівники, щоб розробники могли безпосередньо поспілкуватися з об'єктною пам'яттю!"

Чи повинен розробник збивати цю ідею, оскільки вона додає немислимої складності та вразливості безпеки, чи він повинен робити те, що задається?

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

Який оптимальний розподіл "може робити" проти "не вмію" для звичайного програміста?

EDIT: Питання не про поганого начальника: D

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

Якщо загальне ставлення має бути:

1. так, ми це зробимо, відкрутити складність
2. можливо
3. ні, загальна переробка та наслідки не виправдовують зміни

Якою має бути реакція хорошого розробника?

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

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

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

Це тендерна ситуація, пов’язана з робочою політикою, але з нею можна по-доброму впоратися.

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

Якщо він чи вона не отримує балу, то ви зобов'язані робити дурні речі. Це воно. Він начальник. У такому випадку ви можете просто робити те, що він / вона каже, або поговорити зі своїм начальником або змінити роботу.

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

Якщо функція, яку ви запитуєте, порушує якийсь основний принцип програми (наприклад, "Додати синю кнопку!" В інтерфейс користувача, який специфічний і призначений мати лише червоні кнопки відповідно до запиту клієнта), тоді я думаю, що це нормально запитати "Чому?" і зазначимо, що це суперечить заздалегідь встановленому дизайну.

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

Щоб відповісти на ваше відредаговане запитання, я думаю, що відповідь має бути №2 "Можливо", до очікування подальшого дослідження та аналізу.

Ви не хочете відповідати №1 "Так, беззастережно", тому що ви можете застрягти, виконуючи щось, чого ви не здатні доставити у визначені часові рамки.

Ви не хочете відповідати на №3 "Ні, це занадто багато роботи", оскільки тоді це виглядає так, що ви не співпрацюєте і не потребуєте труднощів.

З точки зору розробника: НІКОЛИ не кажіть нікому, хто платить рахунки, що вони не можуть мати те, що хочуть. Натомість, ви можете сказати їм, що вони не можуть мати її за цю ціну або що вони не можуть мати її саме так, як спочатку її задумали.

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

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

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

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

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

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

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

Звичайно, можливо також, що ти просто помилився. Хіба не розробка програмного забезпечення?

Оскільки питання досить розпливчасте, я збираюся трохи узагальнити свою відповідь.

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

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

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

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

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

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

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

• Залишайтеся вірними собі. Якщо у вашій кишці виникає занепокоєння з приводу функції, висловіть свої побоювання чутно. Хороші шанси, що команда просто чекає відкриття.
• Не намагайтеся замінити досвід правилами великого досвіду досвідченого. Для вас кожна ситуація різна, кожна особливість нова. Це плюс ваших старших людей.
• Розробка програмного забезпечення не є точною наукою, вона ніколи не буде. Тому накопичуйте мудрість, а не поведінку.
• Прийміть поразку. Якщо команда погоджується на інше, не повторюйте свої занепокоєння.
• Думай позитивно. Якщо ідея насправді просить "збити її", спробуйте знайти та назвати позитивні моменти до неї, перш ніж перерахувати її недоліки.
• Дізнайтеся, як взаємодіяти з людьми. Ми, розробники, часто ставимо технічні знання над соціальною компетентністю. Технічні здібності досягають піку на початку життя, але соціальна компетентність може продовжувати зростати до виходу на пенсію.

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

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

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

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

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

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

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

У такому випадку я рекомендую якусь стратегію зменшення ризику. Зображення, яке ви розглядаєте, як додавати WCF / веб-сервіси до свого API, що може бути приголомшливим чи великим рівнем складності без винагороди:

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

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

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

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

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

Я бачу проблему у використанні слова аргументувати.

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

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

Якщо це не так, можливо, настав час їх кодифікувати!

1. Зрозумійте, що ви не все знаєте і не можете все зробити.

2. Якщо ви впевнені, що це погана ідея, то скажіть, що погано.

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

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

В ідеальному сценарії у вас є провідний розробник, який приймає остаточні рішення з технічної сторони, і бізнес-лідер, який приймає остаточні рішення з боку бізнесу. Це дало б відповідь на два основні питання:

1) Що? Що хоче клієнт?

2) Як? Як ми це досягаємо з технологічної точки зору.

Замовник бажає остаточного прийняття рішень, оскільки саме вони платять рахунки

Як розробник, вам не варто байдуже, які вимоги потрібно запровадити.

Однак вам слід пояснити, чи щось нереально і чи є кращі способи.

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

Це майже щоденне завдання для мене, і насправді я радий, що це так.

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

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

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

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

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

І якщо нова функція занадто дурна або робоче середовище занадто шалене, то саме час знайти іншу роботу.