Моя производительность снижается по мере того, как проект становится больше. Как повысить производительность по мере увеличения размера проекта? [закрыто]
Изначально я начал с небольшого проекта, редактируя php-файлы и тому подобное в notepad++. Раньше было легко придумать функцию и добавить ее в проект в виде отдельного файла. По мере того как проект становился больше, моя производительность начала снижаться, потому что я не мог вспомнить все функции, которые я сделал, и где они хранились и т.д... Затем я добавил IDE (PhpED) и SVN, а затем заметил значительный рост производительности.
Я обнаружил, что снова снижаю производительность (потому что все снова становится слишком сложным).Проект вырос примерно с 20 или около того файлов - > 100 файлов, и мне становится трудно управлять всем в моей голове (даже с помощью IDE). Мне интересно, есть ли у людей советы о том, что я могу сделать, чтобы снова повысить производительность. (Каков следующий уровень? если таковой имеется)
Какие-либо программные инструменты или советы о том, как подойти к разработке программ/хотя бы упростить визуализацию?
Я знаю, что серебряной пули не существует, но любые идеи были бы полезный.
Например, вы, ребята, используете определенные инструменты, чтобы пережить день, помимо IDE/SVN. Кроме того, вы пишете код определенным образом, чтобы это не было проблемой в будущем? (подробности, пожалуйста).
23 answers
Бесспорный факт заключается в том, что эффективность разработчиков будет снижаться вместе с размером проекта. Это было известно десятилетиями. Есть методы, которые могут помочь, но они требуют некоторой дисциплины.
Лучшее решение - перейти на более высокий уровень абстракции. Напишите процедуры, которые будут служить строительными блоками, которые вы можете использовать, как если бы они были стандартной библиотекой или языковыми конструкциями. Документируйте их интерфейсы и программируйте только на интерфейсы. Если вы когда-нибудь почувствуете, что вам нужно знать как реализуется процедура, над которой вы не работаете, вы либо используете ее неправильно, либо недостаточно документировали интерфейс. Не спешите добавлять что-либо в интерфейс, медленнее удаляйте что-либо и помните, что изменение его элементов может сильно вас укусить.
Местность - ваш друг. Чем больше вы можете сосредоточиться на небольшой области, тем лучше для вас. Этому помогает программирование интерфейсов. Поддержание последовательности процедур помогает этому, так что процедуры выполняют одну вещь за раз.
Объект ориентация очень полезна, так как она способствует двум вышеперечисленным. Он способствует инкапсуляции и кодированию интерфейса, а также группирует связанные фрагменты кода вместе.
Разработка на основе тестов полезна для внедрения программирования в интерфейс. Пишите тесты на основе интерфейса, а не на основе реализации. Это имеет приятный побочный эффект, заключающийся в том, что сами наборы тестов помогают определить интерфейс. Если это не проверяется, вы на это не рассчитываете. Убедитесь, что вы можете запускать наборы тестов легко, и войди в привычку.
Потребуется рефакторинг. Планируйте это, особенно когда что-то меняете. Вам нужен чистый код. Более того, вы неизбежно обнаружите, что разместили функциональность не в том месте.
Помните также, что ничто из этого не решит проблему полностью. Крупные программные проекты по своей сути сложны.
Нарисуйте и/или запишите это. Если вы говорите, что это "все в вашей голове", тогда отвлекитесь на некоторое время от кодирования и документируйте свою работу. Это может включать абзацы, объясняющие, почему вы что-то сделали.
Диаграммы и другие визуальные элементы также помогут вам упорядочить его.
Я обнаружил, что некоторые программисты игнорируют нетехнические факторы в проектах. Это особенно верно для одиноких разработчиков, у которых нет структуры группы, которая могла бы их направлять. Ваша работа - это больше, чем просто код и вы должны рассмотреть все аспекты вашего процесса.
Никогда не гордитесь редактированием кода в блокноте! IDE экономит ваше время и повышает вашу эффективность. Когда проект становится большим, вы должны позаботиться об управлении проектом и придерживаться эффективного "Шаблона процесса", такого как RUP (Rational Unified Process), EUP или OOSP. Ваш SVN является частью SCM. Конечно, существует гораздо больше видов деятельности, определенных в Шаблоне.Что касается проблемы управления файлами, вы можете разделить их на разные пакеты и сохранить в разных местах. Если вы не имеете никакого представления о "Разработке программного обеспечения", вы можете обратиться к некоторым книгам, написанным Скоттом У.Эмблером или другими о SE (Разработка программного обеспечения). Помните, программное обеспечение - это гораздо больше, чем КОД!
Хороший разработчик знает, что в разработке есть нечто большее, чем программирование. Отличный разработчик знает, что разработка - это нечто большее, чем просто разработка. Скотт У. Эмблер
Разработка на основе тестирования может быть вам полезна.
Сначала создайте свои тесты, а затем напишите код для прохождения этих тестов.
Когда вы добавляете/изменяете какой-либо код, у вас есть набор тестов регрессии, который вы можете запустить, чтобы убедиться, что вы ничего не сломали. По моему опыту, это экономит массу времени, особенно по мере роста сложности и размера приложения.
Производительность на больших кодовых базах зависит не столько от инструментов, сколько от кода, который вы пишете. Потратьте время на улучшение качества вашего кода, как нового, так и существующего. Да, это замедляет вас в краткосрочной перспективе, но позволяет вам поддерживать свой темп с течением времени.
Это применимо независимо от ваших инструментов или языка. Лучшие инструменты в мире не помогут тому, кто хочет устроить беспорядок. Для начала я бы запомнил несколько простых идей:
- Качество кода - это инвестиции в будущую производительность.
- Если ваша интуиция подсказывает вам, что код плохой, сложный, неправильный, уродливый... вероятно, так и есть, исправьте это.
- Прекратите писать плохой код сейчас, а не завтра.
Для получения более подробной информации о том, как создавать отличный код, я предлагаю просмотреть здесь.
Раньше я работал над проектом, в котором было примерно миллион строк кода (C#, C++), и он все еще растет.
1) Для управления такой базой кода структура папок архива svn была создана таким образом, чтобы она имитировала различные архитектурные слои нашего продукта. Таким образом, нам стало легче ориентироваться в архиве.
2) Также у нас был свой собственный инструмент сборки. Когда у вас огромная база кода, может оказаться невозможным создать все в любое время, когда вы захотите чтобы протестировать небольшую функцию. Наш пользовательский инструмент сборки имел множество опций, которые могли создавать архив с любой степенью детализации.
3) Обычно я наблюдал, что если вы правильно используете общие функции/помощников, создание новых вещей поверх этого становится проще, а также позволяет избежать раздувания кода.
4) Создайте вики-страницу, если число разработчиков, работающих над вашим проектом, больше. Вики-документация проста, удобна для поиска и полезна, если все сделано правильно.
Это все, что я могу придумать, верно сейчас. Надеюсь, это поможет
- Рефакторинг после каждой итерации - поддерживает чистую базу кода
- Разрыв зависимостей - помогает кодовой базе быть простой для понимания
- Наличие автоматизированных модульных тестов и тестовой проводки - сокращает время выполнения новой функции
- Обновление документации и возможность отслеживания после каждой итерации - помогает понять код.
Как насчет этого распространяющегося мифа о том, что ООП спасет положение? Если это правда, то почему ребята из Linux/Ядра все еще еженедельно выпускают новые версии? Другими словами, все ли программисты ASM/C обречены на сложность "Привет, мир"?
Не уверен, о чем именно вы просите. Я имею в виду работу над проблемами до и после их возникновения:
Если у вас много файлов и локаций, просто уменьшите и реорганизуйте их. Например, путем строительства или использования твердых пород фреймворки для определенных задач (PDO вместо mysql()). Другими словами, не повторяйтесь. Короткие, запоминающиеся, похожие имена функций: get_user_ID(), get_task_ID(), db_query()....
Является ли общение в группе проблемой? Попробуйте вики, попробуйте внутренние мгновенные сообщения, попробуйте использовать больше комментариев, спросите группу, что им не нравится и что они хотят улучшить. Это полностью зависит от проекта.
Если вы работаете в группе, не будьте повсюду. Работайте над своими деталями и улучшайте их. Тот экономит время, необходимое для того, чтобы проникнуться мышлением других программистов. Одно изменение за раз. Не открывайте 200 файлов и не редактируйте совершенно несвязанные вещи.
Автоматизируйте и ускорьте все, если это возможно: развертывание, управление версиями, документацию, тесты.
Большие проекты - это большие проекты, и их всегда трудно полностью понять. ПОЦЕЛУЙ - это хорошо, но, по моему опыту, иногда помогает просто разбить вещь на независимо работающие компоненты, взаимодействующие через XML, языковые интерфейсы и т.д... Короче говоря: Сделайте много маленьких проектов из большого.
Я веду личный список дел/запоминаний, как "myname.todo.txt ".
Быстрое развертывание обязательно! Например, установите локальную лампу/xampp и непосредственно просмотрите ваши изменения.
Моя первая мысль заключается в том, что вам нужно все записать. Ваш комментарий о "это все в моей голове" беспокоит меня, что
- В конце концов вы забудете что-то действительно важное и потратите время на выяснение или восстановление чего-то, потому что вы не можете вспомнить.
- Будущие программисты проекта возненавидят вас за то, что вы ничего не документируете.
Я нахожу, что вики, даже если я единственный пользователь, феноменально помогает упорядочить мои мысли. То процесс редактирования прост и быстр, что позволяет мне буквально выгружать содержимое моего мозга в цифровой носитель с возможностью поиска.
Неважно, какую вики вы выберете, просто потратьте некоторое время на то, чтобы действительно изучить синтаксис, чтобы вы не постоянно переключали свое внимание на форматирование.
Затем просто сядьте и сбросьте.
Как только у вас появится материал на странице, вы можете начать перестраивать свои мысли, и вам будет легче увидеть всю архитектуру системы с высокого уровня, когда это прямо перед вами.
Я также нашел множество умных и интересных способов исправить свою архитектуру, просто представив все это передо мной в совершенно другой среде.
Как говорит Стив Макконнел, главная проблема в программировании - это управление сложностью.
У вас есть несколько способов управлять этим:
- Используя правильные инструменты (хорошие IDE, VCS и т. Д.), Вы можете управлять более высоким уровнем сложности, Но по мере увеличения сложности рано или поздно вы не сможете им управлять.
- Используя правильные методы (ООП, TDD и т.д.), вы можете снизить сложность, но вскоре она будет неуклонно возрастать.
- Использование правильных подходов (рефакторинг, модульное тестирование и т. Д.) И большая дисциплина вы можете снизить темпы увеличения сложности - но, тем не менее, она будет увеличиваться.
- Использование понятных интерфейсов может позволить разделить проект между большим количеством людей, каждому из которых придется справляться с меньшей сложностью, но по мере роста команды сложность командных коммуникаций будет возрастать все больше.
По моему личному мнению, первые два пункта (инструменты и методы) действительно хороши, но не то, что действительно меняется. Например, у меня есть коллеги в моей команде, которые используют старые редакторы и почти так же продуктивны, как коллеги, использующие Eclipse.
С другой стороны, два других момента помогут гораздо больше: дисциплина, хороший дизайн и рефакторинг помогут поддерживать сложность как можно ниже, а хорошая командная работа позволяет решать более крупные проекты, которые сами по себе были бы действительно слишком сложными.
Однако, как вы уже отмечали, серебряной пули не существует. В конце концов, сложность любого успешного программного обеспечения возрастает до такой степени, что его обслуживание может стать настолько дорогостоящим, что потребуется полностью новое поколение.
И это жизнь в программном обеспечении:-)
Я думаю, вам следует прочитать классическую книгу Брукса " Мифическое человеко-месячное юбилейное издание ". Хотя оригинальная книга описывает работу, проделанную в середине 60-х годов, основополагающие истины по-прежнему точны. И более поздняя статья " Без серебряной пули" (которая включена в юбилейное издание) очень проницательна.
Короче говоря, в книге объясняется, что по мере того, как программы становятся больше, ими становится сложнее управлять (понимать, поддерживать, развивать), потому что их становится больше есть о чем подумать. Почти все методы проектирования и программирования используются для того, чтобы попытаться ограничить эти проблемы, но проблемы возникают по мере того, как программное обеспечение становится больше (это "суть" части подзаголовка "Нет серебряной пули").
Заведите привычку регулярно изучать свой код и искать способы устранить повторение (т.Е. Применять принцип "Не повторяйся" или "СУХОЙ") и будьте безжалостны в рефакторинге этого повторения. Чем больше вы помещаете общие фрагменты кода в повторно используемые методы и классы, тем проще писать новый код и тем больше преимуществ вы получаете в решении проблемы.
Использование хорошей IDE поможет вам найти общие черты и применить рефакторинги.
Также ищите платформы с открытым исходным кодом и инструменты , которые автоматизируют аспекты вашего программного обеспечения. Их использование - это массовое применение СУХОГО принципа.
Нетипизированные и процедурные языки ломаются в больших проектах. Так было всегда, вот почему был создан OO, и такие вещи, как развязка и инкапсуляция, считаются хорошими методологиями проектирования.
Конечно, сначала используйте oo-программирование и наследование. Затем я бы использовал фреймворк, такой как code igniter для запуска, добавил модуль для макета (чтобы у вас был согласованный макет сайта) и, возможно, несколько других, смысл в том, чтобы не тратить слишком много времени на общие вещи. К сожалению, миграции для CI невелики, но они существуют, поэтому что-то в этом роде было бы полезно для работы с бд. С их помощью вы снова сможете повысить свою производительность, так как не будете тратить время на мелочи.
Вещь с более крупными проектами дело в том, что они имеют множество аспектов, и чем больше их существует, тем больше времени вам нужно потратить на их учет.
Надеюсь, это поможет.
Использование фреймворка PHP MVC значительно сократит объем кода, который вам нужно отслеживать. Он позаботится о многих вещах, которые вам, вероятно, пришлось написать самостоятельно, таких как сеанс, уровень базы данных и т.д. Используя фреймворк, он поможет вам логически организовать ваши файлы.
Я обнаружил, что разработка на основе тестов (TDD) /разработка на основе поведения (BDD) помогает мне поддерживать порядок по мере их увеличения. Даже если вы просто пишете модульные тесты, оставляя в стороне функциональные, интеграционные и другие тесты, это само по себе может оказать огромную помощь. По мере того как ваша кодовая база превращается в неуклюжее, неуклюжее Болото, ваши тесты будут поддерживать ее в более или менее правильном направлении и не позволят ей споткнуться о камень, упасть лицом в грязь и тонет, потому что слишком тяжело вставать.
Если вы напишете достаточно тестов, и они хорошо продуманы, они могут сделать так, чтобы вы могли вносить изменения и сразу знать, если изменение что-то нарушило. Без тестов, после определенного момента вы вроде как ничего не можете изменить.
Я не слишком хорошо знаю PHP-сцену, но, похоже, существуют тестовые платформы для PHP, в том числе одна под названием PHPUnit.
На мой взгляд, у вас огромный проект для PHP. Это можно сделать, но вам действительно нужно организовать.
Разбейте его на независимые части, насколько это возможно, каждая с небольшим интерфейсом.
"Заканчивайте" столько, сколько сможете. Затем рассматривайте этот "готовый" код как API, чтобы вам больше не нужно было на него смотреть. 4,5 дня в неделю, предположим, что это написал кто-то другой и что вы знаете только интерфейс.
Здесь мы идем на риск, но разбивка проекта на более мелкие проекты/API/модули/пакеты/сборки (называйте их как хотите) должна быть следующим логическим шагом здесь.
- Начинал с малого, несколько файлов, небольшой редактор, сборки из командной строки, все было хорошо...
- Стал больше, версии стали сложнее, перешли на SVN и IDE... BIIIG повышение производительности
- Затем проект стал еще больше, и чувство подавленности снова возвращается...
Человек мозг может обрабатывать только так много вещей одновременно, просто наша рабочая память может справиться с таким количеством вещей. Сокрытие мелких деталей за более высоким уровнем абстракции позволит вам забыть об этих файлах до тех пор, пока под капотом не окажется что-то не так. Если это когда-нибудь случится, вам нужно только открыть этот конкретный капот, чтобы закрепить его там. Используйте другой уровень абстракций, и ваши проекты внезапно станут намного меньше, где только несколько единиц будут иметь смысл, в то время как остальные просто чтобы заставить их работать. ООП очень хорошо скрывает детали реализации, раскрывая функционалистов более высокого уровня. При этом, как говорится, есть и другие парадигмы, кроме ООП, из которых вы можете выбирать.
Итак, мой вам совет на данный момент
- Разбейте свои проекты на более мелкие части, каждая из которых имеет интерфейс, который предоставит вам единую точку доступа к остальным.
- Используйте модульное тестирование и другие методы тестирования с хорошей платформой тестирования для тестирования каждого фрагмента индивидуально. Это позволит вам протестировать интерфейс и посмотреть, полезен ли он.
- Никогда не открывайте содержимое интерфейса, если вы чувствуете необходимость, измените интерфейс, тесты, а затем используйте интерфейс. Это самая важная часть, игнорирование этого вернет вас к проблеме, с которой вы столкнулись сейчас (слишком много связей), поэтому максимально сократите точки взаимодействия между блоками, следовательно, интерфейсы.
Это позволит вам сократить резко увеличится количество вещей, которые вы должны помнить о своем проекте, и они будут хорошо масштабироваться до следующего порядка величины.
Затем ваш следующий шаг будет заключаться в более глубоком изучении ООП и изучении архитектуры и шаблонов проектирования. Они помогут вам еще больше сократить домен вашей системы.
Полезный лакомые кусочки
Перестань притворяться, что ты можешь держать все это в своей голове. В какой-то момент (похоже, вы достигли этого) это просто больше невозможно. Как справиться с проектом, слишком большим для запоминания? Ну, точно так же, как вы обрабатываете проекты, написанные другим человеком, или которые вы пишете для того, чтобы их поддерживал кто-то другой.
Самый важный пункт: Напишите хороший код. Используйте согласованные, значимые имена для классов, методов, переменных и т.д. Напишите функции (соответственно методы), которые выполняют именно то, о чем говорит название, ни больше, ни меньше. Никаких хитрых сокращений, неожиданных побочных эффектов, бомб замедленного действия, сюрпризов. Вы должны быть в состоянии уверенно использовать функцию, не читая ее реализацию, чтобы проверить, что она делает и как.
Организуйте свой код. Отделите код графического интерфейса пользователя от кода бизнес-логики. Храните их в отдельных папках. Если файл содержит и то, и другое, выполните его рефакторинг. Если вы сгенерировали код, храните его в отдельной папке (чтобы у вас никогда не возникало соблазна изменить его).
Используйте Система Контроля Версий. (Нельзя говорить слишком часто)
Профилируйте свой процесс!
Так же, как и профилирующий код, вы можете профилировать процесс разработки.
Посмотрите, на что тратится больше всего времени, и попытайтесь оптимизировать эту часть вашего процесса.
Большой проект на PHP? Не только серебряные пули, свинцовых пуль нет, и даже глиняных пуль не хватает.
Другой язык!
Самый большой выигрыш для вашего доллара, скорее всего, произойдет от:
Контроль версий (например, Svn, Mercurial, Git и т.д.)
Сервер сборки (например, Хадсон)
Тесты
Рефакторинг
Вам необходимо изменить архитектуру процесса создания кода. Возможно, и ваш код тоже.
Я также предлагаю прочитать код полностью.