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

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

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

Второй совет: действительно продумайте проект еще до того, как напишите какой-либо код.

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

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

Как мне поступить с этими проектами?

Должен ли я просто начать программировать что-то и учиться (платформы / методы / языки / архитектуры) по ходу дела - или я воздерживаюсь от кодирования и выполняю тонны исследований / чтения, прежде чем даже открыть IDE?

Как мне примирить эти противоречивые советы по программированию?

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

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

Просто маленький пример. На днях я боролся с решением о разработке программного обеспечения. Оглядываясь назад, это было относительно тривиально, но у меня было две альтернативы, и казалось, что они оба будут работать. Я продолжал возвращаться к плюсам / минусам каждого, а затем возвращался назад и пересматривал свои решения. Оглядываясь назад, я немного смущаюсь, сколько времени я трачу на размышления. Тогда я сказал себе: f # @ k! И вместо того, чтобы использовать какой-либо из проектов, я просто взялся за совместный взлом некоторого кода, полностью игнорируя все хорошее, что вы узнали о хорошем дизайне. Я получил эту функцию за 45 минут. Затем я вернулся, посмотрел на мой код и преобразовал его во что-то солидное и что-то, что мне не было бы стыдно при проверке контроля версий. Самое смешное, что после того, как я взломал работу, придумать

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

Есть определенные решения, которые должны быть приняты заранее.

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

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

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

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

Я не рассматриваю эти два как взаимоисключающие.

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

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

Как часто вы отпускаете / и т.д. зависит от конкретной методологии, которую вы используете.

То, что вы должны исследовать, зависит от того, что вы знаете, с тем, что вам неудобно.

«Итерация» и «продумывание» не противоречат друг другу, а дополняют друг друга.

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

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

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

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

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

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

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

Мое эмпирическое правило: если вы не до конца понимаете какую-либо часть проблемы, вам нужно сделать шаг назад и полностью обдумать ее (я включаю создание прототипов и одноразовый код для понимания API и т. Д. Как часть «продумывания») , Если это в основном набор проблем, которые вы уже решили ранее, и вам просто нужно найти лучший способ совместить все в этом конкретном случае, то итерируйте.

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