Dictionary для этой здачи совсем не подходит по логике. Есть более простая структура данных, которые просто идеально подходит к данной задаче - set https://www.programiz.com/swift-programming/sets. Под капотом обычно тоже самое что в словаре, только без значений.
> Обозначение Big O нотация (или просто Big O) — это способ оценки относительной производительности структуры данных или алгоритма, обычно по двум осям: времени и пространству.
Это о сложности, а о времени. Да, некоторые закономерности прослеживаются. Но вот контр пример, возьмем такую задачу: нужно нам обойти ровно миллион ссылок. Как не крути это долго. Раз мы знаем точное количество ссылок, значит время константное O(1), алгоритм выполнится за фиксированное количество шагов. Это не очень полезно, с точки зрения оценки алгоритма, но математика она такая :)
Мне нравится, как вопрос сложности разобран в книге Cracking the code interview.
Только ИТ это не только программисты, это и менеджеры и тестировщики, и прочие професии.
Разные професии, разные требования. Топовые программисты без требований сделают продукт хуже чем средненькие которые делают то, что нужно пользователям этого продукта.
Я не пользовался тем гитом который получился через неделю, но слышал, что пока оберток на перле типа git commit и git push не написали, то он был достаточно сложным и неудобным инструментом для ипользования.
Я не верю, что он написал гит за неделю. За неделю он написал код. В тот момент гит решал две проблемы, несовершенство всех существующих систем контроля версий и то, что у ядра не было возможности пользоваться системой контроля версий. Вторая послужила катализатором. Я думаю, что к этому моменту у него в голове уже было понимание какие фичи ему нужны. Так что, возможно, он гонял в голове эти идеи месяцев 5 по кругу, а потом когда приспичило взял и сделал.
На ассемблере можно написать всё, да, но то что на самом деле привнесли первые языки программирования -- новый способ мыслить о программах. Именно привнесли, а не ограничили.
Тут смешиваются два понятия: Возможность делать и способ мыслить. Да парадигмы это расширения способа мыслить, но при этом это ограничения возможности делать.
и их тестировать удобно можно и нужно, и часто без DI.
Для меня самый простой вид Dependency Injection это передача аргументов в функцию/конструктор. В таком контексте тесты без DI это редкость, и я бы их скорее компонентными или модульными назвал.
Одноразовый это всякие гуи, хендлеры взаимодействия и прочая бизнес логика которая вызывается из одного места для одной цели. Как правило у такого кода много зависимостей (от данных, от вью, особенностей местного законодательства, от чёрта лысого), нет смысла в рефакторинге, нет внятной спецификации.
У меня другая философия, для меня ядро системы это то, почему мы вообще затеяли проект: та самая бизнес логика. Всё остальное это адаптеры: обработчики сообщений, клиенты к другим сервисам, подключения к базам данных, библиотеки, утилиты. Все они имею смысл только в конексте бизнес логики.
В проекте должа быть изюминка. То, чем он отличается от другого или другими словами то почему покупка другого не решит проблему.
Именно эти бизнес требования и стоит покрывать тестами в первую очередь. Программисты не хотят разбираться с бизнесом и размазывают эту логику по хэндлерам, базам данных, и прочим библиотекам. Что делает код запутанным и плохо тестируемым.
Если код не писать с прицелом на тесты, то тесты будет сложно писать. В итоге они будут объёмными, сложными хрупкими и от них откажутся, как от неэфективных.
Я бы такой вообще не ревьювил. Это бесполезно. Собралось и совсем всё не разъехалось - можно мерджить. А уже потом небольшими кусочками доводить до ума и красоты.
Такие вещи надо делать быстро. Если это затянуть и не остановить работы в основной ветке, то будет очень больно.
Можно использовать кодревью для контроля, но это далеко не едеинственное его применение. Код ревью из под палки будет неэфективным.
пробовать время от времени протестировать в уме, как будет выполняться код при тех или иных значениях переменных
Классный метод. Но есть ограничение по сложности и воспроизводимости. После того как я открыл для себя прекрасный мир тестирования, то понял что накидать юнитов быстрее, и изменения в коде не требуют усилий по перепроверке.
И в 99% случаев этот совет статического анализатора не имеет никакого смысла
Отключите это правило. Зачем тратить на это время?
Наработающие правила очень мешают при работе в команде, те кто еще не прониклись плюсами статического анализа спотыкаются на таких вещах и в результате весь код утыкан комментами для анализатора и появляется мнение: статический анализ зло.
> на качество это влияет не сильно
Код ревью это еще и обмен опытом и знаниями о проекте. Разница между "что они тут наворатили" и "я смотрел этот код" огромна.
То есть когда тебе нужно что-то сделать в коде, а его автор не доступен, ты можешь быстро включиться. Когда нет кодревью то вполне реален вариант: автор может поправить за 5 минут, а остальные за 2 дня.
Качество понятие относительное. То что хорошо для одиночки может быть плохо для команды.
Я как-то зарефакторил адапторы написанные на 80% мной из кучи функций в иерархию классов. Когда ученый, сделал нормальный адаптор вообще не задавая мне вопросов, я понял, что получилось нормально. Со старой версией он бы самостоятельно не справился. Старая версия писалась с внимательным код ревью.
Разбивайте изменения. Не мешайте много фич в один реквест. Не машайте рефакторинг и изменения.
Для себя выбрал стратегию: делаю все вперемешку в одной ветке, и в процессе работы часть изменений выношу в отдельные ветки и отправляю её на ревью. Изменения не большие ревьювятся быстро и качественно. В этом мне помогают мои друзья: merge, rebase, cherry-pick, `checkout <branch> -- file`, `cp` . Это требует времени, можно запутаться, но это быстрей чем ждать ревью на гиганские изменения.
Например ревью на +-200 строк на переименование переменной делаются со скоростью скролла и качественно. А вот если среди этих 200 будет еще пара фиксов, то будет либо не быстро (нужно понимать где фикс, а где рефакторинг), либо не качетственно (фиксы не заметят).
Прикрутить автоматизацию: линтеры форматеры. Это вешается на прекоммит хуки и CI (если есть). Насроить всё это для питона оказалось достаточно затратно, но зато теперь таскаю это с собой.
На больших объемах кода тесты сильно ускоряют процесс. Но тут нюансов море.
Само-ревью. Пишешь код и перед тем как его отправить смотришь на него самостоятельно. Много мелких недочётов всплывает. Чем лучше память тем долше должен быть перерыв между написанием и ревью. Иначе будет чтение не с экрана, а из головы.
Я еще используею инкрементальный коммит в гите ( git add -i > 5: patch > * > yyy). В отличии от UI вариантов это не даёт проскролить в конец. Но тут стоит учесть, что я часто комичу.
Для Питона, есть небольшая табличка со сложностью операций над основными структурами данных. https://wiki.python.org/moin/TimeComplexity
Что-то такое должно быть и для остальных языков.
Сортировка это слишком абстрактно. Quick sort да, merge sort нет.
Dictionary для этой здачи совсем не подходит по логике. Есть более простая структура данных, которые просто идеально подходит к данной задаче - set https://www.programiz.com/swift-programming/sets. Под капотом обычно тоже самое что в словаре, только без значений.
> Обозначение Big O нотация (или просто Big O) — это способ оценки относительной производительности структуры данных или алгоритма, обычно по двум осям: времени и пространству.
Это о сложности, а о времени. Да, некоторые закономерности прослеживаются.
Но вот контр пример, возьмем такую задачу: нужно нам обойти ровно миллион ссылок. Как не крути это долго. Раз мы знаем точное количество ссылок, значит время константное O(1), алгоритм выполнится за фиксированное количество шагов. Это не очень полезно, с точки зрения оценки алгоритма, но математика она такая :)
Мне нравится, как вопрос сложности разобран в книге Cracking the code interview.
Только ИТ это не только программисты, это и менеджеры и тестировщики, и прочие професии.
Разные професии, разные требования. Топовые программисты без требований сделают продукт хуже чем средненькие которые делают то, что нужно пользователям этого продукта.
>Торвальдс вон гит за неделю написал
Я не пользовался тем гитом который получился через неделю, но слышал, что пока оберток на перле типа git commit и git push не написали, то он был достаточно сложным и неудобным инструментом для ипользования.
Я не верю, что он написал гит за неделю. За неделю он написал код. В тот момент гит решал две проблемы, несовершенство всех существующих систем контроля версий и то, что у ядра не было возможности пользоваться системой контроля версий. Вторая послужила катализатором. Я думаю, что к этому моменту у него в голове уже было понимание какие фичи ему нужны. Так что, возможно, он гонял в голове эти идеи месяцев 5 по кругу, а потом когда приспичило взял и сделал.
Всегда считал, что для этого используются конечные автоматы.
Код с конечными автоматами получается хорошо структуированным и легко читается.
Я тоже прекрасно обходился, пока не научился писать простые юниттесты. После этого они стали нужны и полезны намного чаще.
Тут смешиваются два понятия: Возможность делать и способ мыслить. Да парадигмы это расширения способа мыслить, но при этом это ограничения возможности делать.
Для меня самый простой вид Dependency Injection это передача аргументов в функцию/конструктор. В таком контексте тесты без DI это редкость, и я бы их скорее компонентными или модульными назвал.
У меня другая философия, для меня ядро системы это то, почему мы вообще затеяли проект: та самая бизнес логика. Всё остальное это адаптеры: обработчики сообщений, клиенты к другим сервисам, подключения к базам данных, библиотеки, утилиты. Все они имею смысл только в конексте бизнес логики.
В проекте должа быть изюминка. То, чем он отличается от другого или другими словами то почему покупка другого не решит проблему.
Именно эти бизнес требования и стоит покрывать тестами в первую очередь. Программисты не хотят разбираться с бизнесом и размазывают эту логику по хэндлерам, базам данных, и прочим библиотекам. Что делает код запутанным и плохо тестируемым.
Если код не писать с прицелом на тесты, то тесты будет сложно писать. В итоге они будут объёмными, сложными хрупкими и от них откажутся, как от неэфективных.
1) Устанавливаем библиотеки 2) Рисуем остаток совы.
Приватный ключик из репозитория скачал, под какой лесницей каморка?
Один реквест на 1000? Не страшно.
Я бы такой вообще не ревьювил. Это бесполезно. Собралось и совсем всё не разъехалось - можно мерджить. А уже потом небольшими кусочками доводить до ума и красоты.
Такие вещи надо делать быстро. Если это затянуть и не остановить работы в основной ветке, то будет очень больно.
Можно использовать кодревью для контроля, но это далеко не едеинственное его применение.
Код ревью из под палки будет неэфективным.
Классный метод. Но есть ограничение по сложности и воспроизводимости. После того как я открыл для себя прекрасный мир тестирования, то понял что накидать юнитов быстрее, и изменения в коде не требуют усилий по перепроверке.
Исключения это нормально. Как только начинаешь осознанно разбивать изменения, то их становится меньше.
Отключите это правило. Зачем тратить на это время?
Наработающие правила очень мешают при работе в команде, те кто еще не прониклись плюсами статического анализа спотыкаются на таких вещах и в результате весь код утыкан комментами для анализатора и появляется мнение: статический анализ зло.
> на качество это влияет не сильно
Код ревью это еще и обмен опытом и знаниями о проекте. Разница между "что они тут наворатили" и "я смотрел этот код" огромна.
То есть когда тебе нужно что-то сделать в коде, а его автор не доступен, ты можешь быстро включиться. Когда нет кодревью то вполне реален вариант: автор может поправить за 5 минут, а остальные за 2 дня.
Качество понятие относительное. То что хорошо для одиночки может быть плохо для команды.
Я как-то зарефакторил адапторы написанные на 80% мной из кучи функций в иерархию классов. Когда ученый, сделал нормальный адаптор вообще не задавая мне вопросов, я понял, что получилось нормально. Со старой версией он бы самостоятельно не справился. Старая версия писалась с внимательным код ревью.
Я бы ограничивал по размеру.
Время растёт не линейно с количеством строк кода.
Разбивайте изменения. Не мешайте много фич в один реквест. Не машайте рефакторинг и изменения.
Для себя выбрал стратегию: делаю все вперемешку в одной ветке, и в процессе работы часть изменений выношу в отдельные ветки и отправляю её на ревью. Изменения не большие ревьювятся быстро и качественно. В этом мне помогают мои друзья:
merge,rebase,cherry-pick, `checkout <branch> -- file`, `cp` . Это требует времени, можно запутаться, но это быстрей чем ждать ревью на гиганские изменения.Например ревью на +-200 строк на переименование переменной делаются со скоростью скролла и качественно. А вот если среди этих 200 будет еще пара фиксов, то будет либо не быстро (нужно понимать где фикс, а где рефакторинг), либо не качетственно (фиксы не заметят).
Прикрутить автоматизацию: линтеры форматеры. Это вешается на прекоммит хуки и CI (если есть). Насроить всё это для питона оказалось достаточно затратно, но зато теперь таскаю это с собой.
На больших объемах кода тесты сильно ускоряют процесс. Но тут нюансов море.
Само-ревью. Пишешь код и перед тем как его отправить смотришь на него самостоятельно. Много мелких недочётов всплывает. Чем лучше память тем долше должен быть перерыв между написанием и ревью. Иначе будет чтение не с экрана, а из головы.
Я еще используею инкрементальный коммит в гите ( git add -i > 5: patch > * > yyy). В отличии от UI вариантов это не даёт проскролить в конец. Но тут стоит учесть, что я часто комичу.