Ответ на пост «Как программисты пишут код?»⁠⁠4

после чего попытка связать все воедино, что, как правило в 99.99%, приводит к значительным переработкам ранее готовых кусков кода

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

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

Бизнесу именно это зачастую и нужно. Быстро выдать minimum viable product, не сильно упарываясь в оптимизации, но оставляя возможность для быстрой замены проблемных мест. А уже потом, если реально припрёт, рефакторить - оптимизировать - вылизывать.

Есть два типа людей: одни могут писать код, другие нет.

ИМХО. Одним интересно, другим, нет.

Те, которые могут, делятся на еще на два: те, кто сразу видят решение, и те, кто итеративно работает.

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

Ну тут странно - как можно заранее знать? Опыт показывает, что в процессе может стать очевидно решение, котором одним махом еще кучу проблем решает. Особенно если это решение комплексно-архитектурное. Заране запланировать такое сложно и бесполезно.

Рабочий код <> Оптимальный и масштабируемый код, что очень удручает, когда потребуется что-то добавить.

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

И начинаешь перебирать всё подряд

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

В данном конкретном случае - мне из API прилетает зашифрованная строка с помощью публичного ключа, RSA SSL чё-то там и вот это вот всё

В теории - берёшь да расшифровываешь с помощью закрытого ключа

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

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

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

Есть два типа людей: одни могут писать код, другие нет. Те, которые могут, делятся на еще на два: те, кто сразу видят решение, и те, кто итеративно работает.
Я в разработке с 2007 и всякого дерьма повидал.

вот тут ЧСВ

Или, как вариант, вы никогда не работали на действительно сложных и старых проектах.
Никто не будет ждать пока вы полгода-год будете изучать весь проект, когда ваша зона ответственности - это 1-2% от оного.
Ваше ЧСВ несколько завышено, ИМХО.

Да как бы, я вас как программист программиста прекрасно понимаю :) Я к стати тоже сначала всё "в голове пишу" а потом разом вываливаю. Мне так быстрее. Но и тимлида которому на ежедневках выносят мозг про "что сделано за вчера?" тоже от части понять могу. Тут надо, что называется - "на берегу договариваться", чтоб он тоже знал что по цепочке отвечать. Хотя да, встречал упоротых которые если думают что если не видят движа - то его нет и хоть заобъясняйся. В прочем - мне проще, я очень редко работаю в командах, в основном один. А сейчас вообще только своё пилю, где я и заказчик и исполнитель и бэкэнд и фронт и вообще всё.

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

Тож поддержу, это на 99,9 недостаток опыта.

Да пример - тупейший парсер, в целом ясно как он должен работать - сграбил, разобрал, отдал нужное, но реализация "разобрал" зависит от результатов того что сграбил. Тут либо за счёт опыта ты знаешь какой выхлоп, либо пробуешь в итерации. И чет я сильно сомневаюсь что ТС сделал бы с лету рабочий парсер без ручного разбора сграбленного html.

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

Попутно местами вводить мелкие "следы интеграции" - это если это нужно внедрить в что-то, что уже работает

А потом за несколько часов срыгнуть код согласно "комплексному подходу", отладить и пустить в продакт

Часто выбор метода между "сходу" и "итеративным" зависит от погружëнности в проект и наличия легаси в проекте.
Можно пойти и написать сложное абстрактное решение сходу. В вакууме, когда проект новый и ты его знаешь как свои пять пальцев.
А иногда приходится идти итеративно, потому что в лабиринте из говна и палок надо найти нишу, куда будет идеологически правильно вкорячить своё решение. По пути что-то обязательно отвалится. И ещё раз. И ещё. И ещё раз. А потом выяснится, что это плохая ниша, ведь вот тут, в куче говна было уже очень похожее и надо доработать просто, а не громоздить ещё рядом.

Фрагментарный подход. Как правило в 99.99%, приводит к значительным переработкам ранее готовых кусков кода

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

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

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

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

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