Python-сообщество

Массив имеет такой вид (внутри массива строка). А нужно посчитать самую часто встречающуюся букву.
Напишите пожалуйста какой командой это можно сделать, пробовал через Counter, но он выводит всю строку целиком

Отредактировано py.user.next (Апрель 27, 2021 08:40:32)

py.user.next

Я попробовала решить задачу известными мне способами, потому что пока не знаю itertools и collection

Получилось вот что:

В процессе выяснила, что моя программа будет работать неправильно для случая, если самых часто встречающихся букв более одной.
В списке ‘а’ встречается 6 раз и ‘b’ тоже 6 раз, а на печать будет выводиться ‘a’

Попробовала этот список с одинаковым количеством ‘a’ и ‘b’ подставить в твой код и тоже на выходе получила только ‘a’.

Подсунула список lst = и на печать получила ‘e’. Получается, что если буквы встречаются одинаковое количество раз, то выводится та, что в исходном списке встретится первая (я еще потестила эту гипотезу, подставляя разные буквы)

Тут сразу возникло много вопросов:
1) Нужно ли модицифировать решение, чтобы корректно обрабатывался случай, когда самых часто встречающихся букв больше одной? Что вообще будет корректным ответом в этом случае? Я подумала, что стоит перечислить все буквы, которые наиболее часто встречаются в массиве.
2) Словарь в python неупорядоченная коллекция и я подумала, что если я много раз (много - это допустим 100 или 1000 раз) буду искать наиболее

Но запустив:
я получила на печати 1000 ‘с’ и ни одной ‘b’. Почему?
Раз словарь неупорядоченная коллекция, то я думала, что при большом числе запусков могут быть оба ответа, потому что и с, и b встречаются по 3 раза, а значит ключом с максимальным значением мог быть в какой-то момент с, а в другой момент - b.
Почему этого не произошло? 1000 - это слишком мало попыток? Как это работает?

Ocean
1) Нужно ли модицифировать решение, чтобы корректно обрабатывался случай, когда самых часто встречающихся букв больше одной? Что вообще будет корректным ответом в этом случае? Я подумала, что стоит перечислить все буквы, которые наиболее часто встречаются в массиве.

Надо сначала поставить задачу.

Вот одна задача

Массив имеет такой вид (внутри массива строка). А нужно посчитать самую часто встречающуюся букву.

Вот вообще другая задача

Массив имеет такой вид (внутри массива строка). А нужно посчитать самые часто встречающиеся буквы.

Вот третья задача, которая тоже другая

Массив имеет такой вид (внутри массива строка). А нужно посчитать самую часто встречающуюся букву. Если их несколько, то посчитать самые часто встречающиеся буквы.

В первой задаче подразумевается, что такая буква одна. Во второй задаче подразумевается, что такая буква не одна. В третьей задаче подразумевается, что такая буква либо одна, либо не одна. То есть это как 1 & 0, 0 & 1, 1 & 1 - три абсолютно разных выражения. Есть ещё четвёртое выражение 0 & 0, которое вполне подходит под начальную формулировку, так как строка или строки в массиве строк может быть пустой или пустыми. То есть нет ни одной самой встречающейся буквы, ни нескольких.

Ну так вот, вот эти задачи похожи друг на друга, но они разные. И то, что они похожи друг на друга, не значит, что они должны каким-то образом обрабатываться одним чудесным кодом. Это ловушка. Так часто кажется новичкам “ну, не буду же я, как дурак, писать три кода, я напишу один, типа я умный”. И вот так они начинают делать что? Они начинают алгоритм подгонять под код и задачу подгонять под алгоритм. То есть не собака начинает крутить хвостом, а хвост начинает крутить задней частью собаки, а потом задняя часть собаки начинает крутить всей собакой. И это уже не собака.

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

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

Да, ты задачу не поставила, поэтому у тебя скошенная прога получилась. Ставь задачу или все задачи и пиши каждый вариант отдельно лучшим для этого варианта способом. Не подгоняя ничего с мыслями “а вот там, в другом варианте, оно должно тоже работать, поэтому тут нельзя вот так”. Не, нужно использовать лучший способ реализации для каждого варианта. Ты один вариант должна научиться писать. А написать три в одном можно будет, пройдя только стадию один в одном и освоив её полностью.


tags: task

Отредактировано py.user.next (Май 4, 2021 06:33:19)

Ocean
Словарь в python неупорядоченная коллекция

Он уже стал упорядоченным
https://docs.python.org/3/library/stdtypes.html#mapping-types-dict

Dictionaries preserve insertion order. Note that updating a key does not affect the order. Keys added after deletion are inserted at the end.

В версии 3.6 это появилось и в версии 3.7 это закрепилось официально.

Также по коду комменты:
Функция count_letters() у тебя сделана правильно.
Функция find_max() у тебя сделана неправильно.
Функция find_max() должна принимать словарь и не должна знать про существовании функции count_letters().
И нужно сделать третью функцию find_all_max(), например, которая принимает массив строк, использует эти две функции count_letters() и find_max() для получения самого частого символа и возвращает этот символ или кортеж этих символов (тут как раз и кроется зависимость от поставленной задачи).

py.user.next
В версии 3.6 это появилось и в версии 3.7 это закрепилось официально.

Да, нашла!

“Dictionaries preserve insertion order. Note that updating a key does not affect the order. Keys added after deletion are inserted at the end.” и “Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6.”
Как коварно вставили они эти два скромные абзаца!)
Спасибо огромное! Возьму себе за привычку детально изучать, что именно в новой версии появилось.

py.user.next
Надо сначала поставить задачу.

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

py.user.next
В первой задаче подразумевается, что такая буква одна. Во второй задаче подразумевается, что такая буква не одна. В третьей задаче подразумевается, что такая буква либо одна, либо не одна. То есть это как 1 & 0, 0 & 1, 1 & 1 - три абсолютно разных выражения. Есть ещё четвёртое выражение 0 & 0, которое вполне подходит под начальную формулировку, так как строка или строки в массиве строк может быть пустой или пустыми. То есть нет ни одной самой встречающейся буквы, ни нескольких.

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

Я неверно воспринимаю тренировочные задачи, как те, которые я могу решать в будущем, когда надо будет подумать, что программа должна корректно работать/завершаться в случае, если пользователь ей подсунет любые данные. Например, я тренировалась работать с API на парсинге работного сайта. Вроде как API должно выдавать понятные ответы по некоему шаблону, что в доках определен. А вот хрен там плавал. Оказывается, есть ошибки и исключения, которые в доках не описаны. Я такие кейсы смогла найти, тогда когда по факту получала нестандартные ответы на которых мой код ломался. Ну то есть через жопаболь. Это как то вообще нихрена не системный подход получается.

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

py.user.next
Поэтому мы ставим задачу очень точно.

А как мне поставить задачу очень точно, если в исходном условии не хватает данных?
Вариант, что приходит на ум: задать вопросы, но в случае книги это нихрена не работает.

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

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

py.user.next
Ну так вот, вот эти задачи похожи друг на друга, но они разные. И то, что они похожи друг на друга, не значит, что они должны каким-то образом обрабатываться одним чудесным кодом. Это ловушка. Так часто кажется новичкам “ну, не буду же я, как дурак, писать три кода, я напишу один, типа я умный”. И вот так они начинают делать что?

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

py.user.next
Поэтому мы ставим задачу очень точно. Потом для неё составляем алгоритм очень правильно. И потом для него пишем реализацию в виде кода очень красивого (код должен быть правильным, понятным и легко меняемым). Если задача поставлена, а алгоритм построить не можешь, то не надо строить что-то похожее на этот алгоритм, а потом менять задачу под это что-то похожее. Если алгоритм реализовать не можешь в коде, то не надо писать что-то похожее на реализацию этого кода, а потом алгоритм перестраивать под это что-то похожее.

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

Получается тупить я начала когда стала думать о проверке правильности кода и только тогда, я додумалась, что мне не всегда может придти на обработку “идеальный” (с точки зрения условий задачи) массив. То есть я уже выполнила все пункты разработки и только потом я подумала, что если бабушка - это дедушка. Поздновато как бы. Ладно тут микрозадачка, а если че-то побольше? Получается из-за того, что я башкой на берегу не подумала, делала полную хрень.

Может быть для таких тормозов, как я, стоит добавить еще пару пунктов? Ну, например:
1) ставим задачу очень точно
2) определяем достаточный набор тестов, которые подтвердят, что алгоритм правильно реализован для всех случаев
3) составляем алгоритм очень правильно
4) пишем реализацию в виде кода очень красивого
5) пишем и запускаем красивые тесты красивого кода

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

py.user.next
Также по коду комменты:

Спасибо огромное. Сегодня же все сяду и исправлю!

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

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

Докуда понимаешь задачу, там её и фиксируешь. Потом решаешь этот фиксированный вариант.

В 2008-м году я прорешал за восемь месяцев всю K&R2 (это книга по языку C). Насколько понимал задачу, на какую глубину, на ту и прорешивал. В прошлом году - в 2020-м - я её снова прорешивал. Я её перечитывал вообще. Ну, я вообще эти программы сделал все по-другому. Я углублялся, я делал то, что не просили в задачах, я обкладывал некоторые программы тестами (юнит-тестами), хотя юнит-тестирование было изобретено позже выхода этой книги и поэтому в книге оно не описано. И от этого перерешивания я получил свои плюсы, нашёл какие-то варианты, не исследованные мной ранее, и добавил их в свой опыт.

То есть книги не требуют от тебя, чтобы ты делала всё правильно. Книги дают тебе возможность научиться чему-то до какой-то степени. Если ты научиться не хочешь, то ты не прорешиваешь какие-то задачи, пропускаешь их. Но потом ты и не умеешь нихера делать. Ты хочешь уметь делать, но не хочешь прорешивать ничего. Так не бывает. Чуть-чуть порешаешь => чуть-чуть будешь уметь. А чтобы реальные проги писать, нужно нифига не чуть-чуть уметь. Нужно уметь до-хе-ра. Потому что реальная прога не будет за тобой сопли вытирать. Она просто не будет писаться и всё. И помогать тебе никто не будет. Никто тебе не придёт и не расскажет, что вот эту прогу можно написать вот так-то. Будешь одна сидеть просто и тупить в окно редактора.

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

Ты знаешь, я тебе скажу так: тренировочные задачи сложные, спору нет, они капец какие сложные и времени на них уходит дохера и больше; но реальные задачи (“задачи дикого мира” или “дикие задачи” я их называю, для которых пишутся “дикие проги”) гораздо сложнее тренировочных. Там нет никаких удобных вещей и там всегда дикий пиздец. Вот просто приходят данные тебе и они нихера не удобные. В учебных задачках - да, данные корректные всегда и всё такое. В диких задачах - дикие данные. Как правило, составлял их и подготавливал какой-нибудь дебил (какой-нибудь малолетний ушлёпок или бывший военный, решивший на ассемблере писать под сраку лет). Этот дебил не рассортировал их, а сбросил всё в один поток; всё это повреждённое, всё это неотформатированное, всё это с ошибками. И представь, к тебе такие данные приходят в какой-то ма-а-аленькой части твоей программы, в каком-то там компоненте-подкомпоненте, который не является ключевым совсем. Но тебе его нужно сделать, иначе вся программа работать без него не будет. Естественно, все эти данные тебе нужно разобрать, раскидать и всё это правильно применить и использовать. Так вот поможет тебе в этом только то, прорешивала ли ты эти десятки тупорылых учебных задач или не прорешивала. Нихера само не будет. Вот оно придёт вот такое и ты с этим будешь сидеть и смотреть на это. А программу-то дальше делать надо.

Ocean
Например, я тренировалась работать с API на парсинге работного сайта. Вроде как API должно выдавать понятные ответы по некоему шаблону, что в доках определен. А вот хрен там плавал.

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

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

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

Ocean
А как мне поставить задачу очень точно, если в исходном условии не хватает данных?
Вариант, что приходит на ум: задать вопросы, но в случае книги это нихрена не работает.

Все задачи поставлены точно уже. Они могут быть неразрешимими. Другое дело, что человек может тебе какую-то хуйню написать и ты бросишься её решать, а он тебе на решение скажет “а я не это имел в виду, там нужно другое, немножко другое”, ты будешь думать “ну, сука, ну ладно, давай другое посмотрим”. Он поставил тебе другую задачу, а не ту, которую ему надо решить. Для этого ты его переспрашиваешь сначала, всё уточняешь, чтобы не делать всё впустую. А иначе он так будет десять раз писать всякие типа задачи, которые ему надо решить, ты будешь так десять раз их делать, а нужна будет всё равно какая-то одиннадцатая.
Книги от тебя просто ничего не требуют. Пишешь, как хочешь. Главное, что остаётся с тобой после книги. Если ничего не остаётся, то время просто потеряно впустую. Книжка не пройдена. Всё пропущено типа “а, ну это я знаю” или “а, ну это я потом решу”.

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

Он попросил одну букву ему вернуть. Я ему вернул одну букву. Хотя экземпляр Counter() содержит их все. Я не стал заморачиваться. Он поставил задачу точно.

Другое дело, когда ты стала ему решать, у тебя возник вопрос “а что ему возвращать? вот это, вот это или вот это?”. Вот этот вопрос у тебя возник из-за неточной постановки задачи тобой для себя. То есть ты интерпретировала его точную задачу в неточную задачу для себя. И у тебя она раз и расслоилась на несколько задач. И я тебе предложил их решить все. Почему? Потому что ты не умеешь их решать. Там есть нюансы, неизвестные тебе, и открыть их можно для себя, только проделывая это. Я-то эти задачи в голове все пишу, а потом сравниваю их между собой, нахожу общие и различающиеся моменты, выделяю эти различающиеся моменты в подпрограммы и так далее, а потом формирую конечный вариант, который подойдёт этому клиенту. К тому же у меня в голове также остаётся ещё один вариант, который ему подойдёт, когда он скажет “а мне нужно не это, а немного другое”, но я его просто с головы не записываю сюда, а храню на случай, если он там проснётся вдруг и скажет эту свою заветную фразу, хорошо известную нам по опыту общения с такими ребятками. Но я-то их пишу в голове почему? Потому что в 2009-м, в 2010-м и других годах я их писал в блокноте, компилировал и выполнял. Мне не нужно пример 2 x 2 = 4 писать на бумажке, чтобы его решить, потому что я его могу в уме у себя написать. А вчерашнему первокласснику, только что пришедшему во второй класс, нужно это всё записывать в тетрадь. Он у себя в уме не может его написать и хранить там и видеть отчётливо. Ему сначала кучу таких примеров в тетради поназаписывать надо. И только к третьему классу он научится без записывания в тетради в уме это всё видеть.

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

Ты не ему пишешь, а пишешь себе. Чтобы самой для себя узнать, а что там скрывается. Ты их берёшь как три разные программы и каждую из них пишешь лучшим для неё способом. Они не получатся одинаковыми, потому что немножко различаются, они могут вообще полностью разными получиться. И вот в этом ключевой момент. Небольшая подгонка задачи в какой-то мелочи может полностью перечеркнуть уже написанный код. И ты начинаешь замечать, что где-то хочется пожертвовать памятью, потому что код неудобным получается, если её экономить. И вот это хочется нужно гасить, нужно бороться с ним. Это вредная хрень. Это вот как раз проявление программы. Программа тебе говорит “я не хочу писаться так, напиши меня попроще, ты сама отдохнёшь и мне приятно будет”, а ты видишь, что это просто непослушная программка пытается тебя наколоть. И ты берёшь её и говоришь “нет, сука! ты будешь память есть минимально! это я решаю, какая ты будешь”. Вот в этом будет успех. Если ты будешь ходить за программками и будешь просить их, чтобы они написались, хлюздопёрить короче, то они будут тебя всегда в тупики заводить. У тебя в итоге ни одной программы не будет, потому что ни одна из них не получится до конца. А когда дело дойдёт до каких-то массивных программ, там даже куски какие-то их получатся не будут. Мелкие кусочки даже будут тебе такое фуфло толкать - “подгони нас туда-то, чтобы мы были поудобнее и тебе хорошо и нам хорошо”. Это всё путь к провалу.

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

Вот это тоже точная постановка задачи
Точная не значит сведённая к чему-то одному, зауженная. Точная - значит, определённая. Как в математике бесконечность - это точное понятие, потому что оно определённое, у него границы определены. Да, мы не знаем, что она значит внутри, но мы знаем точно, где она начинается и заканчивается. Вот здесь она есть, а вот здесь её уже нет.

Ocean
Получается тупить я начала когда стала думать о проверке правильности кода и только тогда, я додумалась, что мне не всегда может придти на обработку “идеальный” (с точки зрения условий задачи) массив. То есть я уже выполнила все пункты разработки и только потом я подумала, что если бабушка - это дедушка. Поздновато как бы. Ладно тут микрозадачка, а если че-то побольше? Получается из-за того, что я башкой на берегу не подумала, делала полную хрень.

Да, без точной постановки задачи не стоит начинать её решать. Я сейчас начну решать, а в процессе пойму, что мне надо решить, - это неправильный процесс. Это признак того, что нет задачи. Ну, ты будешь блуждать и всё. Закончишь где-нибудь в полном бардаке. В результате код выкинешь. В худшем случае будешь ещё пропихивать это со словами “да это хороший код, вы просто не понимаете”. Так делают часто всякие ушлепаны великовозрастные. Напишут дерьмо какое-нибудь и пропихивают его всем. В грудь себя колотит “да я! да я программирую двадцать/тридцать/пятьдесят лет! да я знаю, как писать!”.

Ocean
Может быть для таких тормозов, как я, стоит добавить еще пару пунктов? Ну, например:
1) ставим задачу очень точно
2) определяем достаточный набор тестов, которые подтвердят, что алгоритм правильно реализован для всех случаев
3) составляем алгоритм очень правильно
4) пишем реализацию в виде кода очень красивого
5) пишем и запускаем красивые тесты красивого кода

Хорошо, да. Но не всегда есть время на тесты. Часто ты разрабатываешь макет, чтобы понять, нужен ли он тебе (какой-то путь, который реализован в этом макете). Если ты будешь писать для него тесты, на это уйдёт время. Бывает много времени уходит. А потом ты его разрабатываешь и на середине понимаешь, что он не нужен тебе. Или там в конце понимаешь, что он не нужен тебе. И вот у тебя тесты есть разработанные, на них время ушло, а они оказались тебе нафиг не нужны. Следовательно, быстрее можно было сделать макет без тестов, увидеть, что он нужен, сделать только тогда тесты и потом этим пользоваться, разрабатывать дальше эту идею итеративно. Или, следовательно, быстрее можно было сделать макет без тестов, увидеть, что он нафиг не нужен, не делать никакие тесты и просто выкинуть этот макет.
Так что тесты нужны не всегда. Иногда они тратят время впустую.

Отредактировано py.user.next (Май 7, 2021 02:09:31)