Программировать снизу вверх или сверху вниз?

По настроению. И в зависимости от выбранного подхода/процесса, при TDD, к примеру, снизу вверх будет не очень удобно.

В ширь или в глубь. В общем, как получится. В конце всё равно emacs выйдет.

Главное начать, а затем расширить и углубить.

Конечно, сверху вниз. Если снизу вверх, то получается

к
я
у
х

Как удобно в конкретный момент, так и накладывать. В любом случае, в конце концов, важна решённая задача, а не то, с какого конца её решать.

Как захочешь, главное чтобы все корректно работало)

Смотря на каком языке:

bar() // prints foo
function bar() { foo() }
function foo() { console.log('foo') }

~
❯ python /tmp/foo.py
Traceback (most recent call last):
  File "/tmp/foo.py", line 1, in <module>
    bar()
NameError: name 'bar' is not defined

~ 
❯ cat /tmp/foo.py
bar()


def bar():
    foo()


def foo():
    print("foo")

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

Никогда не думал, почему качественный коитус часто сравнивают с жаркой?

Неожыданный поворот. Продолжай.

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

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

сверху вниз сложнее и чтоб нащупать как правильно делаешь снизу вверх. :)

Хотя бы книжки Макконела почитай.

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

В общем, увы. Первоначальный вопрос не имеет смысла. И оба подхода не дадут ничего, если осуществлен просёр этапов формирования требований и проектирования.

всегда должна быть идея для ПО

С этим точно не поспоришь.

Из идеи выходит архитектура, её нужно в первую очередь продумать, не браться за ~напишем, а потом поправим~

Реальность немного другая, как пример диалог, ТЗ - технический заказчик, И - исполнитель:

ТЗ.: Сделаешь такой-то сервис?
И.: Сделаю, надо подумать как лучше, на каком стэке...
ТЗ.: Завтра надо показать MVP
И.: Точно не успею, всё-таки продумать схему БД, API  и т.п.
ТЗ.: Надо срочно завтра. Я уже продал...

Реальность немного другая, как пример диалог, ТЗ - технический заказчик, И - исполнитель:

Это правда! Но, именно по этому только 18% программных проектов укладываются в сроки и выполняют свои обещания полностью, их можно назвать успешными. 1/3 проектов превышает первоначальный бюджет в разы, который можно было бы сохранить потратив 2-3 недели на подготовку.

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

Баги на последнем этапе, кстати, в 15 раз дороже править чем на этапе проектирования или программирования.

Чтобы делать сверху вниз, нужна команда. В одиночку у тебя скорее всего быстро пропадёт задор, потому что делать «правильно» — рутинно и утомительно.

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

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

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

Программировать можно снизу вверх

Проектировать лучше сверху вниз

Процесс итеративный

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

Имхо задор пропадает когда долго нет результата которым можно пользоваться. Как раз снизу вверх такое

С обеих сторон.

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

Начинать нужно с написания тестов. Те как ты видишь пользовательское api. Потом его реализовываешь через другой слой. Получаешь вид api более низкого уровня. Итд

делать mvp - минимальное рабочее решение, потом его расширять итерационно.

Главная ошибка каждого mvpиста

Начинать нужно с написания тестов

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

Главная ошибка каждого mvpиста

это не ошибка, а самый правильный подход.

В контексте применения и самой сути mvp это именно ошибка

В контексте применения и самой сути mvp это именно ошибка

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

Программировать сразу суть

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

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

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

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

Ответивших «итеративно» тоже плюсую. «Большая работающая система ВСЕГДА получается из маленькой работающей системы. Большая система, целиком спроектированная на бумаге, никогда не заработает.» (c) какой-то из буржуйских гуру. Так что «несколько раз переделывать» придётся в любом случае.

Неважно. В начале def main с текстом основного блока программы, в конце main.

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

А для проекта, который в одну харю не делается, есть два варианта. Либо ты там главный разработчик, либо нет. Если нет, не парься, пусть главный решает. А если да, то скорее всего, с этим вопросом ты пойдёшь не на ЛОР. :) Ну то есть про каскадную, итерационную и эволюционную модели ЖЦ можно и в книжках почитать.

Слева направо.

Слева направо.

Шо, прям весь код в одну строку? А word wrap переносит вверх или вниз? Или даже word wrap не используешь?

Почитайте ещё про слева направо (Фуксман, Расслоённое программирование). Мож, понравится. Вообще, основоположники, помнится, писали, что до 1000 строк вообще неважно. У вас точно больше?

Программировать снизу вверх или сверху вниз? (комментарий)

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

Именно!

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

Именно! (2)

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

Минимально рабочая версия продукта (настоящего) – это уже не совсем MVP, либо MVP случился раньше (в лучшем случае), либо это уже какие-то ощутимые вложенные (потраченные) усилия/инвестиции.

Минимально рабочая версия продукта (настоящего) – это уже не совсем MVP

Так уж получилось, что MVP буквально переводится как «минимально жизнеспособный продукт». Настоящий он или нет - вопрос не к термину MVP

Я писал что сверху вниз И итеративно. Это в разы быстрее чем итеративно снизу вверх ;)

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

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

а потом делаешь из этой тачанки автомобиль

а потом думают […] как дизайн изменить, чтобы все вместилось

Фуксман, Расслоённое программирование

Это только в библиотеке советской выдержки выкопать можно?

В зависимости от:

• содержания проекта
• доступных ресурсов

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

А для проекта, который в одну харю не делается, есть два варианта

Есть куча вариантов, включая встречно-параллельную разработку из нескольких мест в разных направлениях (вертикально и горизонтально) )))

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

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

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

архитектуру лучше прорабатывать сверху-вниз

Это если и работает, то на несложных системах. Чаще приходится искать компромисс.

От задачи зависит. Если прога «для себя» (для конторы своей) да еще из готовых кубиков — сверху-вниз работает вплоть до nocode-«решений». Если это либа общего назначения — без снизу-вверха никак. Если готовых компонентов для какой-то части системы нет опять же не получится совсем без снизу-вверха.

«Покажите на этой схеме, где не работает?» (С) платиновый вопрос наивных сис. аналитиков и архитектургов. Опытные понимают, что их верхнеуровневые доки устаревают в момент написания по ним кода и уточняют «ну, как я там придумал, рассказывайте чо поменять чтоб работало» :)

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

слева направо;)