Существует ли пошаговая процедура для проектирования снизу вверх с начала первой строки кода?
Обновление почти в конце этого поста. Я ищу что-то вроде шаблонов дизайна, идиом, концепций с подходом к дизайну.
Например: я закончил цикл разработки и анализа для банковской системы. Требования, функции, варианты использования и схемы использования и т. Д. Уже готовы. (Сверху вниз) Теперь на этапе реализации я перехожу к подходу "вверх-вниз", чтобы кодировать первую функцию (после написания юнит-теста).
Вот главный вопрос: Существуют ли статьи, книги, ссылки о пошаговом процессе, таком как рефакторинг (Кент, Фаулер и т. Д.), Для проектирования "с нуля" с начала первой строки кода?
Что-то вроде графа решений. Как реализация первой переменной -> метод, функции, события и т. Д. -> рефакторинг -> ОО: первый класс, первый объект -> композиция, наследование, поли -> рефакторинг к шаблонам -> модули -> система, фреймворк и так далее.
Я продолжаю с примером банковской деятельности, чтобы прояснить его подробнее: Мой первый вопрос в графе решений спрашивает меня:
Вам нужна переменная, данные?
"Да" - перейдите к 2.
"Нет" - перейдите к 6. (Поскольку БД уже существует, например)
Что это за тип?
"Для моего ресурса это деньги, и я использую int, потому что я решил вычислить его с цент-единицами (решение о производительности)" - Сделайте его типом int и присвойте доменному имени зависимое имя!
Это глобальный вар?
"Да" - сделать это статичным
"Нет" - переходите к 4.
- Это исправлено при жизни?
"Да" - сделать финал и перейти к 6 (финал больше не может быть установлен)
"Нет" - переходите к 5.
- Вам нужен метод, функция, чтобы получить / установить эту переменную? "Да" - напишите эту функцию (сначала без проверки) и задайте доменное имя. 6... и так далее....
Пока у меня не появятся первая переменная и метод, можно сказать, что я должен создать первый класс и реорганизовать этот var и метод в него с целью ОО-проектирования. И каждый новый шаг продвигается дальше вверх по дереву решений, пока у меня не появится система "Лучшая практика". Лучший ремонтопригодный, расширяемый, инкапсулированный, производительный. Все концепции, задействованные от начала до конца. Таким образом, вы идете более абстрактно, пока он не соответствует уровню абстракции, где вы останавливаетесь сверху вниз.
- Второй крошечный вопрос: существует ли столько дублированного кода из-за абстрактного именования переменных, методов, классов? Когда я снимаю деньги со своего банковского счета, я просто выполняю математическую процедуру - вычитая переменную из другой (за исключением проверки и безопасности и т. Д.)
Извините за этот пост, но спасибо за чтение
Изменить: Чтобы уточнить, что я спрашиваю: Существует ли пошаговая процедура, как каталог решений, для программирования от простых строк кода до определенного уровня OO-абстракции?
Обновление: Извините, я не могу дать ответ на свой вопрос, поэтому я должен сделать это таким образом.
У каждой проблемы, у каждой задачи есть решение. Есть много способов найти это решение. Но все еще ограничен. Пути к этому решению включают принятие решений. Решения, которые вытекают из знаний, из опыта в определенной области. Каждый пытается избежать сложности, сталкивается с решением оптимизации памяти или времени, возможности повторного использования, обслуживания и т. Д. Систем, компонентов, классов, объектов, функций и данных.
Будучи новичком, вы изучаете язык программирования и знакомитесь с правилами. Позже она пишет свою первую программу, анализирует и разрабатывает свой первый проект. Знания и знания об определенных процедурах увеличиваются. Эволюционный процесс поиска решений возникает для достижения поставленных целей.
Все из конкретных, заранее определенных решений.
Существуют подходы, которые отображают эти деревья решений. Примеры включают рефакторинг и Agile методы как целостную концепцию. Александр Кристофер как источник идей для шаблонов. Позже последовали Кент, Фаулер, `дядя Боб 'и, конечно, GoF, и это лишь некоторые из них. Все они следуют определенным схемам. Эти образцы можно найти во многих книгах. Уильям Ф. Опдыке написал диссертацию о процедуре от самого простого процесса до специальной концепции ОО.
Тем не менее, я еще не нашел базы знаний, которая объясняет все эти концепции, принципы, идиомы или эвристики в пошаговом процессе, как это можно найти в книгах авторов, упомянутых выше.
Есть много сайтов, которые описывают эти шаблоны или рефакторинги. Единственные сценарии, которые изображают эту концепцию, можно найти в книгах Мартина Фаулера.
Если бы у меня было достаточно времени, размышлений и опыта, я бы создал такую базу знаний, доступную каждому.
Большое спасибо за чтение.
1 ответ
Не существует пошаговой процедуры, которая перенесет вас из нулевого кода в полную архитектуру системы. Как правило, происходит набор требований, чтобы определить, что, если что-то нужно написать. Это может включать в себя беседу с клиентами, обдумывание идей самостоятельно или в группе, или сравнение того, что предлагают конкуренты, каковы их сильные и слабые стороны.
Вы можете подумать, что, как только у вас есть набор требований, вы можете начать кодирование. Но дело в том, что а) это оставляет вас с длинным списком задач, которые необходимо выполнять без четкого порядка их выполнения, и б) требования будут меняться либо потому, что ваши клиенты меняются, либо потому, что вы понимаете, что Существующие требования либо недостаточны, либо нереальны, либо не соответствуют вашим требованиям.
Приложения часто разделяются на различные библиотеки и модули, которые обрабатывают различные проблемы. Вы можете использовать базу данных для хранения модели данных. Вы, вероятно, будете использовать UI-фреймворк, возможно, с каким-то MVC-слоем для обработки ввода и вывода пользователя. Вы будете нуждаться в других частях, которые могут не войти в хорошо известные образцы. Некоторые из этих вещей могут быть разработаны параллельно, возможно, разными людьми или командами. Или вы можете просто случайно выбрать место для начала и начать там работать.
За 30 с лишним лет профессионального программирования я никогда не видел, чтобы кто-то выполнял пошаговую процедуру для любой программы любого размера и производил что-нибудь полезное. Архитектура редко придумывается, а затем реализуется. Часто требуется несколько итераций, чтобы попытаться что-то предпринять, посмотреть, что работает и где есть несоответствия между частями, или проблемы со скоростью, использованием памяти или удобством использования, и переделать детали по ходу работы. Это проблема многих поколений, когда вам, возможно, придется выпустить свой продукт с некоторыми архитектурными проблемами, которые можно устранить только позднее, когда у вас будет время и средства.