Над развитием мышления

88

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

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

Он сказал, что я радикально размышлял над этой задачей, и потому что я никогда не занимался проектом такого масштаба, прежде чем тратил слишком много времени на размышления о шаблонах проектирования. Своими мудрыми словами он сказал мне: «Черт возьми, строить сейчас».

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

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

sf13579
источник
5
что похоже больше связано с кодированием, чем с дизайном
Balog Pal
22
Я + 1-е изд только для "F * ck the future, build to now". Если ему захочется одобрить это заявление, я буду рад отметить его всякий раз, когда добавляю это в журнал коммитов после того, как вычеркиваю что-то, что у меня тупо перегружено (что случается гораздо чаще, чем хотелось бы).
Хайлем
13
Напоминает мне о старом коллеге, который всегда «покрывал золотом» свои приложения со слишком большим количеством функций, передозировкой дизайна и вещами, в которых вообще не было необходимости просто «хвастаться» или «готовиться к будущему, которое никогда не наступит» , Очень интересный вопрос :)
Жан-Франсуа Кот
8
@Jean: Единственные проекты, где «будущее, которое никогда не наступит», - это программы, которые являются неудачными (даже если проект был признан успешным). Если ваша программа успешна, это означает, что она используется. Если он используется, то пользователи захотят больше возможностей. Если вы придерживаетесь философии «постройки сейчас», то вы получите текущее состояние большинства программного обеспечения сегодня. Чрезвычайный мусор, трудно изменить. Единственная причина, по которой разработчики могут сойти с рук, это то, что она настолько распространена. Опытные разработчики будут создавать системы быстрее, делая это правильно с самого начала и не заканчивая мусором.
Данк
55
Подобные вопросы похожи на тест Роршаха. ОП не предоставляет достаточно информации, чтобы знать, является ли он на самом деле чрезмерным дизайнером или его наставник - недостаточным дизайнером. При отсутствии достаточной информации каждый видит то, что хочет.
PeterAllenWebb

Ответы:

112

Капитан очевиден для спасения!

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

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

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

Построить сейчас, если ...

  • проект будет свернут
  • проект имеет короткий срок службы
  • проект не должен иметь расширений
  • проект не имеет значения влияния риска (в основном с точки зрения имиджа)

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

Оставьте общую проблему на потом, если это может понадобиться и стоить усилий:

XKCD: общая проблема

Строить для будущего, если ...

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

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

Методические рекомендации

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

  • знаю, что ЯГНИ ,
  • Поцелуй ,
  • всякий раз, когда вам захочется почесать зуд и подумать о добавлении, запишите его. Посмотрите на требования вашего проекта и спросите себя, являются ли дополнения приоритетами или нет. Спросите, добавляют ли они основную ценность для бизнеса или нет.

Я знаю, что лично я склонен переосмысливать и переусердствовать. Это действительно помогает записывать идеи и очень часто переосмысливать, если мне нужны дополнительные функции. Часто ответ отрицательный или «это будет круто позже». Эти последние идеи опасны, потому что они остаются в моей голове, и мне нужно заставить себя не планировать их.

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

Просто строить простые вещи.

Dilemmata

переустройства

Является ли это тенденцией, которой обычно придерживаются программисты при разработке такого проекта?

Черт возьми да Это известная дилемма, и она только показывает, что вы заботитесь о продукте. Если вы этого не сделаете, это больше беспокоит. Существуют разногласия по поводу того, действительно ли меньше всегда действительно больше, а если хуже, то всегда действительно лучше . Вы можете быть парнем из МТИ или Нью-Джерси . Здесь нет простого ответа.

Прототипирование / Quick-n-Dirty / Less is More

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

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

Дилберт на отгрузку прототипов непосредственно на производство

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

Когда использовать прототип?

Есть подсказки относительно лучших типов проектов для использования прототипов :

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

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

«Одним из наиболее продуктивных применений быстрого прототипирования на сегодняшний день является инструмент для итеративного проектирования требований пользователя и проектирования интерфейса человек-компьютер».

С другой стороны:

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

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

Дилберт о продлении периода прототипирования

haylem
источник
1
Я не могу особо подчеркнуть, насколько важны те моменты, которые вы высказали о прототипировании. Я не думаю, что это действительно то, о чем был вопрос (главным образом о том, когда можно остановиться и спроектировать, а не просто построить, как я понимаю), но создание прототипов, безусловно, является важной частью этого процесса. Хорошая работа!
Бенджамин Грюнбаум
3
Я довольно озадачен тем, почему я получил здесь отрицательное голосование. Пожалуйста, будьте любезны, предоставьте информацию об этом, чтобы я мог видеть ошибки моих путей, сенсей.
Хайлем
7
Раньше я работал с инженером-механиком, который выражал это так: хотите ли вы, чтобы ваш продукт был недостаточно спроектирован или перепроектирован? Это действительно единственные два варианта.
Гай Сиртон
1
@SamtheBrand: спасибо за отличное редактирование. Намного лучше.
Хайлем
1
@haylem: иногда я обнаруживаю, что внедрение идей в отслеживание проблем (если ваш проект достаточно велик, чтобы их иметь) позволяет мне удалить их из затылка. Знание того, что они каким-то образом видны другим, заставляет меня чувствовать, что мне не нужно постоянно возвращаться к ним в моей голове (хотя там тоже есть балансирование =]).
afuzzyllama
54

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

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

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

  1. Разработайте и обсудите немного.
  2. Напишите кучу кода, который что-то делает.
  3. Распознать проблемы и остановить кодирование.
  4. Серьезно относитесь к дизайну и перестаньте беспокоиться о потере импульса или кода-mojo и игнорируйте менеджера проекта (вы делаете ему / ей одолжение).
  5. Получите проект под контроль. Исправьте свои беспорядки. Убедитесь, что все понимают план. Держите проект под контролем.

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

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

JeffO
источник
1
+1 за doing your bosses a favor, даже если они так не думают
superM
2
+1 Отличный пост. Это действительно хороший менеджер, который понимает, что хороший дизайн должен просачиваться - и это не обязательно связано с клавиатурой!
Робби Ди
Argg, если только я прочитал этот ответ, прежде чем я начал! Спасибо, и для кого-то, кто только начинает в этой отрасли, я люблю эти сумасшедшие кривые изучения!
sf13579
2
+1 заYou have to plan and plan a lot, but don't do it all at once.
Рафаэль Эмшофф
2
@Geek: mojo, flow, zone ... или какой-нибудь вызывающий / модный / хипстерский термин, который можно выбрать для описания состояния производительности.
Хайлем
24

Программисты обычно создают что-то, что работает сейчас, не думая о будущем?

Да.

Должны ли они сделать это?

Нет.

На первый взгляд может показаться, что «размышления о будущем» нарушают устоявшиеся принципы проектирования, такие как KISS и YAGNI , которые утверждают, что не должно быть реализовано ничего, что сейчас не требуется.

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

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

superM
источник
3
Хотя то, что вы говорите, имеет большой смысл, мой личный опыт говорит мне об обратном. Обычно, когда разработчики попадают в режим @F *** k это ... просто отправьте его @, как правило, повсюду появляется множество загруженных копий кода. Конечный результат совершенно невозможен. Забота о будущем - это не только расширения и модификации, но и обслуживание.
Ньютопия
13

У проворных разработчиков есть поговорка «Вам это не нужно» (YAGNI), которая поощряет вас разрабатывать то, что вам нужно сейчас, а не то, что, как вы думаете, может понадобиться в будущем. Чтобы расширить дизайн, чтобы работать в будущем, рекомендуемый маршрут - рефакторинг.

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

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

user93143
источник
1
Есть и другие причины задуматься о том, что разрабатываемая вами функциональность не вписывается в один спринт. Таким образом, вы либо разбиваете это искусственно, либо отказываетесь от реализации каких-либо функций, которые вы не можете выполнить в течение одного спринта.
Джорджио
+1 за упоминание рефакторинга. Я не могу поверить, что ни один из других ответов до сих пор не упомянул это. YAGNI жизнеспособен, только если вы выполняете рефакторинг.
Ян Голдби
7

Является ли это тенденцией, которой обычно придерживаются программисты при разработке такого проекта?

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

Слишком легко думать, что приложение должно делать то и это и быть отвлеченным.

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

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

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

Робби Ди
источник
6

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

Я думаю, что это немного ковбойский менталитет от другого разработчика. Современная версия крутого ботаника, который просто «делает это сейчас». Это стало популярной темой среди стартапов, и спасибо людям в Facebook за то, что они начали фразу «сделать это лучше, чем сделать это правильно».

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

Это идеалистическая фантазия, и жизнь не работает таким образом.

Дурак ворвется в проект, думая, что он может просто «сделать это» и сделать это. Успех пойдет на пользу разработчику, который готовится к невидимым испытаниям и относится к своей профессии как к тонкому мастерству.

Любой старший разработчик может критиковать, осуждать и жаловаться - и большинство из них!

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

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

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

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

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

Reactgular
источник
1
+1 за упоминание о чуме псевдо-наставников в Интернете
FolksLord
5

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

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

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

Балог Пал
источник
3

Есть несколько веских причин выслушать совет, чтобы прекратить планирование и начать кодирование;

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

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

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

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

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

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

Есть менеджеры, которые сами не могут определить тренд, пока он уже не прорывается на фейсбуке. Вместо того, чтобы найти работу по управлению магазином дисконтных шин, эти менеджеры делают вашу проблему в том, что им нужен код, работающий к пятнице. Они не хотят слышать, что вам нужно спроектировать API или проверить, является ли ваш алгоритм масштабируемым. Для них это просто техническая штуковина. Они будут поощрять вас к написанию кода, потому что это все, что они понимали о программном обеспечении, когда они писали Perl-сценарии, чтобы помочь клиентам передавать свои файлы. (У них было название «инженер-программист» на их первой работе по продажам. Кто знал, что программное обеспечение будет таким скучным и сложным?)

SeattleCplusplus
источник
-6

Покажи мне свой код, и я скажу кто ты

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

Вы становитесь тем, что вы кодируете

Ваш код - это ваша программа на всю жизнь.

Программист, пишущий плохой код, похож на балерину, танцующую в стриптиз-клубе

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

Наконец, вы должны прочитать роман Гоголя «Портрет», и вас должна предупредить история главного героя. Ваш друг похож на мужчину из портрета. Он заманивает вас деньгами, но вы заплатите за это высокую цену.

FolksLord
источник
4
Я не просил людей делать личные комментарии о моем наставнике, я спрашивал, где границы, где в отношении продуманных шаблонов дизайна. «Заманивать вас деньгами» - глупое неуместное предположение, и на самом деле он не тот, кто мне платит.
sf13579
4
Оценивать чей-то интеллект на основе одного фрагмента нелепо. Нет живого разработчика, у которого нет своего имени хотя бы в одном фрагменте кода.
Брайан Грин