#php #архитектура #проектирование #code_style
Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
Закрыт 4 года назад.
О себе: кодер на пхп, делаю разные парсилки, чекалки, в т.ч. с капчей, обходом разного
рода защит.
Мне очень не нравится стиль, как я пишу код. Например, задача - многопоточно соединяться
с разными хостами, используя при этом прокси, для каждого хоста собственное (учитывая
что прокси может сдохнуть), затем парсить результат, и зависимо от него, передавать
выполнение дальнейшим блокам кода: парсить следующую страницу, поставить на ожидание
ввода капчи и т.д. При этом должен быть интервал в 10 секунд между запросами к одному
хосту, причем когда один хост ожидает, выполняется другая работа.
Раньше я делал такие конвееры многократными структурами if/elseif/else, switch/case,
goto, чтобы выполнение кода циклически перебрасывалось из одного блока в другой. Столкнулся
с большой сложностью - читабельность и понимаемость кода из-за многократной вложенности
конструкций, сложность отладки, избыточное количество переменных, в которых запутываешься.
В итоге кодинг превращается в настоящую головоломку, и каждый новый проект вызывает
FFFFUUUUU-реакцию, когда приходится это снова повторять.
Сейчас занялся очередным таким проектом, и понимаю, что я неправильно делаю, и можно
проще, независимо от уровня сложности, просто я не знаю как. Подскажите, что я не так
делаю, и как делать правильно?
Ответы
Ответ 1
Мини-ремарка:
Лол, что не так с вопросом? Хоть бы уточнили
Вы не поверите, но описанные в вопросе проблемы, с которыми вы столкнулись, и есть
та огромная разница между хорошим опытным программистом и новичком. Каким вы себе представляете
ответ на такой "не маленький" вопрос? :)
Теперь попытка краткого ответа:
Правильно ставьте задачу. Это действительно половина ответа.
Производите декомпозицию, т.е. разбиение задачи на небольшие
подзадачи. Меньше задача - меньше переменных в голове, яснее цель,
проще и короче решение, меньше число вариантов решения, проще
сосредоточиться и/или переключить контекст в голове, если что-то вас
отвлекло.
Думайте не в терминах языка программирования (if+else, do+while и
т.д.), а в терминах той области, в которой вы решаете задачу. Не в
терминах типов хранения/представления данных (int, string и т.д.), а
в терминах объектов, фигурирующих в текущей области знания. Не вы
"перемещаете" и "изменяете" данные, а объекты как бы сами живут и
меняются, исполняя некоторые обязательства, взаимодействуют друг с
другом.
Отнеситесь серьезно к форматированию и организации кода. Более того,
правильно примененная декомпозиция задачи не оставит вам шансов
писать процедуры/функции/методы, которые не умещаются по высоте на
одной странице монитора.
Но позаботьтесь так же об адекватном именовании абсолютно всего. Код
должен быть таким, чтобы практически любые комментарии были излишни
(кроме достаточно глобальных, являющихся документацией к
классу/модулю, или очень специфических). Найдите середину между
одно-двухбуквенными названиями переменных и
оченьДлиннымиНазваниямиКоторыеЧитатьУжеНуСовсемНеудобно.
Помните, что многопоточку дебажить в принципе сложно. Поэтому очень
важно максимально устранить в коде остальной "дискомфорт".
Upd. Шаблонов и концепций придумано много - по формулировке задачи не очевидно, что
лучше подойдет (да и я не эксперт, если честно).
Я бы старался максимально избегать многопоточки (не асинхронности) - очень часто
профит от ускорения не перекрывает затрат на сложность разработки и поддержки.
В простейшем случае, вы разбиваете вашу задачу на независимые этапы, для каждого
из которых реализуется свой обработчик. Позаботьтесь о том, чтобы обращение к общим
данным было потокобезопасным и его было как можно меньше - чем более независимым будет
обработчик каждого этапа, тем меньшей головной болью будет одновременный запуск нескольких
обработчиков. Обозначьте зависимости и требуемые входные данные для каждого типа обработчиков,
а также данные на выходе.
После этого достаточно лишь организовать механизм сохранения состояния и общения
между обработчиками соседних этапов (т.е. переход от этапа к следующему) - это могут
быть очереди, шины, сокеты, обычные колбэки событий и т.п. Подумайте над тем, кто будет
инициировать переход между состояниями (push-based, pull-based, centralized).
На русском гуглить наверное будет очень сложно (у меня сходу довольно скудные результаты
получились). Теги: multithreading pattern, asynchronous pattern, event-driven programming,
task-based asynchronous pattern, немного про разницу между асинхронностью и многопоточностью.
