Это хороший совет. Напоминает исторический момент разработки Windows 98 и NT. 1-я клепалась быстро, она была как "эскиз" для понимания и конкуренции. Стоит вспомнить какая же она была глючная. Вторая, делалась тщательно и порциями. Благодаря чему и появилась XP. Каждый раз, когда в код вносится новая конструкция, понятное дело, лучше когда она надёжная, т.к. на неё обычно завязывается много других конструкций кода. Но меня всегда волновал вопрос быстрой разработки, но качественной. И это в какой-то степени упирается в хорошее знание инструментов разработки и их развитости.
хорошее программирование - это как игра в шахматы. Чем на большее шагов вперёд продумаешь свой ход (своё изменение), тем успешнее игра (лучше программа). Новички думают на один шаг вперёд, и пох , что там будет потом ))
именно так ) но плюс в том, что с помощью git ты можешь всегда "переходить". чем больше опыта - тем дальше продумываешь и реже приходится ходить по граблям... но все равно получать периодически граблями по голове - неотъемлемая часть этой шахматной партии) особенно при работе в команде
Как так, это ровно мои вчерашние мысли) Меня сильно демотивирует долгий поиск того места кода, который работает не так, как надо. Break point-ы не всегда помогают, да и они не сохраняют историю. Точно помогают print-ы, но если "понаписала кучу всего", то и расставлять print-ы тоже надо повсюду... Поэтому пришла к выводу: все, теперь только мелкими порциями делать и все по ходу проверять.
Чтобы не сталкиваться с проблемой, которой описал автор ролика, нужно научиться писать "автотесты" !!!! Не надо изобретать велосипеды !!! Прочитайте просто как это делать правильно !!! Эта информация доступна в интернете ! Уже написано куча статуй по этому поводу !!! Зачем пытаться изобрести велосипед? Я не понимаю!?
@@user-sw4ny2bz1nообще да, насколько я знаю инструкция call в ассемблере довольно затратный поэтому где можно (в с++ например) стараются использовать inline
Это хороший совет. Напоминает исторический момент разработки Windows 98 и NT. 1-я клепалась быстро, она была как "эскиз" для понимания и конкуренции. Стоит вспомнить какая же она была глючная. Вторая, делалась тщательно и порциями. Благодаря чему и появилась XP. Каждый раз, когда в код вносится новая конструкция, понятное дело, лучше когда она надёжная, т.к. на неё обычно завязывается много других конструкций кода. Но меня всегда волновал вопрос быстрой разработки, но качественной. И это в какой-то степени упирается в хорошее знание инструментов разработки и их развитости.
хорошее программирование - это как игра в шахматы. Чем на большее шагов вперёд продумаешь свой ход (своё изменение), тем успешнее игра (лучше программа).
Новички думают на один шаг вперёд, и пох , что там будет потом ))
именно так ) но плюс в том, что с помощью git ты можешь всегда "переходить". чем больше опыта - тем дальше продумываешь и реже приходится ходить по граблям... но все равно получать периодически граблями по голове - неотъемлемая часть этой шахматной партии) особенно при работе в команде
Будет продолжение по си или по рогалику?
Как так, это ровно мои вчерашние мысли) Меня сильно демотивирует долгий поиск того места кода, который работает не так, как надо. Break point-ы не всегда помогают, да и они не сохраняют историю. Точно помогают print-ы, но если "понаписала кучу всего", то и расставлять print-ы тоже надо повсюду... Поэтому пришла к выводу: все, теперь только мелкими порциями делать и все по ходу проверять.
@@maks2 В моем случае это Dart + Flutter. И, например, при асинхронных операциях неудобно пользоваться дебаггером.
@@maks2 на го тоже брекпоинты можны поставить
Есть такое правило)
Идеальный код, это отсутствующий код.
Любой код это "груз" который нужно дебажить придерживать и актуализировать.
юбилейный выпуск
НЕ ИСПОЛЬЗУЙТЕ print-ы !!!! Это дурная привычка !!!! Почитайте про "Логирование в Golang " !!!
Ешь слона маленькими ложками.
Чтобы не сталкиваться с проблемой, которой описал автор ролика, нужно научиться писать "автотесты" !!!! Не надо изобретать велосипеды !!! Прочитайте просто как это делать правильно !!! Эта информация доступна в интернете ! Уже написано куча статуй по этому поводу !!! Зачем пытаться изобрести велосипед? Я не понимаю!?
если бы ты знал что такое обьекто-ориентированое программирование то мог бы откатить один обьект и протестировать и т.д, а не целый коммит
Слышал, функции замедляют код? Так ли это?
@@user-sw4ny2bz1nообще да, насколько я знаю инструкция call в ассемблере довольно затратный поэтому где можно (в с++ например) стараются использовать inline