Моя производительность уменьшается, поскольку проект становится больше. Как повысить производительность как размер увеличений проекта? [закрытый]
Вот реализация, подходящая для ветвлений:
inline int signum(const double x) {
if(x == 0) return 0;
return (1 - (static_cast((*reinterpret_cast(&x)) >> 63) << 1));
}
Если ваши данные не имеют нулей в качестве половины чисел, здесь предиктор ветвлений выберет одну из ветвей в качестве наиболее распространенной. Обе ветви включают только простые операции.
В качестве альтернативы, на некоторых компиляторах и архитектурах ЦП версия без ответвлений может быть быстрее:
inline int signum(const double x) {
return (x != 0) *
(1 - (static_cast((*reinterpret_cast(&x)) >> 63) << 1));
}
Это работает для двоичного формата двойной точности с плавающей точкой IEEE 754: binary64 .
23 ответа
Жесткий факт - эффективность разработчика будет уменьшаться с размером проекта. Об этом известно уже несколько десятилетий. Есть методы, которые могут помочь, но они требуют определенной дисциплины.
Лучшее решение - перейти на более высокий уровень абстракции. Напишите процедуры, которые будут служить строительными блоками, которые вы можете использовать, как если бы они были стандартной библиотекой или языковыми конструкциями. Документируйте их интерфейсы и программируйте только для интерфейсов. Если вам когда-либо кажется, что вам нужно знать, как реализована процедура, над которой вы не работаете, вы либо используете ее неправильно, либо недостаточно документировали интерфейс. Медленнее добавляйте к интерфейсу, медленнее удаляйте что-либо и помните, что изменение его элементов может вас сильно укусить.
Местность - ваш друг. Чем больше вы сможете сосредоточиться на небольшой площади, тем лучше вам будет. Программирование интерфейсов помогает этому. Согласование процедур помогает этому, так что подпрограммы делают одно дело за раз.
Ориентация на объекты очень полезна, так как она способствует двум вышеупомянутым. Он способствует инкапсуляции и кодированию интерфейса, а также группирует связанные части кода вместе.
Разработка, управляемая тестированием, важна для обеспечения программирования интерфейса. Пишите тесты на основе интерфейса, а не реализации. У этого есть приятный побочный эффект, заключающийся в том, что сами наборы тестов помогают определить интерфейс. Если это не проверяется, вы не рассчитываете на это. Убедитесь, что вы можете легко запускать наборы тестов и выработать привычку.
Потребуется рефакторинг. Планируйте это, особенно когда что-либо меняете. Вам нужен чистый код. Более того, вы неизбежно обнаружите, что разместили функциональные возможности не в том месте.
Помните также, что ничто из этого не решит проблему полностью. Большие программные проекты по своей сути сложны.
Более того, вы неизбежно обнаружите, что разместили функциональные возможности не в том месте.Помните также, что ничто из этого не решит проблему полностью. Большие программные проекты по своей сути сложны.
Более того, вы неизбежно обнаружите, что разместили функциональные возможности не в том месте.Помните также, что ничто из этого не решит проблему полностью. Большие программные проекты по своей сути сложны.
Большой проект на PHP? Не только серебряные пули, здесь нет свинцовых пуль, и даже глиняных пуль мало.
Другой язык!
Профилируйте свой процесс!
Так же, как профилируя код, вы можете профилировать свой процесс разработки.
Посмотрите, на что уходит больше всего времени, и попробуйте оптимизировать эту часть вашего процесса.
На мой взгляд, у вас огромный проект для PHP. Это можно сделать, но вам действительно нужно организовать.
Разбейте это как можно больше на независимые части, каждая с небольшим интерфейсом.
«Готово», насколько это возможно. Затем рассматривайте этот «законченный» код как API, чтобы вам больше не приходилось на него смотреть. 4,5 дня в неделю, предположим, что это написал кто-то другой, а вы знаете только интерфейс.
I have found that test-driven development (TDD) / behavior driven development (BDD) helps me keep things in order as they get larger. Even if you just write unit tests, leaving aside functional, integration, and other tests, that alone can be a huge help. As your code base turns into a lumbering, shambling Swamp Thing of Doom, your tests will keep it shambling in more or less the right direction and will prevent it from tripping over a rock, falling face down in the mud, and drowning because it's too heavy to get up.
If you write enough tests and they're well thought out they can make it so that you can make changes and know right away if the change broke something. Without tests, after a certain point you kind of can't change anything.
I don't know the PHP scene too well but it appears that there are testing frameworks for PHP, including one called PHPUnit.
Перестань притворяться, будто ты можешь держать все это в своей голове. В какой-то момент (похоже, вы его достигли) это просто больше невозможно. Как справиться с проектом, слишком большим для запоминания? Ну, точно так же, как вы обрабатываете проекты, которые были написаны другим человеком или которые вы пишете для поддержки кем-то другим.
Единственный наиболее важный пункт: напишите хороший код. Используйте последовательные, осмысленные имена для классов, методов, переменных и т. Д. Напишите функции (соответственно методы), которые делают именно то, что говорит имя, ни больше, ни меньше. Никаких хитростей, неожиданных побочных эффектов, бомб замедленного действия, сюрпризов. Вы должны уметь использовать функцию с уверенностью, не читая ее реализацию, чтобы проверить, что она делает и как.
Организуйте свой код. Отделите код графического интерфейса пользователя от кода бизнес-логики. Храните их в отдельных папках. Если файл содержит и то, и другое, выполните рефакторинг. Если вы сгенерировали код, храните его в отдельной папке (чтобы у вас никогда не возникало соблазна его модифицировать).
Используйте систему контроля версий. (Жестяная банка'
Использование фреймворк PHP MVC значительно сократит объем кода, который вам нужно отслеживать. Он позаботится о многих вещах, которые вам, вероятно, пришлось написать самостоятельно, например о сеансе, уровне базы данных и т. Д. Используя фреймворк, он поможет вам логически организовать ваши файлы.
Нетипизированные и процедурные языки не работают в больших проектах. Так было всегда, поэтому был создан объектно-ориентированный подход, а такие вещи, как разделение и инкапсуляция, считаются хорошими методологиями проектирования.
Конечно, сначала используйте oo программирование и наследование. Затем я бы использовал фреймворк, такой как воспламенитель кода, для начала, добавил бы модуль для макета (чтобы у вас был согласованный макет сайта) и, возможно, несколько других, главное не тратить слишком много времени на общие вещи. К сожалению, миграции для CI невелики, но они существуют, поэтому что-то в этом роде было бы полезно для работы с db. С ними вы снова сможете продуктивно работать, поскольку не будете тратить время на мелочи.
Проблема с более крупными проектами заключается в том, что они имеют множество аспектов, и чем больше их существует, тем больше времени вам нужно потратить на их учет.
Надеюсь, это поможет.
В конце концов мы нашли ответ - в потоке управления были две независимые задачи, которые устанавливали соединения с одной и той же базой данных. Очевидно, где-то есть какое-то состояние гонки, которое приводит к сбою. Добавление ограничения приоритета для принудительного выполнения задач последовательно решило проблему.
По моему личному мнению, первые два пункта (инструменты и методы) действительно хороши, но не то, что действительно меняет. Например, в моей команде есть коллеги, которые используют старые редакторы и работают почти так же продуктивно, как коллеги, использующие Eclipse.
С другой стороны, два других пункта помогут гораздо больше: дисциплина, хороший дизайн и рефакторинг помогут поддерживать сложность на минимальном уровне, а хорошая командная работа позволяет заниматься более крупными проектами, которые сами по себе были бы слишком сложными.
Однако, как вы уже отметили, серебряной пули не существует. В конце концов, сложность любого успешного программного обеспечения возрастает до такой степени, что его обслуживание может стать настолько дорогостоящим, что потребуется полностью новое поколение.
И это жизнь в программном обеспечении: -)
Моя первая мысль, что вам нужно что-то записывать. Ваш комментарий о том, что «это все в моей голове» беспокоит меня, что
- В конце концов вы забудете что-то очень важное и потратите время на то, чтобы придумывать или перестраивать что-то, потому что вы не можете вспомнить.
- Будущие программисты в проекте буду ненавидеть вас за то, что вы ничего не документируете.
Я считаю, что вики, даже если я единственный пользователь, феноменально помогает в упорядочивании моих мыслей. Процесс редактирования прост и быстр, что позволяет мне буквально дампить содержимое моего мозга на доступный для поиска цифровой носитель.
Неважно, какую вики вы выберете, просто потратьте некоторое время, чтобы действительно изучить синтаксис, чтобы если вы не переключаете постоянно внимание на форматирование.
- Рефакторинг после каждой итерации - поддерживает чистую базу кода
- Устранение зависимостей - помогает упростить понимание базы кода
- Автоматизировали модульные тесты и средства тестирования - сокращают время выполнения новой функции.
- Обновление документации и отслеживаемость после каждой итерации - помогает понять код.
Раньше я работал над проектом, в котором было примерно миллион строк кода (C #, C ++), и он все еще растет.
1) Для управления такой базой кода папка Структура svn-архива была создана таким образом, чтобы имитировать различные архитектурные слои нашего продукта. Так стало легче ориентироваться в архиве.
2) Также у нас был собственный инструмент для сборки. Когда у вас огромная база кода, может оказаться невозможным создать все в любое время, когда вы захотите протестировать небольшую функцию. У нашего специального инструмента сборки было множество опций, с помощью которых можно было построить архив с любой степенью детализации.
3) Обычно я наблюдал, что если вы правильно понимаете общие функции / помощники, создание новых вещей на его основе становится проще, а также предотвращает раздувание кода.
4) Создайте вики, если над вашим проектом работает больше разработчиков. Вики-документация проста, способна искать и полезна, если все сделано правильно.
Это все, о чем я могу думать прямо сейчас. Надеюсь, это поможет
Никогда не гордитесь редактированием кода в блокноте! IDE экономит ваше время и повышает эффективность. Когда проект становится большим, вам следует позаботиться об управлении проектом и придерживаться эффективного «шаблона процесса», такого как RUP (Rational Unified Process), EUP или OOSP. Ваш SVN является частью SCM. Конечно, в шаблоне определено гораздо больше действий. Что касается проблемы управления файлами, вы можете разделить их на разные пакеты и сохранить в разных местах. Если вы не имеете никакого представления о «программной инженерии», вы можете обратиться к некоторым книгам, написанным Скоттом Эмблером или другими о SE (программной инженерии). Помните, Великий разработчик знает, что разработка - это больше, чем разработка. Скотт У. Амблер
Разработка через тестирование может быть вам полезна.
Сначала создайте свои тесты, а затем напишите код для прохождения этих тестов.
Когда вы добавляете / изменяете любой код, возникает регресс набор тестов, который вы можете запустить, чтобы убедиться, что вы что-то не сломали. По моему опыту, это экономит массу времени, особенно по мере роста сложности и размера приложения.
Производительность на больших базах кода - это не столько инструменты, сколько код, который вы пишете. Потратьте время на улучшение качества вашего кода, как нового, так и существующего. Да, это замедляет вас в краткосрочной перспективе, но позволяет поддерживать темп со временем.
Это применимо независимо от ваших инструментов или языка. Лучшие инструменты в мире не помогут тому, кто хочет устроить беспорядок. Для начала я бы держал в уме несколько простых идей:
- Качество кода - это вложение в будущую продуктивность.
- Если ваша интуиция подсказывает вам, что код плохой, сложный, неправильный, уродливый ... это, вероятно, так, исправьте это.
- Прекратите писать плохой код, сейчас, а не завтра.
Чтобы получить более подробную информацию о том, как создавать отличный код, я предлагаю просмотреть здесь .
Нарисуйте и / или запишите это. Если вы говорите, что «все в вашей голове», то выделите время для написания кода и задокументируйте свою работу. Это может включать в себя абзацы, объясняющие, почему вы что-то сделали.
Диаграммы и другие наглядные пособия также помогут вам сохранить порядок.
Я обнаружил, что некоторые программисты игнорируют нетехнические факторы в проектах. Это особенно актуально для разработчиков-одиночек, у которых нет структуры группы, которая могла бы ими руководить. Ваша работа - это больше, чем просто код, и вы должны смотреть на все аспекты своего процесса.
Возьмите в привычку регулярно изучать свой код и искать способы исключить повторение (т. Е. Применять принцип «Не повторяйся» или принцип DRY) и будьте безжалостны. в рефакторинге этого повторения. Чем больше вы вставляете общие фрагменты кода в методы и классы многократного использования, тем проще писать новый код и тем больше у вас возможностей для решения проблемы.
Использование хорошей IDE поможет вам найти общие черты и применить рефакторинг.
Также ищите фреймворки и инструменты с открытым исходным кодом , которые автоматизируют некоторые аспекты вашего программного обеспечения. Их использование - это массовое применение принципа СУХОЙ.
Думаю, вам следует прочитать Классическая книга Брукса « Мифический человеко-месяц, юбилейное издание ». Хотя в оригинальной книге описана работа, проделанная в середине 60-х годов, основные истины все еще точны. И более поздняя статья о « No Silver Bullet » (который включен в юбилейное издание) очень проницателен.
Короче говоря, в книге объясняется, что по мере того, как программы становятся больше, ими становится все труднее управлять (понимать, поддерживать, развивать), потому что есть больше вещей, о которых нужно думать. Почти все методы проектирования и программирования используются, чтобы попытаться ограничить эти проблемы, но проблемы возникают по мере того, как программное обеспечение становится больше (это «суть» части подзаголовка «Нет серебряной пули»).
Как насчет этого мифа, который витает в воздухе, что ООП спасет положение? Если это правда, то почему ребята из Linux / Kernel все еще выпускают новые версии еженедельно? Другими словами, все ли программисты ASM / C обречены на сложность «Hello World»?
Не уверен, что именно вы просите. Я имею в виду работу над проблемами до и после их возникновения:
Если у вас много файлов и LOC, просто уменьшите и реорганизуйте их. Например, путем создания или использования надежных фреймворков для определенных задач (PDO вместо mysql ()). Другими словами, не повторяйтесь. Короткие, запоминающиеся, похожие названия функций: get_user_ID (), get_task_ID (), db_query () ....
Является ли общение в группе проблемой? Попробуйте вики, внутренний чат, попробуйте добавить больше комментариев, спросите группу, что им не нравится и что они хотят улучшить. Это полностью зависит от проекта.
Если вы работаете в группе, не будьте постоянно заняты. Работайте над деталями и улучшайте их. Это экономит время, необходимое для того, чтобы понять мышление других программистов. Одно изменение за раз. Не открывайте 200 файлов и не редактируйте совершенно несвязанные вещи.
Автоматизируйте и ускоряйте все, если возможно: развертывание, управление версиями, документацию, тесты.
Большие проекты - это большие проекты, и их всегда трудно полностью понять. KISS - это хорошо, но, по моему опыту, иногда помогает просто разбить все на независимо работающие компоненты, взаимодействующие через XML, языковые интерфейсы и т. Д. Вкратце: сделайте много маленьких проектов из большого. Я веду личный список дел / запоминаний как "myname.todo.txt".
Быстрое развертывание обязательно! Например, установите локальную лампу / xampp и напрямую просматривайте свои изменения.
Следующим логическим шагом здесь должно стать разрушение проекта на более мелкие проекты / API / модули / пакеты / сборки (называйте их как хотите).
- Начал с малого, несколько файлов, небольшой редактор, сборки из командной строки, все было хорошо ...
- Стало больше, версии стали сложнее, перешли на SVN и IDE ... БОЛЬШОЕ повышение производительности
- Затем проект окупился больше, и чувство подавленности возвращается снова ...
Человеческий мозг может обрабатывать столько всего одновременно, столько всего может справиться наша рабочая память. Скрытие мелких деталей за более высоким уровнем абстракции позволит вам забыть об этих файлах, пока под капотом не что-то не так. Если это когда-нибудь произойдет, вам нужно только открыть именно этот капюшон, чтобы исправить это там. Используйте другой уровень абстракции, и ваши проекты внезапно станут намного меньше, где только несколько единиц будут иметь смысл, а остальное - просто заставить их работать. ООП очень хорошо скрывает детали реализации, открывая доступ к функционалистам более высокого уровня. При этом есть и другие парадигмы, помимо ООП, из которых вы можете выбирать.
Итак, мой вам совет на этом этапе.
- Разбивайте ваши проекты на более мелкие части, каждый с интерфейсом, который даст вам единую точку доступа к остальное.
- Используйте модульное тестирование и другие методы тестирования с хорошей средой тестирования, чтобы протестировать каждый блок по отдельности. Это позволит вам протестировать интерфейс и посмотреть, полезен ли он.
- Никогда не обращайтесь к тому, что скрывается за интерфейсом, если вы чувствуете необходимость, измените интерфейс, тесты и затем используйте интерфейс. Это самая важная часть, игнорирование этого вернет вас к проблеме, которая у вас есть сейчас (слишком сильная связь), поэтому уменьшите как можно больше точек взаимодействия между чанками, а следовательно, и интерфейсы.
Это позволит вам чтобы резко сократить количество вещей, которые вы должны помнить о своем проекте, и будет хорошо масштабироваться до следующего порядка величины.
Затем вашим следующим шагом будет более глубокий взгляд на ООП и изучение архитектуры и шаблонов проектирования. Они помогут вам еще больше сократить область вашей системы.
полезные лакомые кусочки
Наибольшую отдачу от вложенных средств, вероятно, принесут:
Контроль версий (например, Svn, Mercurial, Git и т. Д.)
Сервер сборки (например, Hudson)
Тесты
Рефакторинг
Вам необходимо изменить архитектуру процесса построения кода. Возможно, ваш код тоже.
Я также предлагаю прочитать Code Complete.