Как объяснить, почему выбор дизайна хорош? [закрыто]

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

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

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

Это может не дать прямого ответа на ваш вопрос, но может привести вас в интересном направлении.

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

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

Продажи не происходят автоматически - вы должны приложить согласованные усилия, чтобы понять точку зрения другого человека , а затем выяснить, как отобразить ваши идеи в их Happy Place ™. Как только они узнают, как лично они получат выгоду от этой новой вещи, они часто спрашивают: «Сколько это будет стоить и как скоро мы сможем это сделать?» Как только вы услышите эти волшебные слова, вы поймете, что хорошо справились с работой по продажам.

У меня нет действительно решения вашего вопроса, но некоторое время назад я столкнулся с точно такой же дилеммой и хотел ответить точно на этот же вопрос.

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

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

Ну, я так и не нашел ответа, но несколько дней назад, когда я просматривал Lean Software Development: Agile ToolkitЯ наткнулся на что-то интересное, что может означать, что ответа на самом деле не существует. В разделе книги говорилось о лидерах в других областях, особенно в подразделениях реагирования на чрезвычайные ситуации, и о том, как эти лидеры принимали решения. Когда в вас стреляют или кто-то стреляет в вас, эти лидеры никогда не садятся и не спорят о плюсах и минусах со своими товарищами по команде. Вместо этого они используют интуицию, которая была разработана на основе обучения и опыта, чтобы помочь им принимать решения. То же самое относится и к нашей профессии: как вы можете принять полностью логичное решение, столкнувшись с кучей неизвестных и изменчивости, которые так распространены в разработке программного обеспечения? Авторы утверждают, что вместо того, чтобы пытаться оправдать каждое решение, следует поощрять разработчиков к обучению и совершенствованию своих инстинктов, чтобы в конечном итоге они «просто знали», что делать.

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

1. Вы можете попытаться получить звание (я закончил тем, что пошел к своему боссу и попросил звание, потому что я так устал от этих тупиковых споров)
2. Вы можете попытаться лоббировать большую часть команды, чтобы поддержать вас.
3. Если проект может позволить себе (т.е. не слишком большие потери производительности), что, по вашему мнению, является плохим решением, пусть другой человек выиграет спор. Произойдет одно из двух:
   • В некоторых случаях (надеюсь, очень малая часть) ваша интуиция будет неправильной, и вы в конечном итоге чему-то научитесь. Повезло тебе.
   • В большинстве случаев (опять же ... надеюсь) вы и человек, который защищал «плохой» дизайн, поймут, почему он плох; ведь задним числом всегда 20/20. Надеюсь, это будет урок для того человека, который, возможно, вы знаете, о чем говорите, и в следующий раз они дважды подумают, аргументируя свое дело.

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

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

Я стараюсь быть максимально честным в отношении того, что является спорным, и какой процент разработчиков согласился бы со мной.

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

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

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

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

Я нахожу хороший способ объяснить людям, предоставляя конкретные примеры прошлых ошибок, допущенных в проектах, в которых они активно участвовали (например: «Вы когда-нибудь пытались отлаживать эту вещь? Так было годами, и никто не знает, как почини это.."). Более того, применяя эти «новые» дизайнерские идеи и принципы к небольшому / пробному проекту и демонстрируя, насколько успешным он оказался в конце.

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

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

Зависит от зрителей! Как разработчики мы разработали интуицию для хорошего и плохого кода и использовали смутные эмоциональные термины, такие как «запах кода», «ужасный код», «красивое решение». Это работает только при общении с другими разработчиками с таким же мышлением. Постарайтесь объяснить своему нетехническому генеральному директору, что вы должны потратить x человеко-часов на то, чтобы сделать какой-то код «более красивым», что, скорее всего, приведет к провалу.

Вы должны быть в состоянии утверждать, что любое улучшение

• сэкономить деньги для компании
• заработать деньги для компании

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