Как сделать код более быстрым (без ущерба для качества) [закрыто]

Я был профессиональным кодером уже несколько лет. Комментарии о моем коде, как правило, были одинаковыми: пишет отличный код, хорошо протестирован, но может быть быстрее .

Итак, , как я могу стать более быстрым кодером , не жертвуя качеством? Ради этого вопроса я собираюсь ограничить область применения C #, поскольку это в первую очередь то, что я кодирую (для удовольствия) - или Java, что во многом аналогично многим.

Вещи, которые я уже делаю:

  • Напишите минимальное решение, которое выполнит работу
  • Напишите множество автоматических тестов (предотвратите регрессии)
  • Пишите (и используйте) многоразовые библиотеки для всех видов вещей.
  • Используйте хорошо известные технологии, где они хорошо работают (например, Hibernate).
  • Используйте шаблоны проектирования, где они подходят (например, Singleton)

Все это здорово, но я не чувствую, что со временем скорость увеличивается. I do , потому что, если я могу что-то сделать, чтобы увеличить свою производительность (даже на 10%), это на 10% быстрее, чем у моих конкурентов. (Не то, чтобы у меня было.)

Кроме того, я постоянно получал эту скидку от своих менеджеров - будь то мелкомасштабная разработка Flash или корпоративная разработка Java /C ++.

Изменить: Кажется, что у меня много вопросов о том, что я имею в виду, и как я знаю, что я медленный. Позвольте мне уточнить некоторые подробности.

Я работал в небольших и средних группах (5-50 человек) в различных компаниях по различным проектам и различным технологиям (Flash, ASP.NET, Java, C ++). Наблюдение за моими менеджерами (что они сказали мне прямо) состоит в том, что я «медленный».

Отчасти это связано с тем, что значительное количество моих сверстников приносило в жертву качество за скорость; они написали код, который был неудачным, трудно читаемым, его трудно поддерживать, и трудно писать автоматизированные тесты. Мой код, как правило, хорошо документирован, доступен для чтения и может быть проверен.

В Oracle я буду последовательно решать ошибки медленнее, чем другие члены команды. Я знаю это, потому что я получаю комментарии к этому эффекту; это означает, что другие (да, более старшие и опытные) разработчики могли бы выполнять мою работу за меньшее время, чем это требовало меня, при почти том же качестве (читаемость, ремонтопригодность и тестируемость).

Почему? Что мне не хватает? Как я могу поправиться?

Моя конечная цель проста: если я смогу сделать продукт X через 40 часов сегодня, и я могу как-то улучшить себя, чтобы я мог создать тот же продукт через 20, 30 или даже 38 часов завтра, вот что я хочу ноу-хау, как я туда попасть? Какой процесс я могу использовать для постоянного улучшения? Я думал, что речь идет о повторном использовании кода, но этого недостаточно.

130 голосов | спросил 3 revs, 2 users 100%
ashes999
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

19 ответов


144

Мне нравится подход Джеффа Этвуда к этому, который можно найти здесь http: //www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

В основном в статье он ссылается на отрывок из книги Art & Страх Дэвида Бейлса и Теда Орланда. Проход идет:

  

Учитель керамики объявил о   что он разделил   класс на две группы. Все на   в левой части студии, сказал он,   будет оцениваться только по количеству   работы, которую они произвели, все   право исключительно на его качество. Его   процедура была простой: в последний день   класса, который он принесет   шкафы для ванной и взвешивают работу   группа «количество»: пятьдесят фунтов   горшки оценили «А», сорок фунтов «В»,   и так далее. Те, кого оценивают   «качество», однако, необходимо для производства   только один банк - хотя и идеальный -   получить «А». Ну, пришло время сортировки   и возник интересный факт: работы   самого высокого качества были произведены   по классификации группы   количество. Кажется, что, хотя   Группа «количество»   из груды работы - и обучения   их ошибки - группа «качество»   сидел, теоретизируя о совершенстве,   и в конце концов было немного больше, чтобы показать   за их усилия, чем грандиозные   теории и кучу мертвой глины.

По сути, ваши руки грязные быстрее и чаще улучшают ваши навыки лучше, чем тратить свое время на изучение и теоретизацию о «идеальном» способе сделать это. Мой совет, продолжайте практиковать, идти в ногу с технологией и изучать дизайн.

ответил kevin cline 28 Mayam12 2012, 10:08:34
69

Одна из возможностей, о которой никто больше не упомянул, заключается в том, что вы делаете все отлично, а ваши менеджеры не очень хороши. Как они измеряют производительность? Могут ли они дать вам конкретные примеры или это просто общее восприятие? Учитывали ли они количество времени, затрачиваемого на то, чтобы работать над другими людьми по сравнению с вашими?

Я видел, как многие люди получают кредит за то, что делали вещи, а остальная часть их команды исправляет беспорядок, который они оставили.

ответил kevin cline 28 Mayam12 2012, 10:08:34
39

Большинство людей, которые думают , важны, не важны. Скорость ввода не важна. Более быстрые машины или инструменты не важны. Мы не машинистки или машинные операторы. Мы мыслители. Мы принимаем решения .

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

  • Работа над сторонними проектами.
  • Работа над проектами с открытым исходным кодом.
  • Работайте с разработчиками, которые лучше вас. Паровая программа!
  • Откройте для себя новые инструменты и методы. Сохраняйте, что работает.
  • Выполняйте упражнения программирования, предназначенные для обучения вашего устройства принятия решений *.
  • Контролируйте свое улучшение на основе объективных показателей, таких как скорость и скорость дефекта, а также субъективные показатели, такие как качество кода и фитнес.

Наконец: помните, что скорость без качества бесполезна, и наоборот. Чтобы максимизировать свою полезность, найдите баланс между этими напряжениями.

* http://codekata.pragprog.com/

ответил kevin cline 28 Mayam12 2012, 10:08:34
22

Вполне возможно, что на самом деле вас попросят пожертвовать качеством some для большей скорости.

В некоторых средах разработки 1 просто не стоит лишнего времени производить что-то отполированное, когда будет «достаточно хорошо».


1 - Я думаю о «внутренних инструментах» в частности, но, возможно, есть и другие.

ответил kevin cline 28 Mayam12 2012, 10:08:34
12

Похоже, вы делаете все хорошие вещи - что в среднесрочной перспективе сделает вас быстрее, поэтому это не очевидно, если вы на самом деле медленны. Только вы действительно это знаете. (но это очень реальная возможность - PeopleWare утверждает, что разница между разработчиками составляет 10X разной производительности для одной и той же задачи).

Итак, у меня есть несколько предложений для вас:

  1. Время - относительная вещь, поэтому, возможно, проблема заключается не в вашей реальной скорости, а в восприятии времени, которое вы даете. Вы можете предположить, что это займет неделю, но в итоге потратить две недели, где другие могут потратить 3 недели ... но вы просто смотрите на 1 неделю медленнее.

  2. Поскольку вы часто получаете эту обратную связь, возможно, время поговорить с вашим менеджером и сверстниками, чтобы узнать, что они говорят, - должно быть много, чтобы учиться у них.

  3. Сделайте пару программ с разработчиком «быстрого качества», чтобы узнать, можете ли вы определить разницу.

ответил kevin cline 28 Mayam12 2012, 10:08:34
8

Вопрос: если вы стоите дешевле, глядя на долгосрочную общую стоимость.

Другими словами, ваши тщательно исправимые исправления ошибок такого высокого качества (в том числе тестовые примеры и документация), что он перевешивает расходы, связанные с необходимостью исправлять ошибки, совершенные вашими более быстрыми сотрудниками

Если да, то вам нужно, чтобы ваши начальники знали об этом факте. Может быть, трудно спорить, если они не измеряют и не имеют необходимых данных для подтверждения вашей оценки.

Если нет, то вам нужно рассмотреть , почему это так:

  • Вы слишком неопытные?
  • Вы тратите много времени на то, чтобы делать то, что не было спрошено, которое, по вашему мнению, должно быть там?
  • Вам сложно определить, когда исправление закончено?
  • Является ли ваш код более низкого качества после вас, чем вы думаете?
  • Если вы подходите к разработке кода по-другому, потому что вам нужно слишком долго, чтобы ускорить то, как вы это делаете сейчас?
  • Вы потратили слишком много времени на такие вещи, как этот сайт?

Подумайте об этом и измените свой вопрос своими выводами.

ответил kevin cline 28 Mayam12 2012, 10:08:34
7

Эффективно, что это сводится к опыту . Быть быстрее в том, что вы делаете, это вождение автомобиля, изначально вы боитесь, так как другие быстрые (или пьяные) драйверы (или оба), и вы хотите безопасно добраться домой (в программном обеспечении вы хотите убедиться, что ваш код работает как развитый, и он хорошо работает).

В течение нескольких лет /месяцев, как только вы получаете вождение и автострады, вы узнаете несколько трюков по пути, который делает ваше удовольствие от вождения. Это то, что мы называем опытом. Эти «трюки» (которые я называю чертами) - это то, что помогает.

В моем случае я изучил реальное использование шаблонов проектирования путем кодирования (даже @ home) и изучения использования некоторых. Таким образом, когда я сталкиваюсь с проблемой, которая требует шаблона проектирования, я использую прошлый опыт, чтобы увидеть, какие из них были обработаны, и почему он будет работать /не работать для моей ситуации.

Вкратце:

  • Опыт создает черты, повышающие доверие и лучшее программное обеспечение.

PS: Опыт также происходит от обучения других. Например. Помощь от SO, Pair Programming, Peer Reviews и т. Д. У вас не может быть опыта, если вы не можете оглянуться назад и учиться на ошибках (или если кто-то никогда не бросает вызов вашим усилиям).

ответил kevin cline 28 Mayam12 2012, 10:08:34
7

Все опрошенные люди сделали о том, действительно ли вы по-настоящему медленны, это глупо. Быть более быстрым программистом, не жертвуя качеством, всегда является хорошей целью независимо от того, насколько вы медленны или быстры. Это моя цель номер 1 в качестве программиста, и я никогда не буду сделан. Я всегда стараюсь быстрее, не жертвуя качеством, я одержим этим. Вот что я до сих пор работал в порядке полезности, а также некоторые экспериментальные идеи в конце:

1) Никогда не прекращайте обучение: Узнайте все, что вы можете о программировании и использовании компьютеров в целом. Найдите районы, в которых вы слабы, и изучите их. Даже если это кажется совершенно не связанным с вашей работой и C #, я гарантирую, что если вы ее ищете, вы часто найдете способы применить ее к тому, что вы делаете. Обучение также связано с опытом, поэтому не просто читайте материал, но и пробуйте его и расширяйте свои навыки. Если вы привыкли использовать Windows, попробуйте использовать Unix или наоборот. Если вам обычно нравится использовать инструменты командной строки IDE и текстовые редакторы или наоборот. Если вы слышите о инструменте или технологии, о которых вы не слышали раньше или не знаете многого, не поддавайтесь соблазну двигаться дальше. Поищи это! Не бойтесь мыслить вне коробки и изучать экспериментальные новые технологии, которые, по мнению других, непрактичны; Мы только начинаем царапать поверхность, как продуктивно программировать.

2) Разбить проекты: Попытайтесь разбить свои проекты на мини-проекты. Попробуйте сделать новый выпуск каждый день или раз в несколько дней максимум. Спросите себя: «Какова минимальная функциональность, которую я могу выпустить, и до сих пор выпускаю что-то полезное для пользователя». Это умение, которое вы узнаете, сделав это. Возможно, вам придется убедить своих менеджеров позволить вам сделать это, но они, как правило, будут довольны результатами довольно быстро. Сделав это, вы начнете замечать, что вещи, которые, по вашему мнению, были важны для вашей функции, на самом деле являются дополнительными функциями, которые могут быть разработаны позже. Это позволяет вам и вашим менеджерам уделять приоритетное внимание только самым важным функциям, а не всем функциям, связанным с тем, над которым вы работаете. Это позволяет вам думать быстрее, сохраняя свой разум ясным и целенаправленным. Вы, в свою очередь, будете законно программировать быстрее. Менеджеры вашего менеджера или, по крайней мере, менеджеры вашего менеджера также, скорее всего, поймут, что вы сейчас программируете даже быстрее, чем вы на самом деле, потому что вы получаете больше выпусков. Еще одно огромное преимущество в этом заключается в том, что вы будете намного лучше оценивать, сколько длинных релизов потребуется для завершения, и ваши менеджеры будут любить вас за это. Поскольку вы уже проводите много автоматизированного тестирования, у вас не должно возникнуть проблем с частыми релизами, которые стабильны. Тем не менее, вам может потребоваться усиление вашей автоматизированной системы сборки. Я настоятельно рекомендую прочитать книгу «Непрерывная поставка» в серии Martin Fowler. Это трудно прочитать и потому, что он очень повторяющийся, но все же очень полезный.

3) Используйте технику pomodoro и адаптируйте /измените то, что не работает для вас. Если вы объедините это число с номером 2 в этом списке, вы получите БОЛЬШОЕ повышение производительности.

4) Изучите Vim. Даже если вы закончите использовать эти команды в Visual Studio с помощью ViEmu или изнутри Eclipse через плагин или из Emacs, вы получите производительность. Лучший способ узнать Vim - начать использовать его и заставить себя никогда (отключить его /вернуться к старым инструментам), пока вы не освоите его. Сначала это больно, но вы никогда не захотите вернуться и даже съежиться, когда вам придется работать без него. Некоторые сказали бы, что это не увеличит вашу скорость. Но быстрее происходит быстрее, особенно когда чтение и изменение кода - это ЧТО МЫ ДЕЛАЕМ, и я обнаружил, что иногда экономят много времени с этим.

5) Это последнее не обязательно рекомендуется, так как я не уверен, что это хорошая идея, и это может фактически снизить вашу производительность, но я все равно ее пройду. Вы можете попробовать сделать больше приемочных испытаний и меньше модульных тестов, или, возможно, напо крайней мере, убедитесь, что вы проводите приемочные испытания. У меня был успех с SpecFlow, но я подозреваю, что там что-то лучше. Даже написание спецификаций может быть довольно техническим, поэтому вы можете просто попросить своего менеджера /клиента сначала написать черновик, чтобы вы значительно изменились, или вы можете написать все, что угодно, и просто попросите их прочитать и ОК. Это поможет вам с номером 2 из этого списка. Также приемочные испытания могут быть более практичными и требуют меньше кода, чем модульные тесты. Это не значит, что они заменяют их, разные инструменты для разных вещей. Но вы можете уйти с меньшим модульным тестированием, если вы проводите много приемочных испытаний.

6) Это еще более экспериментально и противоречиво. Я на самом деле не сделал этого сам, поэтому я не могу его точно рекомендовать. Изучите и используйте Meta Programming System из JetBrains. Используйте его для создания инструментов, которые ваш менеджер /клиент использует для создания самого необходимого программного обеспечения. Возможно, вы даже сможете прекратить выполнение единичных и приемочных тестов, если вы можете использовать это, чтобы создавать инструменты, которые ваш менеджер /клиент использует, чтобы определить поведение очень простым и незастроенным способом. Идея заключается не в том, чтобы избавиться от программиста. Программистам все равно нужно будет добавлять новые функции к этим инструментам, используемым клиентом /менеджером, когда они (люди, а не инструменты) не могут легко создать желаемую функциональность. Я верю, что MPS или другие аналогичные ему инструменты - это путь в будущее.

ответил kevin cline 28 Mayam12 2012, 10:08:34
5

Используйте свой мозг больше и делайте меньше испытаний. Честно говоря, тестирование имеет свое место, но оно дорого.

Также читайте «Искусство программирования Unix» (бесплатно онлайн, книга стоит цены)

Наконец, вы можете оказаться не в нужном месте. Круглый колышек в квадратной работе и т. Д.

В конце концов, это похоже на школу: «Вывести то, что хочет учитель», становится «выводить то, что менеджмент запрашивает и оплачивает».

ответил kevin cline 28 Mayam12 2012, 10:08:34
5

Если вы возьмете довольно большой завершенный проект и получите количество «окончательных» строк кода за человеческий час, вы обнаружите, что код программистов МНОГО медленнее, чем вы могли себе представить.

Мы говорим всего несколько строк кода в день. В остальное время вы тратите отладки, переписываете и делаете общий материал программиста.

Возможно, вы слышали старую поговорку: если вы поймаете ошибку во время ее ввода, она спасет вас в 10 раз, если вы поймаете ее во время сборки, что в 10 раз лучше, чем ловить ее во время QA, что в 10 раз лучше, чем поймать его после выпуска.

Итак, как вы это ускорите? Я бы не сосредоточился на какой-либо форме набора текста - сокращение ошибок и улучшение других «будущих взаимодействий» с вашим кодом должно быть намного лучшим вложением вашего времени.

Считываемый, понятный код имеет решающее значение. Вы пишете свой код один раз, но он будет читаться десятки раз. Запись для удобства чтения сэкономит вам массу проблем по линии (что также сэкономит много времени). Если вы ВСЕГДА вернетесь и прочитаете свой код, и вам придется подумать об этом хотя бы секунду, тогда вы делаете это неправильно.

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

Кодирование с защитой (например, проверка параметров) может уменьшить проблемы ... Если у вас действительно хороший аналитик /архитектор в вашей команде, вы можете сэкономить время с хорошим стартовым дизайном.

В противном случае просто продолжайте совершенствовать свои дизайнерские навыки. По мере того, как вы приобретете опыт, вы обнаружите, что сможете более эффективно распознавать шаблоны, которые не будут работать, и избегать их, вы сможете идентифицировать приемники времени раньше и т. Д.

ответил kevin cline 28 Mayam12 2012, 10:08:34
3

Считаете ли вы, что вы делаете подробный аудит себя, когда работаете? Как ручка, так и бумага отслеживают, как вы тратите свое время или используете что-то вроде Время спасения , чтобы отслеживать себя.

Как только вы более точно узнаете, КАК вы проводите свое время, вы можете получить лучшее представление о том, что нужно улучшить и сосредоточить свои усилия там.

В идеале вы можете бросить вызов некоторым из ваших коллег, чтобы сделать это тоже, сравнить свои результаты и получить идеи друг от друга. Вероятно, у вас есть некоторые сильные стороны, от которых они могут выиграть.

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

Или, может быть, вы узнаете, что тестирование занимает больше времени, чем вы думали, и вам нужно переосмыслить свое мнение о том, что оно ускоряет процесс.

Если ничто другое не дает вам некоторых тестов, с которыми вы можете работать.

ответил kevin cline 28 Mayam12 2012, 10:08:34
3

Из вашего списка у вас все в порядке.

Если ваши коллеги делают код с более высоким номером CRAP, они будут идти быстрее. CRAP - это комично названная метрика, объединяющая циклическую сложность и охват тестирования.

Не пишите код, который больше CRAP, чем вам нужно. ;)

Мое единственное изменение, которое вы предлагаете, это использовать библиотеки, не пишите их, если:

  1. Ваша компания продает библиотеки.
  2. Вы обновили повторяющийся код в библиотеке

Ты читаешь и делаешь, и это здорово. Но вы можете задуматься о кодексах или OO-коде, не подверглись ли вы функциональному программированию (скажем, Haskell?) И Prolog?

Чтобы обострить технику программирования OO, вы играли с Smalltalk /Squeak?

И, наконец, теория. У вас есть хотя бы рудиментарное понимание теории графов? (Некоторые программы работают с деревьями, DAG или просто графами в какой-то точке. Сети - это графики)

ответил kevin cline 28 Mayam12 2012, 10:08:34
3

Насколько я знаю, это:

  1. хорошо
  2. быстро
  3. дешевы

В качестве менеджера вы можете выбрать любые 2.

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

ответил kevin cline 28 Mayam12 2012, 10:08:34
2

Основные вещи, о которых я могу думать, следующие:

  • Увеличьте скорость ввода.
  • Используйте инструменты, обеспечивающие повышение производительности. Например, ReSharper.
  • Более быстрые машины или инструменты. Как и больше оперативной памяти или твердотельного диска.

Я уверен, что есть кое-что, что вы можете сделать и в области навыков кодирования, но похоже, что вы все это делаете. То, что я перечислял выше, обычно игнорируется разработчиками.

ответил kevin cline 28 Mayam12 2012, 10:08:34
2

Вы можете пройти курс скоростной печати. Я не знаю, быстрее ли печатать на машинке, но «слишком медленное кодирование» может быть вызвано просто медленной скоростью печати.

Как насчет генераторов кода? Иногда код повторяется. Рефакторинг может удалить некоторые из них, но даже тогда у вас могут повторяться призывы к одной и той же рефакторинговой функции. В зависимости от данных и кода, с которыми вы работаете, генераторы кода (написанные в Excel, Perl, Java, независимо ...) могут сэкономить много времени. И использование инструментов генерации кода для разработки пользовательского интерфейса обычно не вызывает затруднений.

И, наконец, возможно, метрики ошибочны. Считаете ли вы, что вы кодируете на скорости fasteset возможную скорость, учитывая все остальное, и что временные рамки слишком коротки, чтобы вы отображались как медленный кодер? р>


Основываясь на изменениях в вашем вопросе, кажется, что вы можете либо пойти по пути некоторых ваших сотрудников, и взломать самое быстрое решение, которое будет работать, - и документация и QA будут прокляты!

Или ... получите больше опыта и практики в определенной области, чтобы вы знали код и API так хорошо, что могли бы кодировать решения во сне. Это можно сделать, но требуется больше времени. Если другие разработчики, которые быстрее вас знают, являются более старшими и более опытными, то есть только одна вещь - вы должны стать старше и опытнее!

ответил kevin cline 28 Mayam12 2012, 10:08:34
2

Я приведу Дядя Боб :

  

Единственный способ быстро идти - это хорошо.

     

Каждый раз, когда вы испытываете искушение торговать качеством за скорость, вы замедляетесь. Каждый раз.

- «Беспокойная посредственность», Роберт К. Мартин

ответил kevin cline 28 Mayam12 2012, 10:08:34
2

У меня есть возражение против того, что OP «пожертвовал качество для скорости».

Профессиональные кодеры (программисты) должны удовлетворять 3 объектам:
1) Код должен работать как предполагается 2) Доставка должна быть вовремя
3) иметь хорошее качество, документацию и т. Д.
4) Другое и т. Д.

Я думаю, что OP был обвинен как медленный, вероятно, потому, что OP не успел.

ответил kevin cline 28 Mayam12 2012, 10:08:34
2

Это уловка 22, с которой трудно обойти. Хотя у вас все еще может быть недостаток опыта и некоторые знания во многих аспектах уже быстрее, чем у большинства, уловка в том, что сложнее измерить .

Лично лучшее, что вы можете сделать в этот момент, - это измерить себя. Предоставьте себе отзывы о том, как вы работаете, возможно, простые изменения в ваших рабочих привычках могут сделать вас более продуктивными.

Я обнаружил, что письма съедали гораздо больше, чем я думал просто из-за прерывания. Теперь я только отвечаю на письма дважды в день и получаю почти 1 час производительности несколько дней. Попробуйте такие методы, как pomodoro , я использовал его как средство измерения. Через равные промежутки времени (15 минут) я хотел бы отметить, что я делал в то время. Это позволило мне увидеть, как мои дни были структурированы и что я мог сделать, чтобы повысить эффективность.

ответил kevin cline 28 Mayam12 2012, 10:08:34
0

Преимущество Squeak для быстрого кодирования выходит далеко за рамки только «оттачивания навыков ООП». Существует причина, по которой современные GUI, а также IDE были изобретены на Smalltalk, не говоря уже о том, что JUNIT был портом SUNIT для Java, термин OOP был изобретен для описания Smalltalk и т. Д. И т. Д.

Нужно всегда использовать язык и среду, наиболее подходящую для того, что можно надеяться достичь, но для общего прототипирования, по крайней мере, я бы сравнил писк с чем-либо, за исключением, возможно, HyperCard, и даже это потребовало бы бенчмаркинга посмотрите, что было на самом деле быстрее, учитывая, что в Squeak есть встроенные гиперкарповые объекты.

ответил kevin cline 28 Mayam12 2012, 10:08:34

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132