Должен ли разработчик спорить с ненужными или вредными функциями?

Что такое хорошее отношение разработчиков при обсуждении новых функций, а именно некритических / сомнительных функций?

Скажем, вы разрабатываете какой-то Java-подобный язык, и босс говорит: «Нам нужны указатели, чтобы разработчики могли напрямую манипулировать объектной памятью!

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

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

Что является оптимальным распределением «могу сделать» и «не могу сделать» для обычного программиста?

РЕДАКТИРОВАТЬ: Вопрос не о плохом начальнике: D

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

Должно ли общее отношение быть:

1. да, мы сделаем это, винт сложности
2. может быть
3. нет, общая переделка и последствия не оправдывают изменения

Какой должна быть реакция хорошего разработчика?

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

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

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

Это нежная ситуация, связанная с политикой работы, но с ней можно обходиться дружно.

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

Если он или она не понимают, то вы обязаны делать глупости. Вот и все. Он босс. В таком случае вы можете просто делать то, что он / она говорит, или поговорить с его / ее боссом, или сменить работу.

Вы можете сказать начальнику, что, хотя это технически возможно, это будет стоить X времени и денег, потраченных на усилия по анализу, проектированию, переписыванию существующего кода, тестированию, регрессионному тестированию, ... А затем спросите, стоит ли эта функция , Иногда ответом будет «да! Мы должны иметь это!», Иногда это будет «нет, я думаю, нет».

Если запрашиваемая функция нарушает какой-то основной принцип приложения (например, «Добавить синюю кнопку!» К пользовательскому интерфейсу, который предназначен и имеет только красные кнопки в соответствии с запросом клиента), то я думаю, что все в порядке спросить "почему?" и упомянуть, что это идет вразрез с заранее установленным дизайном.

В конце концов, почти все «можно сделать» (с технической точки зрения не сложно добавить красную кнопку в пользовательский интерфейс только с синим цветом), это скорее вопрос «должен делать?»

Чтобы ответить на ваш отредактированный вопрос, я думаю, что ответ должен быть № 2, «Возможно», в ожидании дальнейшего изучения и анализа.

Вы не хотите отвечать № 1 «Да, безусловно», потому что вы можете застрять, совершая что-то, что вы не способны доставить в данный период времени.

Вы не хотите отвечать на вопрос № 3 «Нет, это слишком много работы», потому что тогда кажется, что вы отказываетесь от сотрудничества и излишне трудны.

С точки зрения разработчика: НИКОГДА не говорите никому, оплачивающему счета, что они не могут получить то, что хотят. Вместо этого вы можете сказать им, что у них не может быть этого за ту цену, или что у них не может быть этого в точности так, как они изначально задумывали.

К вашему примеру с указателем; .NET, среда управляемого кода, имеет указатели. Они критически необходимы для большой функциональной совместимости с неуправляемым кодом. Однако их «безопасное» использование строго регламентировано, и если оно используется в «небезопасном» коде, этот код требует более высоких разрешений безопасности во время выполнения. Если вы разрабатывали управляемый язык, который также требовал прямого доступа к памяти через указатели, вы могли бы придумать аналогичную схему сортировки за кулисами, где вы могли бы, используя управляемые указатели только для чтения, где вы не могли автоматически маршалировать, и позволяя " Истинные "указатели только в самых надежных областях кодовой базы.

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

Во всех случаях эта новая функция может увеличить объем работы, требуемый клиентом. Это, в свою очередь, потребует либо продления графика, большего количества денег и / или сокращения других запланированных работ.

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

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

Другие авторы утверждают, что вы должны попытаться количественно оценить стоимость проблемы, которая будет вызвана проблемной функцией, и это хорошая идея, когда это возможно, но обычно это не так. Обычно можно оценить только непосредственные затраты на внедрение. Даже это часто трудно для больших функций. Что касается будущих расходов, вы находитесь в трудном положении. Вы не знаете наверняка, какие другие функции потребуются, или как долго продукт будет находиться в процессе обслуживания. Стоимость, как правило, будет намного выше, чем вы могли бы подкрепить оценкой, основанной на достоверных фактах.

Чем больше компетентности вы продемонстрировали в прошлом, тем больше у вас было свободы действий, чтобы просто объявить функцию плохой идеей. Это может прийти только со временем и подтвержденным успехом. Тем не менее, вы всегда должны выражать готовность выполнить запрос, так как это то, что хочет ваш клиент. Вы должны высказать оговорки, основываясь на своем опыте, и, как только вы это сделаете, это станет не проблема в 90% случаев, потому что вы начнете разговор, который доходит до корня проблемы, а именно: Почему они попросили вас добавить эта функция в первую очередь? На этом этапе вы можете предложить альтернативы или, возможно, согласиться с тем, что хотя запрошенная функция будет создавать проблемы, она все же необходима.

Конечно, также возможно, что вы просто неправы. Разве разработка программного обеспечения не забавна?

Поскольку вопрос довольно расплывчатый, я немного обобщу свой ответ.

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

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

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

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

Я хочу сказать, что, когда возникает новое бизнес-требование, оно будет работать для деловых людей, потому что оно не повышает сложность гораздо выше, но может оказывать большее влияние на всю систему. На мой взгляд, это не повод, чтобы возразить против этого изменения. Это правильный момент, чтобы обсудить усилия (и расходы) с клиентом. Вероятно, это не остановит пользователей от создания этой функциональной возможности, но со временем у них появится чувство к приложениям и некоторые дискуссии на тему: «Ух, ты такой дорогой!» будет гораздо менее требователен

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

Извините, но этот вопрос звучит как несовершеннолетний, просящий отцовского совета. Если это так, хороший разработчик должен принять эти заповеди:

• Оставайся верным себе. Если вам не нравится какая-либо функция, озвучьте свои проблемы. Хорошие шансы, что команда просто ждет открытия.
• Не пытайтесь заменить опыт опытными правилами. Для вас каждая ситуация отличается, каждая функция является новой. Это плюс, что ваши старшие не имеют.
• Разработка программного обеспечения не является точной наукой, она никогда не будет. Поэтому накапливай мудрость, а не поведение.
• Прими поражение. Если команда соглашается иначе, не повторяйте ваши проблемы до тошноты.
• Мыслить позитивно. Если идея на самом деле требует «сбить ее с толку», попробуйте найти и назвать ее положительные стороны, прежде чем перечислять ее недостатки.
• Узнайте, как общаться с людьми. Мы, разработчики, часто ставим технические знания выше социальной компетенции. Технические способности достигают максимума в раннем возрасте, но социальная компетентность может расти до выхода на пенсию.

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

Например, у меня были люди, которые хотят, чтобы требования были взаимоисключающими к тому, что приложение уже делает. Если я сделаю это, то это, на 100% гарантированный, сломается. Поэтому я отправляю требование обратно и говорю им, что это нарушит другое бизнес-правило, которое у нас уже есть, и они тоже хотят изменить это правило? Часто небольшая группа, которая предъявляет особые требования, не имеет доступа к более полной картине того, что может делать остальная часть приложения. В большинстве случаев, когда я отправлял одно из них назад, заказчик осознавал, что начальное правило было более критичным, и решал, что изменение, которое он хотел, не стоило того. Когда они решили внести изменения, они сделали это после консультации с людьми, которые выдвинули первоначальное требование.

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

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

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

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

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

В этом случае я бы порекомендовал какую-то стратегию снижения риска. Изображение, которое вы рассматриваете для добавления WCF / веб-сервисов к вашему API, что может быть круто или очень сложно без вознаграждения:

• добавить функцию на ветке. Если это работает, объедините это. Если оно превращается в гнездо крыс, убейте его.
• запустите новый одностраничный проект и сделайте проверку концепции. Если вы не можете сделать доказательство концепции в течение короткого времени, тогда отбросьте его. Если доказательство концепции работает, увеличьте его и интегрируйте с
• поищите в Интернете людей, которые разбираются в этой функции или технологии. Там, где происходит много проблем, технология может быть сопряжена с реальными рисками чрезмерной сложности. Java Beans и COM +, вероятно, являются старыми, но хорошими примерами функций, которые действительно увеличивают сложность и могут или не могли предоставить преимущества в уравнении

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

Это очень сильно зависит от запроса. Реализация указателя достаточно велика, чтобы повлиять на весь проект, поэтому его достоинства должны быть взвешены, если есть возможность выбора.

Реализация кнопки, которая нарушает поток. Может быть, это не такая уж большая проблема, если форма может быть размещена таким образом, что кнопка является необязательной. Я сделал это на самом деле. Я добавил кнопку, но перед этим собрал достаточно информации, чтобы кнопка стала необязательной. Пользователи, которые ожидали, что это будет там, использовали это, и те, кто понял, что это было просто излишним, не сделали.

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

Проблема, которую я вижу, заключается в том, что вы используете слово «спорить».

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

Если у вас есть четко сформулированные требования (язык должен быть безопасным, нам нужны указатели для доступа к устаревшим процедурам), вы можете представить, как эти два требования противоречат друг другу, и спросить, что является более важным. Если у вас есть требования и причины их возникновения, вы можете даже предложить совершенно другое решение, которое поддерживает оба требования (JNI - своего рода).

Если это не так, возможно, сейчас самое время их кодифицировать!

1. Поймите, что вы не знаете всего и не можете делать все.

2. Если вы уверены, что это плохая идея, скажите, что плохая.

3. Если они попытаются навязать это вам, скажите либо: - Нужно больше времени для анализа, если вам нужно больше времени или скажите, что мы не нашли хорошего решения этой проблемы.

4. Если они по-прежнему настаивают на реализации плохой идеи, получите от них подтверждение того, что вы посоветовали против нее, включая ваши причины. Вы можете даже отправить электронное письмо с кратким изложением обсуждения с копией своему менеджеру. Это может спасти ваш ** позже.

В идеальном случае у вас был бы ведущий разработчик, который принимает окончательные решения по технической части, и бизнес-лидер, который принимает окончательные решения по деловой части. Это ответило бы на два основных вопроса:

1) что? Что хочет клиент?

2) Как? Как мы можем достичь этого с технологической точки зрения.

То, что хочет клиент, является окончательным принимающим решение, поскольку они - те, кто оплачивает счета

Как разработчик, вы не должны заботиться о том, какие требования должны быть выполнены.

Тем не менее, вы должны объяснить, если что-то нереально и есть ли лучшие способы.

Иногда это действительно запрос клиента (исходя из внутренней политики клиента). Тогда это безнадежно и должно быть сделано (но руководство должно также рассмотреть вопрос о том, продолжать ли такой проект или стоит ли пересматривать цену).

Это почти повседневная задача для меня, и на самом деле я рад, что это так.

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

Конечно, тяжело, когда все хотят использовать функцию X, и вы в конечном итоге говорите: «Это может быть нехорошо», но, в конце концов, все пытаются создать безопасное, надежное и стабильное приложение (поддерживаемое, гибкое и т. Д.). ) и каждый голос должен рассчитывать.

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

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

Однако, если полномочия решат, что новая функция будет добавлена, тогда вы должны сделать лучшую возможную работу. Это вызов.

И если новая функция слишком глупая или рабочая среда слишком дрянная, то пришло время найти другую работу.