С чего начать программирование?

Question

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

• Точка входа
• Framework / Поддержка классов
• Классы сущностей
• Сначала самое простое
• Сначала самое сложное

Что вы предлагаете?

Answer 1

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

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

1. Я склонен начать с создания грубой html-оболочки, чтобы дать представление о том, как должен выглядеть сайт.
2. Затем я начну с самой простой функциональности (во многих случаях это была гостевая книга или что-то вроде ввода / отображения данных в виде блогов), где я начинаю с настройки таблицы в базе данных, сопоставления ее с моим поставщиком данных ( Entity Framework, если я нахожусь в .Net) и получить сайт для доступа к данным (пока нет функциональности ввода!).
3. Когда страница получает данные правильно (я проверяю, помещая случайные вещи в базу данных вручную), я начинаю работать над входной частью этого раздела сайта.
4. Как только один раздел сайта (например, гостевая книга) готов и работает именно так, как я хочу, я перехожу к следующей части и начинаю снова с 1.

Answer 2

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

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

Answer 3

Мой опыт программиста подмастерье:

1. Планирование структуры данных
2. Сделать черновую версию пользовательского интерфейса
3. Код логики приложения
4. Нанести последние штрихи на пользовательский интерфейс

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

Answer 4

Мне нравится начинать с написания фреймворка, а затем позволить другим частям слиться воедино.

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

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

Answer 5

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

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

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

Answer 6

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

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

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