Если человек сидит на одной работе над одним проектом то он не будет развиваться (какой нибудь внутренний софт).
Если человек получил удачный опыт и постоянно его везде использует то он не будет развиваться (некоторые гуру которые «знают» как правильно делать).
Про производительность могу сказать только одно, проекты разного размера требуют разные подходы. Если проект больший, то «быстрота» выполнения задачи не нужна (иногда запрещена), требуется следовать некоторым принципам и методологиям. Если же проект маленький, то требуется именно методичная реализация небольшого функционала. Отсюда все проблемы в том числе и холивар по поводу оверинженеринга.
У термина АОП есть волне нормальный используемый термин — «проектировщик». И программу программист не пишет а разрабатывает. В термин «разработка» входит аккурат проектирование и реализация.
Только гуру собеседование не пройдет, вакансии архитекторов почти не выкладывают, растят изнутри. И если его даже пригласят (заманят пожурив этой вакансией) то собеседовать будут прикладные программисты и задавать будут вопросы по фреймворкам.
Я конечно далеко не гуру, но на вопрос «как сделать что то во таком то фреймворке», мой ответ — «все описано в документации» никого не устраивает. Т.е. получается я настолько неуч что даже на прикладника не тяну, куда мне выше вакансию предлагать. Извиняюсь, наболело.
Покупаю. Я веду опен сурс проекты, и разрабатываю другие приложения. Так же дома обычно доступны рабочие проекты для удобства разработки, и программы привязанные в компу тут проблематичны.
Но ответ мне ясен, спасибо.
А какая целевая аудитория вашего продукта? Я, например, обычный программист, я зарабатываю вроде как неплохо, но 250 для меня как то не комфортно, к тому же всего на год. Или целевая аудитория это фирма с одним программистом?
>>Аккуратное использование стековых объектов позволяет создавать очень эффективный и безопасный код, где, в отличие от систем со сборкой мусора, сохраняется локальность ссылок, что дает возможность уменьшить число обращений к системе за памятью, снизить её фрагментацию, более эффективно использовать кэш памяти.
Не понял причем тут GC. В момент выброса исключения требования к объектам очень жесткие, если соблюдать те же требования в любом другом языке с GC то будет тот же результат.
Спасибо. Но я взял канонический формат RIFF, который настолько простой что любой кто сам захочет написать что то подобное напишет его же. (имя чанка + размер чанка + данные)
Самый простой пример, передать буфер вершин (килобайты флоатов). Аккурат такая задача была, смотрел различные форматы, почти везде такая же схема как и в этом примере. В итоге остановился на RIFF контейнере.
Извините за оффтоп. Никогда не понимал кодестайлы где приватные поля идут первыми. Публичные методы класса есть его интерфейс (логический) и когда он сверху то быстрее вникнуть в роль класса.
Мне кажется там чаще ошибка неправильного начертания чем пропусков палочки. Человек после надписи смотрит на свое творение, и если там пропущена палка то он это видит а если ошибка начертания то может не заметить.
>>Мне было немного странно видеть, что в таком замечательном ресурсе мало обсуждения и самой темы о торговых марках, то есть наименовании IT продуктов и компаний (“торговой марки”, “торгового наименования”, “ТМ”, “trademark”). Очевидно, что любой программист и участник IT рынка (а особенно те, кто пишут свои продукты), рано или поздно столкнется с этим вопросом.
Просто любой программист сталкивался с тем что самое сложное в программировании это придумывать названия переменных.
Если человек получил удачный опыт и постоянно его везде использует то он не будет развиваться (некоторые гуру которые «знают» как правильно делать).
Про производительность могу сказать только одно, проекты разного размера требуют разные подходы. Если проект больший, то «быстрота» выполнения задачи не нужна (иногда запрещена), требуется следовать некоторым принципам и методологиям. Если же проект маленький, то требуется именно методичная реализация небольшого функционала. Отсюда все проблемы в том числе и холивар по поводу оверинженеринга.
Я конечно далеко не гуру, но на вопрос «как сделать что то во таком то фреймворке», мой ответ — «все описано в документации» никого не устраивает. Т.е. получается я настолько неуч что даже на прикладника не тяну, куда мне выше вакансию предлагать. Извиняюсь, наболело.
Но ответ мне ясен, спасибо.
Я вот это комментировал.
Просто любой программист сталкивался с тем что самое сложное в программировании это придумывать названия переменных.