lekovr / getpages Goto Github PK

последовательность операций: чтение Body, обработка Body, закрытие Body, слияние ошибок чтения и обработки Body в одну общую, обработка результирующей ошибки – таким образом будет непонятен источник возникновения ошибки + закрытие Body было бы логичнее делать в defer

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

resp.Body копируется в io.Discard и читается кол-во скопированных байт, тогда как можно было просто прочитать размер контента из resp.ContentLength

массив contextAttrs объявляется длиной 2, но ёмкостью 3, хотя, всегда содержит в себе ровно два элемента.

запускается несколько воркеров, каждый в своей горутине, все под waitGroup.
Далее, в главной горутине читается файл с url-ми, каждая строка отправляется в канал, который слушают воркеры. Воркеры завершают свою работу только когда канал с url-ми закрывается. И в самом конце главная горутина блокируется wg.Wait()
Но, т.к. ни один воркер не закончит свою работу ранее, чем главная горутина закроет канал, то и использование WaitGroup тут излишне.

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

воркеры читают из канала url-ов в бесконечном цикле, проверяя внутри, не закрыт ли канал. Работает, но лучше было бы использовать for ... range

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