Бинарная независимость — это основная идея плагинной архитектуры. Разработчик пишет хост и предоставляет возможность расширения функционала без перекомпиляции хоста.
COM не всегда подходит. Есть плагинные архитектуры, напоминающие COM, например, VST. Есть плагинные архитектуры на основе виртуальных функций (AviSynth), на основе посылки сообщений (OpenFX), как в бинарной форме, так и в текстовой. Есть разные подходы к тому, как регистрировать плагины, через доступ к структуре памяти со списком функций, через отдельные функции по типу dll, через бинарные ресурсы (Photoshop SDK).
В некоторых случаях выбор плагинной архитектуры затрагивает вопросы законности, например, связывание GNU GPL кода с проприетарным кодом. Иногда это обходится плагинной архитектурой с вызовов плагина как отдельный процесс и общение с ним через пайпы консоли.
У вас, вероятно, мало опыта в данных вопросах. Лично я писал плагины к разным программам на VC++, GCC, C и Delphi на профессиональной основе. Также использовал плагины, написанные на разных языках.
А вопросы ABI-совместимости C++ в плагинной архитектуре — широко известная проблема.
Мои замечания про std: связаны с наглядностью примеров, поясняющих возможности вашего кода для потенциальных потребителей. Примеры пишутся для того, чтобы быстро ввести в курс дела новичка дать ему базовое понимание о том, для чего нужен ваш код и подходит ли он ему. Обилие std: и новых фич языка (в том числе очень спорных, о каких уже высказались в других комментариях) говорит о том, что вы показываете не возможности самого плагина, а свое знание новых фич C++. Поэтому я еще писал про поиск работы.
>Мой код завязан на эти фичи потому что они уже здесь, грядут, идут и используются (ну или готовы чтобы их использовали).
Рекомендую изменить свой взгляд в сторону понимания бизнес-задач ваших пользователей. Это вам интересно использовать новые фичи стандартной библиотеки или языка. А пользователю интересно другое: решает ли ваш код его задачи, насколько применение вашего кода упростит его разработку, как внедрение вашего кода повлияет на его цели.
И даже если вы разрабатываете плагинную архитектуру для внутренних целей, следует учитывать вопросы бизнеса, в структуре которого вы находитесь как наемный работник. Порог входа, о каком вы говорите — это дополнительные затраты бизнеса на программистов. Чрезмерное усложнение кода самым последним, самым модным — это большая нагрузка на junior программистов, что повлияет на устойчивость бизнеса и повышение затратов на персонал, повышение затрат на кодирование, поиск ошибок и сопровождение вашего кода.
Также стремление ко всему самому новому может обернуться неожиданными ограничениями, о которых пока не известно. Вы же пишите плагинную архитектуру. Представляете, какие сложности по ее изменению возникнут потом, когда вдруг ваши технические решения окажутся неудачными и придется или мириться с этими сложностями и ограничениями или полностью все переделывать? Уже коллеги вам сказали про проверку типов. Мало того, что это небезопасно, это еще усложняет понимание кода, раздувает его, что обязательно приведет в дальнейшим проблемам: разработчики будут тратить больше мысленных усилий на чтение и понимание кода и будут делать в итоге больше ошибок, удерживая значительную часть памяти ненужными усложнениями.
Надеюсь, мои комментарии были полезны для вас и развития других читателей. Пишу больше для аудитории, а не только для автора статьи. Поэтому не воспринимайте их как критику именно вас или вашего опыта.
Вопросы «зачем нужен плагин» и последующий «зачем нужна возможность писать плагин на разных языках» возникает из бизнес целей архитектуры Хост ⇄ Плагин.
Плагины помогает программу делать более популярной и более привлекательной для пользователей. Также это помогает независимым разработчикам реализовать возможность построить бизнес на разработке плагинов. Некоторые инди-разработчики и даже целые команды живут исключительно с этого дохода.
Некоторые программы специально разрабатываются как хосты для совместной работы плагинов независимых разработчиков, имея только базовый, ограниченный функционал, но большую экосистему плагинов. Большинство хостов для обработки видео, аудио, изображений, текста немыслимы сейчас без возможности установки сторонних плагинов.
Для конечных пользователей это возможность кастомизировать применение программы в своей области. Пользователем может быть и крупный и мелкий бизнес, где есть свой штат программистов.
Чем проще написать плагин, чем популярней программа, — тем больше шанса, что плагинная архитектура будет задействована. И для этой задачи задача разработчика хоста — сделать эту архитектуру доступной, простой, ясной и привлекательной для разработки.
Стандартный подход для обеспечения возможности писать на разных языках обеспечивается средствами операционной системы делить программы на независимые бинарные модули (dll, so, dylib). Можно вызывать как код из бинарного модуля и наоборот.
Возможно написание плагинов, используя другие средства, например IPC, named pipes, вызов через потоки ввода-вывода консольного интерфейса. Если бинарная возможность ограничена, сторонний плагин может быть загружен и задействован исключительно средствами самой хост программы в виде конфигурационных файлов, скриптовых файлов на разных языках, в том числе специфичных для хоста.
Рекомендую прибегнуть к поисковикам, чтобы рассмотреть эту тему шире.
Плагины подразумевают бинарную независимость хоста от модуля расширения. Чтобы можно было писать на разных компиляторах. У вас, правильней назвать, не плагины, а модульный дизайн.
Имею несчастье пользоваться неудачно-разработанной плагинной системой, где тоже С++. Хуже решения не придумать. Только один компилятор и трудности изменения API. Если хочется хорошую плагинную систему и оставить C++, лучше сделать прослойку: C++ на хосте оборачивается в C вызовы. А в хидере для плагина C вызовы оборачиваются снова в C++. В итоге можно пользоваться и С и C++. И не забывать важную идею: в плагине и хосте разные менеджеры памяти: где память выделили, там ее и надо освобождать.
Насколько я понял, вас интересует обратная связь. Вот мои размышления:
А про код сказать мало что могу, потому что не вникал. Я предпочитаю, чтобы код был как можно более проще, чтобы видя несколко десяток строк одновременно, было сразу ясно, что это и как это работает. А у вас слишком много модного C++, слишком многословно, слишком расточительно и от std:: рябит в глазах. Т.е. прямая противоположность того, что я считаю красивым и удобным кодом.
Как я понимаю, вы это писали, видимо, для резюме, чтобы показать свои знания модного C++. Ход может быть неплохом, чтобы найти работу. Но обычно в коммерческом программировании важно не знание самого модного, а умение писать просто и элегантно по принципу KISS.
Простота обеспечивается как техническими решениями, так и простотой с точки зрения того, кто будет пользоваться вашим кодом. Обилие всевозможных фич C++ в вашем решении говорит об обратном. Это означает, что ваше решение завязано на эти фичи, что дает меньше гибкости для пользователей вашего кода.
Если хочется применить что-то техническое (типа специфичных фич языка или библиотек), то лучше сначала подумать, можно ли обойтись без этого, есть ли другие более элегантные методы достижения технической задачи? По-возмжности, лучше выбирать те решения, какие не ограничивают пользователя, не замедляют программу, не приводят к простыням кода, какой требуется еще написать, чтобы сделать что-то минимально-полезное.
Еще внимательней относитесь к именам. У вас я вижу get и get_plugin, has и другие слишком общие слова. Одинаковые и похожие имена, а также слишком общие названия могут затруднять чтение кода и усложнить понимание того, для чего они нужны.
По поводу шаблонов в API. Старайтесь применять шаблоны, только если они дают элегантное и простое решение технических задач. Использовать шаблоны для создания сахара может быть неудобным решением, поскольку параметры шаблона не очевидны для понимания пользователем кода, что именно туда передается и почему. Всякие <2>, ::_3 и прочее — это коряво и выглядит как хак. К сожалению, в стандартной библиотеке такого полно. Там это делалось для ухищрений. В своем коде ухищряться подобным образом — не лучшее решение для подражания.
Надо смотреть с позиции того человека, кто читает этот текст. Перед тем как он прочитает существительное, нужно определить, знает ли он уже это существительное, нужно ли ему обратить на него внимание. Если да, то the подойдет. Если это просто какое-то не столь важное или неизвестное пока для него существительное, то a подойдет больше. Существование pdf тут не имеет значение. Имеет значение, существует ли образ этого pdf в сознании читающего.
По смыслу получается, что the нужен, ведь пользователь должен понимать, к чему он вводит заголовок.
Однако, последние тенденции текстов для UI таковы, что артикли обычно выкидывают. Посмотрите, например, последние программы от Microsoft. Если решитесь на такое решение, то лучше везде в программе придерживаться этого стиля для однообразия.
PS. Два существительных подряд — неудачно. Я бы избавился от слова checklist в предложении. Оно должно уже быть понятно в контексте. Например, быть в тексте выше, в заголовке или в пояснительном тексте под заголовком. Иначе пользователю будет не ясно, что он должен вводить и для чего.
Пришел к аналогичному интуитивному пониманию языка через множество лет постоянного чтения и (главное!) написания текстов. Так сформировался некоторый внутренний промежуточный язык смыслов, где все эти сложные времена существуют в виде законченных понятий (у вас в статье как «чукотский стиль») на некотором универсальном образном языке. Если этот внутренний язык переводить на английский, все получается буквально, как пишется! Никаких волевых усилий не требуется при составлении и понимании текста. Если же переводить на русский, то получается громоздко, потому что в русском языке так не выражаются (у вас в статье как «пафосный стиль»).
Еще дополню по поводу артиклей. Там аналогичная ситуация. Не понимаю, как можно их путать и употреблять неправильно, если на внутреннем образном представлении всегда имеется некоторая «ссылка», показывающая некоторый «статус» существительного. В русском языке такой статус не нужен, поскольку существительные уже имеют гораздо более красочные статусы за счет большого количества суффиксов и прилагательных. В английском с этим туго, поэтому артикли восполняют пробел многообразия оттенков. И, самое главное, без знания этого статуса сложно понимать, о чем идет речь.
Поэтому дополню: в английском каждое существительное должно иметь статус:
указательный (the), неопределенный/неизвестный (a), очевидный (без артикля). Чтобы понять, какой артикль использовать, что он означает, думайте с точки зрения управления вниманием. В английском всегда нужно это учитывать. Прежде чем что-то сказать кому-то, нужно соединить к существительному этот статус, чтобы собеседник понял, на что ему обратить внимание.
И расширю это понимание. Артикль — это самое главное, с чего надо начинать, вводя в фразу какую-то сущность. Он главней и подлежащего и сказуемого. Это не некоторая искусственная прибамбаса к слову, а очень важное слово, помогающее направлять внимание.
Например, мне нужно сказать, что я вчера сидел за компом весь день. Представив это, начинаем формировать лингвистический образ по частям:
* I — в образе существую я. Это очевидность, поэтому артикль не нужен.
* was — этот образ простого воспоминания, или had — это будет важно для того кому говорю.
* working — в образе у меня имеется статус меня, длительно работающего. Это не глагол а состояние глагола — настолько длительное состояние, что оно закостенело и поэтому нужно -ing.
* on the — если нужно сказать про известную человеку вещь или on a, если человек не знает эту вещь.
* computer — теперь стало ясно, что это за вещь. Мне то было ясно изначально, но для управления вниманием надо было сначала применить артикль, чтобы собеседник понял, что я сейчас укажу на какую-то вещь.
* all the — дальше упомяну день, но хочу показать важность того что это было вчера и весь день, а не кусочек. Или all day — если очевидно, что это был просто день. A day (с артиклем a) не подходит, потому что это и так очевидно что речь идет про вчерашний день.
* day — а вот и появился образ того, в чем я работал.
Внимание, перед множественным числом артикль не надо ставить не потому что таковы правила, а потому что тут очевидна множественность. Но если нужно специально выделить множественность, будет не лишним добавить the. Для русского языка все одно, но мы наделяем статусом несколько объектов и этот нюанс будет понят англичанину.
Так получается универсальный конструктор слов из образов, в какой добавляются дополнительные статусы, в каком я управляю вниманием собеседника или дополнительно формирую статусы, чтобы изменить оттенок смысла.
Когда читаешь чужой текст, эти образы уже формируются автоматически, но когда пишешь или говоришь сам, все это нужно учитывать. Поначалу это непривычно и противоестественно для русского языка, где можно просто сыпать поток образов, облекая их в суффиксы и окончания. В английском нужно следить за тем что сказать в первую очередь, а что потом и не забывать о статусах. Потом, спустя некоторое время, сформируется некоторое внутреннее чутье — что выбирать сначала, а что оставлять на потом. Так составление фраз станет быстрым и естественным. А уж о том, какие времена и какие формы глаголов надо употреблять — такого и вовсе не будет в таком чутье.
Не забьвать постоянно надо думать о статусах. Например, если хочется скрыть ответственность, то надо на первое место поставить вещь, над которой делается какое-то действие (passive), если же хочется явно указать на ответственное лицо, то оно указывается первым. А дальше — только подбирать нужные слова, не думая о временах, формах глагола и прочей зауми — все получится правильным и так, без знания каких-то правил. В дальнейшем для разнообразия и некоторого творчества, можно постепенно добавлять сложные грамматические элементы. Но это уже будет расширенное владение языком.
Совершенно верно. У меня нет серьезных замечаний. Я добавил те аспекты, какие балансируют понимание рефакторинга.
Еще немного дополнений с практической стороны:
Наилучшая стратегия для рефакторинга — делать его тогда, когда код меняется, когда старое состояние кода начинает мешать дальнейшей разработке или планируемым позже изменениям. «Мешать» — это когда хочется обойти код заплатками, надстройками и прочей «изолентой». Или когда спотыкаешься о код и видишь, что это тормозит работе и даже мешает. Но не когда испытываешь эстетическое неприятие кода. Даже идеально написанный код может быть эстетически неприятным. Не все алгоритмы красивы, некоторые уродливы. И никаким рефакторингом это уродство не убрать.
Рефакторить код там, где его не видно лично программисту, не надо. Не надо специально выискивать плохие места и специально уделять часть времени на такой поиск и такое «сервисное обслуживание». Рефакторинг должен быть частью изменения кода.
Даже если в программе есть места, какие «воняют» очень сильно, но их не видно за интерфейсами или приватным кодом, не надо ничего там менять. Это место работает и не мешает всему остальному. Вот когда начнет мешать, тогда и надо будет рефакторить. Только надо понимать, что мешать приватный код может только тогда, когда на уровне абстракции выше от него требуется решение задачи с иными требованиями. И тут, возможно, не рефакторинг понадобится, а разработка более соответствующего требованиям модуля.
Если делать рефакторинг вовремя, то его сложность и цена изменений становятся небольшими. Если делать раньше или делать «от нечего делать» или «для красоты» — это пустая работа. У меня было много опыта наведения лоска на код, какой потом приходилось сносить полностью. Когда видишь, сколько впустую потратил на это времени, начинает доходить.
Баланса достичь трудно, если не смотреть на код системно. К сожалению, системный взгляд приходит только с опытом.
Это можно ускорить, если начать читать книги:
1. Классиков Agile. Из Agile пришел рефакторинг таким, каким мы его сейчас знаем. Там это — основной инструмент, потому что приниципы разработки предполагались как постоянное изменение кода в условиях неизвестности. Даже если разработка не ведется по идеологии Agile, можно перенести параллели на свои проекты и смотреть, как что меняется и почему.
2. По системному анализу и теории систем. Сейчас это преподают в ВУЗах как стандартный предмет. И это правильно. Сейчас программирование настолько сложное, что нельзя ухватить все в уме. Системный взгляд позволяет успешно проектировать и менять код в таких условиях.
Также рекомендую вести свой личный проект помимо основной работы, как тренировочный инструмент. Меняйте проект после каждой версии так, чтобы не просто добавлять какие-то функции, а менять что-то серьезное (мажорные изменения версии). Как упражнение, можно сделать плавную переделку в совсем иное. Но не переписывать с нуля! Это поможет лучше понимать, как проектировать устойчиво к изменениям, когда и как делать рефакторинг.
Касаемо бизнеса. Чтобы лучше понимать бизнес, нужно самому иметь свой бизнес. Для программиста возможность лучше понимать бизнес — это подработки или shareware. Или совсем иные сферы, но касаемо своих хобби. Пока нет своего бизнеса, пока сам не принимаешь бизнес-решения и не видишь последствия, взгляды на бизнес в целом могут быть верными, но нюансы решают все.
Рефакторинг нужен для одной вещи — обеспечение устойчивости к изменениям. Когда проект разрабатывается или модифицируется, разница между планируемой архитектурой и действительным положением вещей постоянно увеличивается. Это происходит потому, что в самом начале неизвестно, как на самом деле все будет работать в релизе, как этот код придется изменять. Постепенно первоначальные представления о продукте меняются и отлично-спроектированный код постепенно перестает быть отлично-спроектированным для изменившихся условий. Вот тогда и осуществляется рефакторинг.
Изменения могут быть на разных уровнях: и на уровне архитектуры и на уровне какой-то одной мелкой функции. Поэтому и рефакторинг может быть на разных уровнях.
Например, программист Вася планирует реализовать алгоритм и вводит в свою мелкую функцию переменную Counter. Он называет так ее потому, что на этом этапе он так думает. Но по мере разработки он понимает, что название было неудачным и начинает мешать ему лично лучше понимать код. Т.е. условия изменились и примененное техническое решение (переменная и ее название) уже не соответствует текущему состоянию кода. Он делает рефакторинг на своем уровне, переименовывает эту переменную. Теперь новое название Item больше соответствует текущему состоянию кода.
Усложните этот пример, увеличив уровень абстракции, и вы увидите, что подобные вещи постоянно происходят и там. Неудачно названа функция, неудачно выбраны параметры и их типы, структуры данных хранят много всего, что нужно переносить в другое место, некоторый код слишком сложно написан, некоторая часть кода вообще не ясно как работает, а эта подсистема имеет слишком много лишних связей с другой подсистемой. Все это мешает дорабатывать и менять код на каждом из уровней.
И рефакторинг имеет ценность для бизнеса. Если программист или менеджер проекта не видят этой ценности, то это означает лишь одно: эти лица не понимают, как себя ведет продукт в изменениях.
Рассматривайте рефакторинг как заточку инструмента. Можно работать тупым ножом, но лучше его заточить. Работать станет быстрее и приятнее.
Или рассматривайте рефакторинг как приваривание ушек для крепления одной тяжелой конструкции к другой. Можно без этих мест крепления привязать веревочками или изолентой прикрутить, поначалу все будет работать, но потом нас ждет катастрофа.
Обычно программист не доводит себя до катастрофы, пытаясь переписать код или ища возможность все-то прикручивать сваи не изолентой, а стальным тросом. И мучается, постоянно борясь со сложностями и неудобствами. В итоге его производительность падает, код становится ненадежным, изменение становится настолько дорогим, что программист всячески избегает изменений. Тупик. И бизнес за это платит! Незаметно из кармана владельца уходят суммы, сравнимые с зарплатой программистов. А программисты работают в более сложных условиях, мучая себя и желая избегать работу. Или и вовсе, начинают подумывать об уходе.
Так что, если хочется мазохизма, если хочется побольше вбухать бабла в программирование, не делайте рефакторинг, спихивайте это на тех, кто придет на ваше место после вашего увольнения, спихивайте на архитекторов, на коллег.
PS. У меня есть проекты, пережившие 12 мажорных версий. Если бы не рефакторинг, я бы уже давно разорился.
Могу сказать по своему опыту как со стороны исполнителя, так и со стороны владельца проектов. Тонкие знания алгоритмов и структур данных на собеседовании не нужны. Это справочные данные, которые всегда можно загуглить. Однако, если кандидат вообще ничего не знает что это такое, не понимает особенности и ограничения, то он не сможет найти и подобрать оптимальную реализацию или не сможет понять код.
На мой взгляд, требование у доски на собеседовании рассказывать какие-то тонкости и хитрости — это чрезмерно, достаточно, что у кандидата есть обзорные знания. В моей работе алгоритмы и структуры используются почти в каждом проекте, и особенно в многопоточной среде. Использование этого дает конкурентное преимущество и вообще способность создавать адекватные рынку решения.
А касаемо списков — это тот минимальный уровень владения алгоритмами, который реально нужен почти в каждом проекте. Деревья у меня почти не используются (кроме реализаций стандартных библиотек), но списки практически повсеместно. И списки самые разные. Умение писать список и работать с ним, на настоящий момент времени, — это основной навык после умения писать циклы и работать с граничными условиями. Редко в каком коде не используется динамическая память, так что объекты, так или иначе, надо группировать и как-то проходить по ним. Минимум — это связывать их в список.
Правильней всего «продавать себя», пользуясь «глупыми» вопросами. То как отвечать, зависит от того, кто вас собеседует. Если это HR менеджер, то он оценивает психологию человека, его адекватность и его карьерный потенциал. Если это технический руководитель, то ему нужно оценить пригодность кандидата к конкретной работе. Если это просто типовой сотрудник, то, скорей всего, собеседование будет напоминать экзамен. Если это директор предприятия, ему нужно оценить перспективность кандидата, его стоимость и расходы на его содержание. Так что, всегда интересуйтесь, кто именно перед вами и попробуйте определить, какова сфера его ответственности.
Кем видеть себя через пять лет — это не совсем идиотский вопрос. Он слишком заезженный, и задается порой не в тему, отсюда и кажется глупым. Работодатель хочет оценить амбиции человека и его способность к саморазвитию без того, чтобы его гнать в эту сторону. Можно смело рассказать о ваших планах развиваться как профессионально, так и человечески, включая культурный уровень, достижения в хобби и т.п. Глупым ответом на этот вопрос будет ответ в духе «в вашей компании я стану руководителем» (или иные карьерные изменения). Еще вообще ничего не известно о компании, о работе, о принципах и правилах, а кандидат уже губу раскатывает.
Умение находить несколько альтернативных решений — ключевой навык сильного инженера. Насколько я понял диалог, собеседующие решили потянуть кандидата на уровень выше.
Откуда взяться опыта у человека, кто только вчера научился писать циклы? Умение проектировать и писать код, которому жить и жить, переживать изменения, вплоть до полной переделки, без потерь и потрясений потребителей этого кода, дается только с опытом участия во многих проектах самой разной направленности, с самыми разными технологиями, как с самыми свежими, так и с теми, которым десятки лет. В умении запоминать библиотечные функции и стандартные приемы работы с фреймворками нет ничего выдающегося — это простая зубрежка или природная хорошая память. А опыт писать надежный и изменяемый код набирается годами граблей, бессонными ночами, сотнями часов в отладчиках, сотнями часов раздумий в поиске решений в нетривиальных положениях.
Потом, ничего принципиально-нового со времен 70-х годов пока не сделано. Все что преподносится как новые технологии — все то же программирование на тех же самых принципах. Опытный программист легко переключается между инструментами, языками, библиотеками. А специфические технологические вещи пишутся учеными, потом подхватываются технологическими компаниями, и лишь потом эти технологии становятся доступными тем, кого набирают на работу через резюме. И уже эти технологии обрастают пачками научных работ, готовых библиотек, сред и подготовленной информацией в интернет, коммерческими компаниями, специализирующимися на популяризации перспективных направлений. Простого Васю не возьмут по резюме разрабатывать супер-новую, никем не виданную технологию. Этот Вася должен сначала засветиться в этих средах как специалист, подходящий для разработки новой технологии.
Дополнение. Если ощущаете, что кандидат технически подкован, не останавливайтесь на этом уровне, а спросите его о том, какие меры он принимает для борьбы со сложностью и что он будет делать с унаследованным кодом. Есть программисты, кто все выучил наизусть, блестяще разбирается в каких-то деталях, но результат, какой они получают, соответствует только их реальному опыту как кодировщику, умеющему писать код по заданию руководителя. Также есть специалисты, кто привык к идеальньму коду, но не смогут нормально работать с реальным кодом обычного качества, считая, что у организации есть деньги на полную переделку и наведение лоска.
Технически-знающий детали специалист может вызвать ошибочное представление о себе как о кандидате высокого уровня. И получаем «сеньоров» с опытом работы в 1-2 года.
Большая часть новичков не сможет адекватно держать сложный проект в рабочем состоянии. Можно наизусть знать фреймворк, библиотеку, разбираться в тонкостях языка, в паттернах, но создавать код, живущий только одну версию, до первых модицикаций. Дальше все скатывается в тягую неповоротную смесь кода, какую сложно модицифировать и развивать. Особенно актуально для продуктовых компаний.
Сейчас и телефоны за $100 подвержены этому. Это не недоработка самого телефона, а именно проблема дизайна UI, связанная с тем, что интерфейсные элементы располагаются по краям экрана.
Имею 5.5" телефон на андроиде с узкой рамкой в 3мм. По сравнению с телефоном 4" на Symbian с рамкой в 5мм, из-за большого размера и веса самого телефона приходится охватывать сильнее корпус. Кожа пальцев в итоге налезает на интерфейсные элементы с краю. Аналогичной проблемы с Symbian телефоном нет — там практически нет таких элементов, плюс размеры и вес способствуют менее сильному сжатию в руках и более-специфическому навыку держания за край. Современные лопаты вообще невозможно держать только за край из-за размеров и веса.
Рекомендации разработчикам и дизайнерам: с краев экрана убрать интерфейсные элементы, реагирующие на касание. Соблюдать отступ хотя бы 7 мм. Проведите опыт: охватите телефон рукой и посмотрите, насколько кожа пальцев распределяется по краю.
Еще типичная проблема дизайна с краев экрана: текст и другие элементы располагаются на контрастной границе белое-черное, что резко снижает читаемость текста. Плюс, эта контрастная полоса приводит к сильному отводу внимания на себя. В итоге элементы с краев экрана становятся менее визуально-заметными. Все внимание захватывает область границы.
Есть разница между SDK 7.1 и 10: например, разные версии DirectX, кое-какие хидеры и определения отсутствуют. База Win32, конечно, совпадает. Если проект старый и там все старое используется, это конечно может не подойти. А если предполагается разработка нового проекта, но не хочется потерять совместимость с XP, можно попробовать сразу использовать SDK 10. Так и совместимость останется, и можно будет пользоваться возможностями Window 10, не заморачиваясь с хидерами.
Microsoft Visual Studio 2017 поддерживает компиляцию для XP. Нет необходимости отказываться от фич C++14 и 17. Для поддержки достаточно включить поддержку XP в хидерах -D_USING_V110_SDK71_ компилятора, а в линковщике указать /SUBSYSTEM:WINDOWS,5.02 для 64-битных сборок или /SUBSYSTEM:WINDOWS,5.01 для 32-битных. Использовать Windows SDK 7.1 не обязательно. Оно уже хорошо работает и с Windows 10 SDK. Насчет совместимости этого со сборкой Qt ничего не могу сказать.
Чтобы обучиться работать с новым фреймворком или библиотекой, достаточно пары недель, а не пол-годика. Чтобы вникнуть в основы, достаточно нескольких часов.
В реальной работе программист всегда работает с неизвестной для себя областью знаний. Это и бизнес-логика, и новый инструментарий, и новые алгоритмы. Да и вообще он создает новое, то чего не было раньше. Условия меняются очень быстро и приходится порой полностью переделывать уже написанное.
Нет никаких полгода для изучения чего-то нового. Это когда сам студент и есть море свободного времени после посещения учебного заведения — бери да изучай. Только вот через годик мода пройдет на изучаемое — и полученные знания можно смело выкидывать в корзину. Лучше это время потратить на базу программирования. Сейчас не те времена, когда программистов готовили к работе загодя и этого было достаточно.
Для новичков лично я рекомендую учиться работать с элементарным: уметь реализовывать алгоритмы и структуры данных без стандартных средств языка и библиотек, расширять свой кругозор в архетиктуре компьютерных технологий, изучать самые разные области программирования и языки, изучать чужой код. Нужен кругозор того что есть и глубина понимания базы. Доскональное знание чего-то одного не нужно.
И самое главное — рекомендую делать свои личные проекты. Потому что когда делаешь свое — приходит понимание в том как реализовывать задумку в условиях, приближенных к настоящей работе.
А лучше — не просто делать проекты и бросать, а постоянно их совершенствовать. Когда начнете совершенствовать свой личный проект, придет и понимание, как программировать плохо; и самое главное — почему это плохо. Придет понимание, что прежде чем что-то запрограммировать, надо думать и учитывать много факторов, какие не видишь с самого начала и даже не можешь их загодя просчитать. И придется даже учитывать изменение фреймворков и библиотек! И опа — приходит понимание, что надо было не фреймворк учить, а учиться проектировать и программировать. А это нудно и не вовсе не модно. И результат не такой модный и красивый, да и почти незаметен.
Постоянно вижу в среде новичков кучу мифов и табу, а понимания нет. И возникают перлы типа: Писать следует исключительно только и только в ООП, использовать следует только новомодный фреймворк X, ни в коем случае не использовать вот этот оператор языка, всегда использовать только это новое средство языка вместо другого и т.п. Да нет же! Все хорошо, когда применено по месту. Только вот новичок заучил эти табу, но не понимает, что в большинстве своем коде он делает другие ошибки, о каких не модно кричать на форумах и какие не видишь сразу.
Вот именно такой опыт и нужен в программировании. И таких программистов катастрофически не хватает. Вызубрить что-то чтобы пройти собеседование — это тупик. Может подойти для совсем новичка, только вот в реальной работе для такого новичка это вызубренное не поможет, потому что сразу дадут задание, какое он никогда не реализовывал и, может быть, впервые в жизни видит. И сидят в шоке: «как же так, я вызубрил знание фреймворка, а надо реализовывать фичу и при этом разбираться в непонятном коде, копаясь в мегабайтах чужих исходников не самого идеального кода, да и еще надо это сделать к сегодняшнему вечеру!».
Такая вот жесть в собеседованиях неспроста. Чтобы понять в чем дело, надо подумать над очень неудобными темами.
Цель компании — деньги любой ценой. Компаниям не нужны программисты сами по себе. Программист не приносит деньги напрямую. Над ним нужен надзор, ему еще надо задания давать, проверять, тестировать, следить чтобы он работал, а не сидел в интернете. Столько с ним мороки!
Программист со средними способностями не нужен — будут искать такого же, но очень дешевого. Программист, кто не будет стоять по струнке и бодро выкрикивать «ку» — тоже не нужен. Поэтому самодовольные, кому что-то не нравится на собеседованиях — пусть побыстрей отваливаются. Будем искать покорного, трудолюбивого.
Программисты, кто работал в других темах, с другими фреймворками, с другими задачами — тоже не нужны. Компании не настолько богатые, чтобы платить деньги работникам, чтобы переобучать программистов. Вы же программисты — должны все знать в совершенстве, а не знаете — не компетентны.
Программист не знает алгоритм сортировки? Отлично — это повод снизить ему зарплату в два раза. Компаниям не нужны алгоритмы сортировки, но любой прокол программиста на собеседовании — отличный повод несколько месяцев платить ему сниженную зарплату.
Программист любит качественный код, продуманную архитектуру? Это жесть! Компания не будет ждать высокоинтеллектуальные изыски. Надо чтобы было готово уже вчера. И программиста будут гнать на работе до изнеможения, чтобы еле успевал за выходные восстановиться.
Программист очень молод? Отлично. Будет работать за десятерых, пока молодость позволяет, да и еще не надо ему оплачивать больничные.
А чтобы не просил добавок к зарплате, устроим бег в колесе. Пусть он соревнуется с другими программистами. Сделал работу позже всех, не смог сравниться с большинством выживших — ты нам не подходишь, работаешь медленно и не вписываешься в план. Не успеваешь делать красивый код и в гонке пишешь говнокод — ты нам тоже не нужен.
Чтобы уж точно обезопасить себя от дорогих программистов, устроим испытательный период в три месяца и без какой-либо оплаты или будем платить меньше чем уборщице. А зачем платить больше? Ведь три месяца для компании — это халява. Плюс всегда можно уволить особо недовольных, неповоротливых или средних — они же согласились на наши шулерские правила игры с испытательным сроком.
Вот так вот. Как любят говорить «это бизнес, детка!»
А как быть тем кто горд, самолюбив, медленно пишет код, больше думает, чем пишет, не хочет на халяву писать тестовые задания, не хочет терпеть экзамены-унижения на идеальное знание?
Вы подаете резюме не в те компании и не на те позиции. Ваша квалификация выше тех позиций, на какие расчитываете. И вы идеально годны на работу в адекватные компании. Но сильно не зазнавайтесь, там халявы тоже не будет.
Ваш выбор — соглашаться на жестокие правила игры или играть в свои игры, где ваша жизнь в выигрыше.
Серьезная опечатка. Исправить в тексте не могу, нет полномочий. В конце следует читать так: И не беритесь бойтесь брать ответственность.
Дело в том, что всегда работаешь на свое развитие. Поэтому выход из своей зоны комфорта необходим. И это основное, что нужно в инженерных специальностях. Мы работаем с творчеством и неизвестностью. Здесь нужен результат.
COM не всегда подходит. Есть плагинные архитектуры, напоминающие COM, например, VST. Есть плагинные архитектуры на основе виртуальных функций (AviSynth), на основе посылки сообщений (OpenFX), как в бинарной форме, так и в текстовой. Есть разные подходы к тому, как регистрировать плагины, через доступ к структуре памяти со списком функций, через отдельные функции по типу dll, через бинарные ресурсы (Photoshop SDK).
В некоторых случаях выбор плагинной архитектуры затрагивает вопросы законности, например, связывание GNU GPL кода с проприетарным кодом. Иногда это обходится плагинной архитектурой с вызовов плагина как отдельный процесс и общение с ним через пайпы консоли.
А вопросы ABI-совместимости C++ в плагинной архитектуре — широко известная проблема.
>Мой код завязан на эти фичи потому что они уже здесь, грядут, идут и используются (ну или готовы чтобы их использовали).
Рекомендую изменить свой взгляд в сторону понимания бизнес-задач ваших пользователей. Это вам интересно использовать новые фичи стандартной библиотеки или языка. А пользователю интересно другое: решает ли ваш код его задачи, насколько применение вашего кода упростит его разработку, как внедрение вашего кода повлияет на его цели.
И даже если вы разрабатываете плагинную архитектуру для внутренних целей, следует учитывать вопросы бизнеса, в структуре которого вы находитесь как наемный работник. Порог входа, о каком вы говорите — это дополнительные затраты бизнеса на программистов. Чрезмерное усложнение кода самым последним, самым модным — это большая нагрузка на junior программистов, что повлияет на устойчивость бизнеса и повышение затратов на персонал, повышение затрат на кодирование, поиск ошибок и сопровождение вашего кода.
Также стремление ко всему самому новому может обернуться неожиданными ограничениями, о которых пока не известно. Вы же пишите плагинную архитектуру. Представляете, какие сложности по ее изменению возникнут потом, когда вдруг ваши технические решения окажутся неудачными и придется или мириться с этими сложностями и ограничениями или полностью все переделывать? Уже коллеги вам сказали про проверку типов. Мало того, что это небезопасно, это еще усложняет понимание кода, раздувает его, что обязательно приведет в дальнейшим проблемам: разработчики будут тратить больше мысленных усилий на чтение и понимание кода и будут делать в итоге больше ошибок, удерживая значительную часть памяти ненужными усложнениями.
Надеюсь, мои комментарии были полезны для вас и развития других читателей. Пишу больше для аудитории, а не только для автора статьи. Поэтому не воспринимайте их как критику именно вас или вашего опыта.
Плагины помогает программу делать более популярной и более привлекательной для пользователей. Также это помогает независимым разработчикам реализовать возможность построить бизнес на разработке плагинов. Некоторые инди-разработчики и даже целые команды живут исключительно с этого дохода.
Некоторые программы специально разрабатываются как хосты для совместной работы плагинов независимых разработчиков, имея только базовый, ограниченный функционал, но большую экосистему плагинов. Большинство хостов для обработки видео, аудио, изображений, текста немыслимы сейчас без возможности установки сторонних плагинов.
Для конечных пользователей это возможность кастомизировать применение программы в своей области. Пользователем может быть и крупный и мелкий бизнес, где есть свой штат программистов.
Чем проще написать плагин, чем популярней программа, — тем больше шанса, что плагинная архитектура будет задействована. И для этой задачи задача разработчика хоста — сделать эту архитектуру доступной, простой, ясной и привлекательной для разработки.
Стандартный подход для обеспечения возможности писать на разных языках обеспечивается средствами операционной системы делить программы на независимые бинарные модули (dll, so, dylib). Можно вызывать как код из бинарного модуля и наоборот.
Возможно написание плагинов, используя другие средства, например IPC, named pipes, вызов через потоки ввода-вывода консольного интерфейса. Если бинарная возможность ограничена, сторонний плагин может быть загружен и задействован исключительно средствами самой хост программы в виде конфигурационных файлов, скриптовых файлов на разных языках, в том числе специфичных для хоста.
Рекомендую прибегнуть к поисковикам, чтобы рассмотреть эту тему шире.
Имею несчастье пользоваться неудачно-разработанной плагинной системой, где тоже С++. Хуже решения не придумать. Только один компилятор и трудности изменения API. Если хочется хорошую плагинную систему и оставить C++, лучше сделать прослойку: C++ на хосте оборачивается в C вызовы. А в хидере для плагина C вызовы оборачиваются снова в C++. В итоге можно пользоваться и С и C++. И не забывать важную идею: в плагине и хосте разные менеджеры памяти: где память выделили, там ее и надо освобождать.
Насколько я понял, вас интересует обратная связь. Вот мои размышления:
А про код сказать мало что могу, потому что не вникал. Я предпочитаю, чтобы код был как можно более проще, чтобы видя несколко десяток строк одновременно, было сразу ясно, что это и как это работает. А у вас слишком много модного C++, слишком многословно, слишком расточительно и от std:: рябит в глазах. Т.е. прямая противоположность того, что я считаю красивым и удобным кодом.
Как я понимаю, вы это писали, видимо, для резюме, чтобы показать свои знания модного C++. Ход может быть неплохом, чтобы найти работу. Но обычно в коммерческом программировании важно не знание самого модного, а умение писать просто и элегантно по принципу KISS.
Простота обеспечивается как техническими решениями, так и простотой с точки зрения того, кто будет пользоваться вашим кодом. Обилие всевозможных фич C++ в вашем решении говорит об обратном. Это означает, что ваше решение завязано на эти фичи, что дает меньше гибкости для пользователей вашего кода.
Если хочется применить что-то техническое (типа специфичных фич языка или библиотек), то лучше сначала подумать, можно ли обойтись без этого, есть ли другие более элегантные методы достижения технической задачи? По-возмжности, лучше выбирать те решения, какие не ограничивают пользователя, не замедляют программу, не приводят к простыням кода, какой требуется еще написать, чтобы сделать что-то минимально-полезное.
Еще внимательней относитесь к именам. У вас я вижу get и get_plugin, has и другие слишком общие слова. Одинаковые и похожие имена, а также слишком общие названия могут затруднять чтение кода и усложнить понимание того, для чего они нужны.
По поводу шаблонов в API. Старайтесь применять шаблоны, только если они дают элегантное и простое решение технических задач. Использовать шаблоны для создания сахара может быть неудобным решением, поскольку параметры шаблона не очевидны для понимания пользователем кода, что именно туда передается и почему. Всякие <2>, ::_3 и прочее — это коряво и выглядит как хак. К сожалению, в стандартной библиотеке такого полно. Там это делалось для ухищрений. В своем коде ухищряться подобным образом — не лучшее решение для подражания.
По смыслу получается, что the нужен, ведь пользователь должен понимать, к чему он вводит заголовок.
Однако, последние тенденции текстов для UI таковы, что артикли обычно выкидывают. Посмотрите, например, последние программы от Microsoft. Если решитесь на такое решение, то лучше везде в программе придерживаться этого стиля для однообразия.
PS. Два существительных подряд — неудачно. Я бы избавился от слова checklist в предложении. Оно должно уже быть понятно в контексте. Например, быть в тексте выше, в заголовке или в пояснительном тексте под заголовком. Иначе пользователю будет не ясно, что он должен вводить и для чего.
Еще дополню по поводу артиклей. Там аналогичная ситуация. Не понимаю, как можно их путать и употреблять неправильно, если на внутреннем образном представлении всегда имеется некоторая «ссылка», показывающая некоторый «статус» существительного. В русском языке такой статус не нужен, поскольку существительные уже имеют гораздо более красочные статусы за счет большого количества суффиксов и прилагательных. В английском с этим туго, поэтому артикли восполняют пробел многообразия оттенков. И, самое главное, без знания этого статуса сложно понимать, о чем идет речь.
Поэтому дополню: в английском каждое существительное должно иметь статус:
указательный (the), неопределенный/неизвестный (a), очевидный (без артикля). Чтобы понять, какой артикль использовать, что он означает, думайте с точки зрения управления вниманием. В английском всегда нужно это учитывать. Прежде чем что-то сказать кому-то, нужно соединить к существительному этот статус, чтобы собеседник понял, на что ему обратить внимание.
И расширю это понимание. Артикль — это самое главное, с чего надо начинать, вводя в фразу какую-то сущность. Он главней и подлежащего и сказуемого. Это не некоторая искусственная прибамбаса к слову, а очень важное слово, помогающее направлять внимание.
Например, мне нужно сказать, что я вчера сидел за компом весь день. Представив это, начинаем формировать лингвистический образ по частям:
* I — в образе существую я. Это очевидность, поэтому артикль не нужен.
* was — этот образ простого воспоминания, или had — это будет важно для того кому говорю.
* working — в образе у меня имеется статус меня, длительно работающего. Это не глагол а состояние глагола — настолько длительное состояние, что оно закостенело и поэтому нужно -ing.
* on the — если нужно сказать про известную человеку вещь или on a, если человек не знает эту вещь.
* computer — теперь стало ясно, что это за вещь. Мне то было ясно изначально, но для управления вниманием надо было сначала применить артикль, чтобы собеседник понял, что я сейчас укажу на какую-то вещь.
* all the — дальше упомяну день, но хочу показать важность того что это было вчера и весь день, а не кусочек. Или all day — если очевидно, что это был просто день. A day (с артиклем a) не подходит, потому что это и так очевидно что речь идет про вчерашний день.
* day — а вот и появился образ того, в чем я работал.
Внимание, перед множественным числом артикль не надо ставить не потому что таковы правила, а потому что тут очевидна множественность. Но если нужно специально выделить множественность, будет не лишним добавить the. Для русского языка все одно, но мы наделяем статусом несколько объектов и этот нюанс будет понят англичанину.
Так получается универсальный конструктор слов из образов, в какой добавляются дополнительные статусы, в каком я управляю вниманием собеседника или дополнительно формирую статусы, чтобы изменить оттенок смысла.
Когда читаешь чужой текст, эти образы уже формируются автоматически, но когда пишешь или говоришь сам, все это нужно учитывать. Поначалу это непривычно и противоестественно для русского языка, где можно просто сыпать поток образов, облекая их в суффиксы и окончания. В английском нужно следить за тем что сказать в первую очередь, а что потом и не забывать о статусах. Потом, спустя некоторое время, сформируется некоторое внутреннее чутье — что выбирать сначала, а что оставлять на потом. Так составление фраз станет быстрым и естественным. А уж о том, какие времена и какие формы глаголов надо употреблять — такого и вовсе не будет в таком чутье.
Не забьвать постоянно надо думать о статусах. Например, если хочется скрыть ответственность, то надо на первое место поставить вещь, над которой делается какое-то действие (passive), если же хочется явно указать на ответственное лицо, то оно указывается первым. А дальше — только подбирать нужные слова, не думая о временах, формах глагола и прочей зауми — все получится правильным и так, без знания каких-то правил. В дальнейшем для разнообразия и некоторого творчества, можно постепенно добавлять сложные грамматические элементы. Но это уже будет расширенное владение языком.
Еще немного дополнений с практической стороны:
Наилучшая стратегия для рефакторинга — делать его тогда, когда код меняется, когда старое состояние кода начинает мешать дальнейшей разработке или планируемым позже изменениям. «Мешать» — это когда хочется обойти код заплатками, надстройками и прочей «изолентой». Или когда спотыкаешься о код и видишь, что это тормозит работе и даже мешает. Но не когда испытываешь эстетическое неприятие кода. Даже идеально написанный код может быть эстетически неприятным. Не все алгоритмы красивы, некоторые уродливы. И никаким рефакторингом это уродство не убрать.
Рефакторить код там, где его не видно лично программисту, не надо. Не надо специально выискивать плохие места и специально уделять часть времени на такой поиск и такое «сервисное обслуживание». Рефакторинг должен быть частью изменения кода.
Даже если в программе есть места, какие «воняют» очень сильно, но их не видно за интерфейсами или приватным кодом, не надо ничего там менять. Это место работает и не мешает всему остальному. Вот когда начнет мешать, тогда и надо будет рефакторить. Только надо понимать, что мешать приватный код может только тогда, когда на уровне абстракции выше от него требуется решение задачи с иными требованиями. И тут, возможно, не рефакторинг понадобится, а разработка более соответствующего требованиям модуля.
Если делать рефакторинг вовремя, то его сложность и цена изменений становятся небольшими. Если делать раньше или делать «от нечего делать» или «для красоты» — это пустая работа. У меня было много опыта наведения лоска на код, какой потом приходилось сносить полностью. Когда видишь, сколько впустую потратил на это времени, начинает доходить.
Баланса достичь трудно, если не смотреть на код системно. К сожалению, системный взгляд приходит только с опытом.
Это можно ускорить, если начать читать книги:
1. Классиков Agile. Из Agile пришел рефакторинг таким, каким мы его сейчас знаем. Там это — основной инструмент, потому что приниципы разработки предполагались как постоянное изменение кода в условиях неизвестности. Даже если разработка не ведется по идеологии Agile, можно перенести параллели на свои проекты и смотреть, как что меняется и почему.
2. По системному анализу и теории систем. Сейчас это преподают в ВУЗах как стандартный предмет. И это правильно. Сейчас программирование настолько сложное, что нельзя ухватить все в уме. Системный взгляд позволяет успешно проектировать и менять код в таких условиях.
Также рекомендую вести свой личный проект помимо основной работы, как тренировочный инструмент. Меняйте проект после каждой версии так, чтобы не просто добавлять какие-то функции, а менять что-то серьезное (мажорные изменения версии). Как упражнение, можно сделать плавную переделку в совсем иное. Но не переписывать с нуля! Это поможет лучше понимать, как проектировать устойчиво к изменениям, когда и как делать рефакторинг.
Касаемо бизнеса. Чтобы лучше понимать бизнес, нужно самому иметь свой бизнес. Для программиста возможность лучше понимать бизнес — это подработки или shareware. Или совсем иные сферы, но касаемо своих хобби. Пока нет своего бизнеса, пока сам не принимаешь бизнес-решения и не видишь последствия, взгляды на бизнес в целом могут быть верными, но нюансы решают все.
Изменения могут быть на разных уровнях: и на уровне архитектуры и на уровне какой-то одной мелкой функции. Поэтому и рефакторинг может быть на разных уровнях.
Например, программист Вася планирует реализовать алгоритм и вводит в свою мелкую функцию переменную Counter. Он называет так ее потому, что на этом этапе он так думает. Но по мере разработки он понимает, что название было неудачным и начинает мешать ему лично лучше понимать код. Т.е. условия изменились и примененное техническое решение (переменная и ее название) уже не соответствует текущему состоянию кода. Он делает рефакторинг на своем уровне, переименовывает эту переменную. Теперь новое название Item больше соответствует текущему состоянию кода.
Усложните этот пример, увеличив уровень абстракции, и вы увидите, что подобные вещи постоянно происходят и там. Неудачно названа функция, неудачно выбраны параметры и их типы, структуры данных хранят много всего, что нужно переносить в другое место, некоторый код слишком сложно написан, некоторая часть кода вообще не ясно как работает, а эта подсистема имеет слишком много лишних связей с другой подсистемой. Все это мешает дорабатывать и менять код на каждом из уровней.
И рефакторинг имеет ценность для бизнеса. Если программист или менеджер проекта не видят этой ценности, то это означает лишь одно: эти лица не понимают, как себя ведет продукт в изменениях.
Рассматривайте рефакторинг как заточку инструмента. Можно работать тупым ножом, но лучше его заточить. Работать станет быстрее и приятнее.
Или рассматривайте рефакторинг как приваривание ушек для крепления одной тяжелой конструкции к другой. Можно без этих мест крепления привязать веревочками или изолентой прикрутить, поначалу все будет работать, но потом нас ждет катастрофа.
Обычно программист не доводит себя до катастрофы, пытаясь переписать код или ища возможность все-то прикручивать сваи не изолентой, а стальным тросом. И мучается, постоянно борясь со сложностями и неудобствами. В итоге его производительность падает, код становится ненадежным, изменение становится настолько дорогим, что программист всячески избегает изменений. Тупик. И бизнес за это платит! Незаметно из кармана владельца уходят суммы, сравнимые с зарплатой программистов. А программисты работают в более сложных условиях, мучая себя и желая избегать работу. Или и вовсе, начинают подумывать об уходе.
Так что, если хочется мазохизма, если хочется побольше вбухать бабла в программирование, не делайте рефакторинг, спихивайте это на тех, кто придет на ваше место после вашего увольнения, спихивайте на архитекторов, на коллег.
PS. У меня есть проекты, пережившие 12 мажорных версий. Если бы не рефакторинг, я бы уже давно разорился.
На мой взгляд, требование у доски на собеседовании рассказывать какие-то тонкости и хитрости — это чрезмерно, достаточно, что у кандидата есть обзорные знания. В моей работе алгоритмы и структуры используются почти в каждом проекте, и особенно в многопоточной среде. Использование этого дает конкурентное преимущество и вообще способность создавать адекватные рынку решения.
А касаемо списков — это тот минимальный уровень владения алгоритмами, который реально нужен почти в каждом проекте. Деревья у меня почти не используются (кроме реализаций стандартных библиотек), но списки практически повсеместно. И списки самые разные. Умение писать список и работать с ним, на настоящий момент времени, — это основной навык после умения писать циклы и работать с граничными условиями. Редко в каком коде не используется динамическая память, так что объекты, так или иначе, надо группировать и как-то проходить по ним. Минимум — это связывать их в список.
Кем видеть себя через пять лет — это не совсем идиотский вопрос. Он слишком заезженный, и задается порой не в тему, отсюда и кажется глупым. Работодатель хочет оценить амбиции человека и его способность к саморазвитию без того, чтобы его гнать в эту сторону. Можно смело рассказать о ваших планах развиваться как профессионально, так и человечески, включая культурный уровень, достижения в хобби и т.п. Глупым ответом на этот вопрос будет ответ в духе «в вашей компании я стану руководителем» (или иные карьерные изменения). Еще вообще ничего не известно о компании, о работе, о принципах и правилах, а кандидат уже губу раскатывает.
Потом, ничего принципиально-нового со времен 70-х годов пока не сделано. Все что преподносится как новые технологии — все то же программирование на тех же самых принципах. Опытный программист легко переключается между инструментами, языками, библиотеками. А специфические технологические вещи пишутся учеными, потом подхватываются технологическими компаниями, и лишь потом эти технологии становятся доступными тем, кого набирают на работу через резюме. И уже эти технологии обрастают пачками научных работ, готовых библиотек, сред и подготовленной информацией в интернет, коммерческими компаниями, специализирующимися на популяризации перспективных направлений. Простого Васю не возьмут по резюме разрабатывать супер-новую, никем не виданную технологию. Этот Вася должен сначала засветиться в этих средах как специалист, подходящий для разработки новой технологии.
И еще, про 10 лет в моем тексте упоминания нет.
Технически-знающий детали специалист может вызвать ошибочное представление о себе как о кандидате высокого уровня. И получаем «сеньоров» с опытом работы в 1-2 года.
Большая часть новичков не сможет адекватно держать сложный проект в рабочем состоянии. Можно наизусть знать фреймворк, библиотеку, разбираться в тонкостях языка, в паттернах, но создавать код, живущий только одну версию, до первых модицикаций. Дальше все скатывается в тягую неповоротную смесь кода, какую сложно модицифировать и развивать. Особенно актуально для продуктовых компаний.
Имею 5.5" телефон на андроиде с узкой рамкой в 3мм. По сравнению с телефоном 4" на Symbian с рамкой в 5мм, из-за большого размера и веса самого телефона приходится охватывать сильнее корпус. Кожа пальцев в итоге налезает на интерфейсные элементы с краю. Аналогичной проблемы с Symbian телефоном нет — там практически нет таких элементов, плюс размеры и вес способствуют менее сильному сжатию в руках и более-специфическому навыку держания за край. Современные лопаты вообще невозможно держать только за край из-за размеров и веса.
Рекомендации разработчикам и дизайнерам: с краев экрана убрать интерфейсные элементы, реагирующие на касание. Соблюдать отступ хотя бы 7 мм. Проведите опыт: охватите телефон рукой и посмотрите, насколько кожа пальцев распределяется по краю.
Еще типичная проблема дизайна с краев экрана: текст и другие элементы располагаются на контрастной границе белое-черное, что резко снижает читаемость текста. Плюс, эта контрастная полоса приводит к сильному отводу внимания на себя. В итоге элементы с краев экрана становятся менее визуально-заметными. Все внимание захватывает область границы.
В реальной работе программист всегда работает с неизвестной для себя областью знаний. Это и бизнес-логика, и новый инструментарий, и новые алгоритмы. Да и вообще он создает новое, то чего не было раньше. Условия меняются очень быстро и приходится порой полностью переделывать уже написанное.
Нет никаких полгода для изучения чего-то нового. Это когда сам студент и есть море свободного времени после посещения учебного заведения — бери да изучай. Только вот через годик мода пройдет на изучаемое — и полученные знания можно смело выкидывать в корзину. Лучше это время потратить на базу программирования. Сейчас не те времена, когда программистов готовили к работе загодя и этого было достаточно.
Для новичков лично я рекомендую учиться работать с элементарным: уметь реализовывать алгоритмы и структуры данных без стандартных средств языка и библиотек, расширять свой кругозор в архетиктуре компьютерных технологий, изучать самые разные области программирования и языки, изучать чужой код. Нужен кругозор того что есть и глубина понимания базы. Доскональное знание чего-то одного не нужно.
И самое главное — рекомендую делать свои личные проекты. Потому что когда делаешь свое — приходит понимание в том как реализовывать задумку в условиях, приближенных к настоящей работе.
А лучше — не просто делать проекты и бросать, а постоянно их совершенствовать. Когда начнете совершенствовать свой личный проект, придет и понимание, как программировать плохо; и самое главное — почему это плохо. Придет понимание, что прежде чем что-то запрограммировать, надо думать и учитывать много факторов, какие не видишь с самого начала и даже не можешь их загодя просчитать. И придется даже учитывать изменение фреймворков и библиотек! И опа — приходит понимание, что надо было не фреймворк учить, а учиться проектировать и программировать. А это нудно и не вовсе не модно. И результат не такой модный и красивый, да и почти незаметен.
Постоянно вижу в среде новичков кучу мифов и табу, а понимания нет. И возникают перлы типа: Писать следует исключительно только и только в ООП, использовать следует только новомодный фреймворк X, ни в коем случае не использовать вот этот оператор языка, всегда использовать только это новое средство языка вместо другого и т.п. Да нет же! Все хорошо, когда применено по месту. Только вот новичок заучил эти табу, но не понимает, что в большинстве своем коде он делает другие ошибки, о каких не модно кричать на форумах и какие не видишь сразу.
Вот именно такой опыт и нужен в программировании. И таких программистов катастрофически не хватает. Вызубрить что-то чтобы пройти собеседование — это тупик. Может подойти для совсем новичка, только вот в реальной работе для такого новичка это вызубренное не поможет, потому что сразу дадут задание, какое он никогда не реализовывал и, может быть, впервые в жизни видит. И сидят в шоке: «как же так, я вызубрил знание фреймворка, а надо реализовывать фичу и при этом разбираться в непонятном коде, копаясь в мегабайтах чужих исходников не самого идеального кода, да и еще надо это сделать к сегодняшнему вечеру!».
Такая вот жесть в собеседованиях неспроста. Чтобы понять в чем дело, надо подумать над очень неудобными темами.
Цель компании — деньги любой ценой. Компаниям не нужны программисты сами по себе. Программист не приносит деньги напрямую. Над ним нужен надзор, ему еще надо задания давать, проверять, тестировать, следить чтобы он работал, а не сидел в интернете. Столько с ним мороки!
Программист со средними способностями не нужен — будут искать такого же, но очень дешевого. Программист, кто не будет стоять по струнке и бодро выкрикивать «ку» — тоже не нужен. Поэтому самодовольные, кому что-то не нравится на собеседованиях — пусть побыстрей отваливаются. Будем искать покорного, трудолюбивого.
Программисты, кто работал в других темах, с другими фреймворками, с другими задачами — тоже не нужны. Компании не настолько богатые, чтобы платить деньги работникам, чтобы переобучать программистов. Вы же программисты — должны все знать в совершенстве, а не знаете — не компетентны.
Программист не знает алгоритм сортировки? Отлично — это повод снизить ему зарплату в два раза. Компаниям не нужны алгоритмы сортировки, но любой прокол программиста на собеседовании — отличный повод несколько месяцев платить ему сниженную зарплату.
Программист любит качественный код, продуманную архитектуру? Это жесть! Компания не будет ждать высокоинтеллектуальные изыски. Надо чтобы было готово уже вчера. И программиста будут гнать на работе до изнеможения, чтобы еле успевал за выходные восстановиться.
Программист очень молод? Отлично. Будет работать за десятерых, пока молодость позволяет, да и еще не надо ему оплачивать больничные.
А чтобы не просил добавок к зарплате, устроим бег в колесе. Пусть он соревнуется с другими программистами. Сделал работу позже всех, не смог сравниться с большинством выживших — ты нам не подходишь, работаешь медленно и не вписываешься в план. Не успеваешь делать красивый код и в гонке пишешь говнокод — ты нам тоже не нужен.
Чтобы уж точно обезопасить себя от дорогих программистов, устроим испытательный период в три месяца и без какой-либо оплаты или будем платить меньше чем уборщице. А зачем платить больше? Ведь три месяца для компании — это халява. Плюс всегда можно уволить особо недовольных, неповоротливых или средних — они же согласились на наши шулерские правила игры с испытательным сроком.
Вот так вот. Как любят говорить «это бизнес, детка!»
А как быть тем кто горд, самолюбив, медленно пишет код, больше думает, чем пишет, не хочет на халяву писать тестовые задания, не хочет терпеть экзамены-унижения на идеальное знание?
Вы подаете резюме не в те компании и не на те позиции. Ваша квалификация выше тех позиций, на какие расчитываете. И вы идеально годны на работу в адекватные компании. Но сильно не зазнавайтесь, там халявы тоже не будет.
Ваш выбор — соглашаться на жестокие правила игры или играть в свои игры, где ваша жизнь в выигрыше.
беритесьбойтесь брать ответственность.Дело в том, что всегда работаешь на свое развитие. Поэтому выход из своей зоны комфорта необходим. И это основное, что нужно в инженерных специальностях. Мы работаем с творчеством и неизвестностью. Здесь нужен результат.