Надоело переписывать код в ходе разработки по несколько раз, поэтому хотелось научиться сначала проектировать/планировать, а затем реализовывать. Вот что я имею ввиду под этим.
Скажем у меня есть компонент кастомный селект. Я начинаю его делать и входе работы вспоминаю, что ведь нативных селектах можно стрелочки вверх/вниз клацать и значение меняется. Начинаю это добавлять в код, что-то переписывая. И т.д. А как хотелось бы?
Хотелось бы заранее понять какие переменные мне могут быть нужны (например, текущее значение селекта, значение option в фокусе), какие методы могут пригодиться и вообще как оно должно работать. А код писать уже глядя на то что получилось. Что-то меня тянет к конечным автоматам, но пока не пробовал.
Кто как решает эту проблему, кто какими инструментами пользуется?
>Надоело переписывать код в ходе разработки по несколько раз
Welcome to the party.
>хотелось научиться сначала проектировать/планировать, а затем реализовывать
Это миф. Ходят легенды, что один програмист смог так сделать, но знание о том КАК он это сделал - утеряно в веках.
Всегда будут переделки. Даже самое четкое и подробное ТЗ в конечно итоге меняется.
Можно составлять всяие майндмапы, чтобы хоть как-то представлять себе весь процесс разработки. Но мне они не нравятся.
----
Именно из-за этой проблемы и были придуманы всякие Agile/SCRUM и другие подходы к разработке.
Я и не жду чего-то идеального, но это не означает что нет решения, может просто вы его не знаете или для вас нормально переделывать. И по-моему спроектировать компонент реально сразу, если есть опыт
psyhO_octopus:
>И по-моему спроектировать компонент реально сразу, если есть опыт
Яснопонятно. Удачки. Я думаю на women.ru вам подскажут, там у посетителей явно опыта больше чем у меня.
psyhO_octopus: по моему это как сразу получить от бизнеса полное ТЗ. Чтобы вот сами сели и написали - и больше никаких уточнений.
фактически здесь то-же самое, только Вы и бизнес и аналитик в 1 флаконе. Сядьте и до реализации опишите весь функционал компонента.
Да, сказочное русское комьюнити - не помогут, но советов не по теме надают. Если вы уж кастомный селект заранее спроектировать не можете, то о чем с вами говорить. А Agile/SCRUM это из другой оперы.
Макс: а потом он вспомнит, что его компонент должен работать только в 3й фазе луны, когда Юпитер в зените. И придется переделывать всё заного :)
Плавали, знаем.
И что, что нельзя. Значит не стоит этого делать? Т.е. вы отрицаете проектирование как таковое. Отлично. Можете не отвечать, мне вам доказывать ничего не хочется, а ответа вы все равно не дадите. Зачем разжигать тут?
psyhO_octopus: Да, сказочное русское комьюнити...
Ты спрашиваешь: "как заранее покрыть все юзкейсы и составить четкий план разработки".
Я тебе отвечаю: "Это нельзя сделать заранее. Переделки всегда будут."
Даже при проектировании кнопки, ты не покроешь все юзкейсы, пока не опробуешь свою кнопку в своем или чужом проект.
Я дал ответ на твой вопрос. Но тебе ведь не нужен ответ? У тебя в голове уже есть свой ответ, который ты считаешь единственно верным, и сюда ты пришел только лишь для того, чтобы тебя убедили что ты прав.
Именно поэтому я и посоветовал тебе обратится на women.ru, там местные жители любят успокаивать и поддакивать таким как ты.
Русскоязычное коммьюнити примечательно еще тем, что порождает умопомрачительные вопросы. Которые нельзя адекватно оценить - можно только удалить (пожаловаться) и ждать следующего такого же вопроса.
Никогда не получится идеально с первого раза. И всегда нужно пробовать и искать пути оптимизации. Если вас интересует, как построить оптимальный процесс в конкретной среде - так и задавайте вопрос. А в общем смысл серебряной пули нет.
TDD подразумевает test, code, refactor. То есть, "переписывание кода" заложено уже в определении. И точно так же, сколько б вы раз во времени не возвращались к коду, вам всегда будет что-то не нравиться и будет желание переписать - это нормально.
В целом от поста веет максимализмом и преждевременной оптимизацией.
psyhO_octopus: и что это решает? Бизнес требования то все равно составляешь ТЫ.
По сути обычная майндмапа наложенная на идею конечных автоматов. Только это ниразу не ответ на твой вопрос.
Ты всё равно не опишешь всё, что тебе нужно. И всё равно будешь переделывать.
psyhO_octopus: в несостоятельности вопроса: в заголовке вы спрашиваете, как проектировани компоненты, в начале тела вопроса - как избежать переписывания кода, а потом плавное переходите к использованию конечных автоматов для проектирования джаваскрипт-виджетов для браузера.
Есть множество способов оптимизации разработки: тдд, бдд, итерации, каскады, псевдокод, экспертная оценка, ранее тестирование ...
Виктор Ablebeam: да забейте. Автор хотел чтобы его убедили, что конечные автоматы - это круто и что стоит их использовать. Весь вопрос был только из-за них. Его не интересуют адекватные ответы.
Виктор Ablebeam: вы вроде адекватный человек, постараюсь пояснить в чем вопрос. Если прочитать вопрос внимательно, то можно заменить, что изменение кода происходит не из-за изменении ТЗ или чего-то еще, а именно из-за того, что я не подумал за ранее и сел писать код. Если я бы пытался продумать за ранее что может случить с тем же селектом, то такой проблемы бы не было. Т.е. проблемы не в меняющих требованиях, не в заказчиках или фазах луны, а в том что я не думал (проектировал) за ранее. Конечные автоматы это просто то, что мне кажется могло бы решить проблему, но я не уверен. А вопрос в том как правильно проектировать за ранее и какими инструментами пользоваться. Ибо даже если я бы хорошо подумал о селекте, то все в голове было бы сложно удержать и я все равно бы ошибки.
psyhO_octopus: Человеком адекватным вы меня считаете только потому, что я ответил вам более лояльно :)
Ответа ваше объяснение не меняет. В конце вы сами ответили на свой вопрос - все в голове удержать невозможно. То, что вы вспомнили о том, что ваш кастомный селект должен уметь стрелочки - это самое что ни на есть изменение ТЗ. Просто составляли его вы сами и в неформальной атмосфере
С этой точки зрения конечные автоматы являются точно такой же альтернативо, как и методы, что я привел раньше. Лучше или хуже - это решать в рамках конкретной задачи.
Что вы к этим автоматам привязались? Может это вы их очень хотите, а не я. Я рад услышать другие варианты, просто я их не знаю. А автоматы упомянул лишь потому, что слышал о них. Разве это так трудно понять? Если использовали автоматы ок, расскажите о опыте и инструментах. Если использовали что-то трудно, то еще лучше, так же расскажите, а не перечислите списком уходящим в троеточие
psyhO_octopus: вот здесь и несостоятельность вопроса. Вы предлагаете мне перечислить вам опыт моей разработки за несколько лет над проектами с совершенно разными стеками технологий, направленнастями и масштабами, часть из которых, по итогу, вам никогда не пригодится ?
Вот вам и русское коммьюнити.
Хотите конкретные ответы - задавайте конкретные вопросы:
Как избежать переписывания кода? -- Никак
Какие существуют методики оптимизации при абстрактном проекте\бюджете\цели\сроках\стеке\... ? -- Точно такие же, уходящие в троеточие, только через запятую.
Чтобы спланировать нужно сделать всего 2 вещи:
1. Изучить предмет. Какой смысл вообще делать кастомный селект, если вы не прочитали спецификацию, не изучили mdn и т.д. и не знаете до конца, как работает оригинальный.
2. Составить список фич, поддержку которых нужно реализовать. А это TODO список. В этом вам помогут специальные сервисы вроде https://trello.com/
psyhO_octopus: ваш вопрос был в том что вы всё забываете, начинаете делать без плана. Каков вопрос, таков ответ. Что вы еще хотите услышать? Как именно планировать? Я лично это делаю в Trello. Создаю проект, расписываю компоненты, создаю todo списки по каждому. И следую.
