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

1. Начните с нескольких вариантов использования
2. Начать кодирование
3. Осознайте несколько вещей, с которыми я не справился хорошо, и не очень хорошо вписывается в текущую кодовую базу.
4. Переписать большую часть кода

и это может пройти несколько раз

Так что мои вопросы

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

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

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

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

1. Начните с нескольких вариантов использования
2. Начать кодирование
3. Осознайте несколько вещей, с которыми я не справился хорошо, и не очень хорошо вписывается в текущую кодовую базу.
4. Переписать большую часть кода

Это действительно отличная отправная точка. Вот как я подхожу к этому:

1. Начните с нескольких вариантов использования

Хороший. Говоря «прецедентов», вы фокусируетесь на том, что программное обеспечение для . Говоря «несколько», вы не пытаетесь открыть все; Вы придерживаетесь контролируемого объема работы. Все, что я бы добавил здесь, это расставить приоритеты. С вашим клиентом или конечным пользователем выработайте ответ на этот вопрос:

Какое самое маленькое и простое программное обеспечение, которое я могу вам дать, улучшит вашу ситуацию?

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

2. Начните кодировать.

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

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

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

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

3. Обнаружение проблем или недостатков в дизайне.

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

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

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

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

4. Перепишите часть кода

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

5. Тест

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

6. Узнайте

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

Некоторые примеры:

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

Будь проворным

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

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

Это нормально.

Вы можете выбрать один из двух подходов:

1. Добро пожаловать изменить

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

2. Избегайте изменений

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

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

Разработка программного обеспечения была описана как ряд изначально «злых» проблем .

Хорст Риттель и Мелвин Уэббер определили «злую» проблему как проблему, которая может быть четко определена только путем ее решения или решения ее части *. Этот парадокс подразумевает, по сути, что вы должны «решить» проблему один раз, чтобы четко определить ее, а затем решить ее снова, чтобы создать работающее решение. Этот процесс был материнством и яблочным пирогом в разработке программного обеспечения на протяжении десятилетий

Это прекрасно описывает проблему, с которой вы сталкиваетесь. По сути, то , что мы делаем, сложно . Если есть часть, которая может быть описана как «рутина», со временем мы изолируем и автоматизируем ее. Так что все, что осталось, это либо новое, либо сложное.

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

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

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

1. Да, это распространено, за исключением, может быть, части «переписать большую часть кода». Вы никогда не получите все требования с самого начала, поэтому важно хорошо справляться с изменениями. Вот в чем суть концепции «сопровождения кода». Конечно, это также помогает тратить больше времени на разработку требований и правильное проектирование.
2. Во-первых, подумайте, какие изменения требовались в прошлых проектах и ​​как вы могли их предвидеть или лучше подготовиться к ним. В начале проекта, подумайте больше о деталях вариантов использования. Перед тем как приступить к реализации, сделайте некоторый абстрактный дизайн (каковы основные компоненты кода и как они взаимодействуют, каковы их API). Самое главное, постарайтесь сделать код как можно более простым и легким для изменения, ознакомьтесь с такими понятиями, как SOLID, DRY, KISS и YAGNI.

Является ли такая практика распространенной или подразумевает, что я не компетентен?

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

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

Как я могу улучшить себя в этом аспекте?

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

Как только вы начнете это делать, подумайте: как выглядит код, который не нужно переписывать ? Этот код:

• Делает одну полезную вещь.
• Делает это правильно.
• Делает это с достаточной производительностью.

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

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

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

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

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

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

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

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

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

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

4. Если вы работаете в рамках фреймворка, потратьте время, если вы можете сэкономить его, чтобы подумать, как сделать все с нуля. Например, вы можете легко собрать сообщение запроса, открыть сокет и выполнить запрос GET или POST вручную. Если вам нравится, вы можете вручную проанализировать XML-сообщения. Что бы вы ни делали, вопросы, которые вы генерируете, и ответы, которые вы найдете, повысят ваши навыки. Конечно, вы можете выбрать, какие типы основных вопросов важны или представляют интерес. Я бы подумал об этом личном развитии и не ожидал бы проводить здесь много времени в режиме реального времени.

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

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

Я хотел бы добавить несколько указателей

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

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

3) Найдите босса, который может понять, что вы, вероятно, никогда не совершенствовали свое письменное программное обеспечение. Если вы всегда подключаете новые функции / требования, которые бросаются на ваш рабочий стол, и никогда не заботитесь о своем программном обеспечении, оно ответит вам ошибками, недружелюбием при обслуживании и большим количеством волос, потянувших на несколько лет вперед. Получите это время / бюджет обслуживания программного обеспечения! Я считаю, что около 20% времени, необходимого для разработки программного обеспечения, требуется ежегодно для поддержания его в форме в течение всего срока его службы.

4) Этот процесс постепенного обучения никогда не останавливается (и не должен)! Вы оглянетесь через 10 лет и улыбнетесь.

Надеюсь, это поможет немного и удачи!