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

Для контекста я создаю настольное приложение. Я единственный разработчик, и я делаю это неполный рабочий день, так как у меня есть дневная работа. Теперь, на работе, я стараюсь делать все правильно, график позволяет. Но для этого проекта, который, как я ожидаю, изменится, когда я получу отзывы от людей, я не уверен, что это правильный подход. На этой неделе я потратил несколько часов на то, чтобы внести в конструктор учебника Model View учебник, чтобы сообщить об изменениях модели в представлении. В целом это замечательно, но я не уверен, что мне нужно несколько представлений для отображения данных, и я знаю, что я мог бы отображать вещи быстрее без дополнительной архитектуры. Если у меня есть 10-15 часов в неделю, чтобы потратить на проект, я чувствую, что понадобятся целые годы, чтобы создать что-то, что я смогу продемонстрировать, если буду следовать хорошим практикам программного обеспечения. Я знаю, что мои пользователи победили Мне все равно, что я использовал MVC внутри, они просто хотят что-то, что решит их проблему. Но я также попал в ситуацию, когда вы понесли так много технических долгов из-за коротких путей, что код просто невероятно сложно поддерживать и добавлять новые функции. Мне бы очень хотелось услышать, как другие люди подходят к такой проблеме.

Постройте это хорошо .

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

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

Другими словами (если это не одноразовый контракт), постройте его быстро = постройте медленно, постройте хорошо = постройте быстро .

Также есть кое-что важное, что нужно осознать в «построении хорошо» и проектировании архитектуры. Ты спросил...

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

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

Закон Джона Галла от Systemantics :

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

Быстро, тогда хорошо

Это из моего личного опыта перепробовал много разных методов.

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

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

Поэтому быстро, хорошо!

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

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

Таким образом, в моем случае, в любом случае, вы получите приложение со звуковой архитектурой настолько эффективно, насколько это возможно :)

Построить это

Быстро, если время выхода на рынок важнее качества

Хорошо, если качество важнее, чем время выхода на рынок

Построение этого быстро принесет вам краткосрочные выгоды и долгосрочные убытки.

Хорошее его строительство приведет к кратковременным потерям, но принесет долгосрочные выгоды.

Строительство его требует терпения и мудрости, но вы будете вознаграждены.

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

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

Это может быть удручающе медленным время от времени. То, что стоит делать, стоит делать правильно.

Строим это хорошо = строим это быстро

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

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

Ну, если вы уже знаете, что делаете, быстро, если вы не знаете

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

1. Сделай так, чтобы это работало.
2. Сделать это правильно. Если вы сделаете это правильно, у вас будет преимущество в том, что вы сможете лучше определить «правильно», если у вас уже есть опыт заставить его работать.

Постройте это хорошо .. всегда, но создайте иллюзию быстрого движения

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

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

Остаток средств

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

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

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

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

Вы сказали, что лучше всего

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

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

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

Постройте это хорошо . Если у вас нет времени, уменьшите набор функций.

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

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

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

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

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

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

Это также подход, который я использую, работая профессионально. ;)

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

Вы обычно хотите быть в середине этих двух краев:

Создайте это хорошо = жизненно важное программное обеспечение реального времени, от которого зависит жизнь людей. программный контроль: ядерные реакторы, диализные аппараты, МРТ-аппараты и т. д.

Build it fast = бесполезное программное обеспечение, которое на самом деле никто не использует.