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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dilemmata

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

Нет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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