«5 признаков, 5 советов» — это стиль Космополитен. Ни разу не видел там ни единого толкового совета, а «признаки» обычно надерганы от балды. Посему такое вступление скорее отпугивает, чем интригует.
Да, и с чего вы взяли, что на чтение статьи уйдет именно 9 минут — тоже непонятно. Люди сильно разные и читают сильно по-разному. Тексты тоже бывают сильно разные — что-то читается легко, а что-то приходится по нескольку раз перечитывать, чтобы понять.
Ну да бог с ним, со вступлением. Давайте почитаем, что же вы там написали.
А кому и этого мало, держите 5 признаков заиндевелости программиста.
Лично я вижу в этих признаках только одно: профессиональное выгорание. Если человек раньше не испытывал проблем с написанием понятного кода и с общением с коллегами, а сейчас его воротит от всего этого — тут не учиться надо, а лечиться. В отпуск длительный съездить, деятельность сменить… К психологу сходить, в конце концов.
Впрочем, это мое личное субъективное. Продолжим чтение:
Понимание проблемы – уже хорошо. Но наскоком прокачку навыков не взять. Начнете вы с энтузиазмом, но быстро выдохнетесь, а вместе с этим остановится и ваш рост.
Главный вопрос в самообучении — не «как», а «зачем». Все эти абстрактные «прокачать навыки», «стать профессионалом», «повысить свой уровень», «профессиональный рост» — это все ни о чем. Это не цель.
Цель всегда конкретна («что именно я хочу получить?»). Цель всегда направлена на определенный результат («зачем я хочу этого добиться?»).
Здесь еще можно долго философствовать о том, что программисты бывают разные и что карьерные возможности программиста не ограничены кодингом на разных языках.
Если перерыть весь интернет (что я и сделала) и опросить практиков кода на тему «как прокачаться», то все сведется к списку из 5 советов.
Желание обобщить чужой опыт — похвально. Только получился стандартный гуру-рецепт:
«Нужно делать как нужно, а как не нужно делать не нужно».
5 признаков, что вам пора учиться, 25 онлайн-сервисов для прокачки скиллов и 5 практических советов для профессионального развития вы узнаете из этой статьи за 9 минут.
Это хорошо, что вы приложили инвентарную опись сразу в самом начале.
Непонятно, каким образом ее использовать.
Тем более, что все вложенные в ребёнка необычные решения будут в будущем генерировать ещё более интересные решения.
Осталось понять, зачем все это ребенку.
В школе его «еще более интересные решения» будут только мешать учебе.
После школы, скорее всего, тоже. От инженера требуется решать задачи эффективно и понятно для других. Работал я с «творческими личностями» — спасибо, уж лучше туповатый, но исполнительный, чем вострый, но делающий непонятно что и непонятно зачем.
Мне кажется, наивный байесовский классификатор — это сильно шире, чем н-граммы. По крайней мере, разбиение текста на токены у Байеса идет обычно по словам, а не на группы символов заданной длины.
Вот вы метод н-грамм охаяли, а он, между прочим, дает очень даже неплохую точность (ЕМНИП, до 98% на текстах длиной около 1000 символов). Он не учитывает контекст? Это да, согласен. Но в ваших тестах двух библиотек я как-то тоже не наблюдаю указания контекста.
В общем, было бы неплохо для сравнения привести и результаты работы классификатора по н-граммам. Благо в нем кода — раз-два и обчелся.
магнитный момент Венеры не превышает 5—10 % магнитного поля Земли
То есть у Венеры магнитного поля почитай что и нет, а атмосфера тем не менее — есть, причем офигенно мощная. Заметим, солнечный ветер на орбите Венеры тоже не в пример сильнее, чем на орбите Марса.
В каких случаях и для чего может понадобиться искать коммит для кода перед глазами? Я, если честно, даже выдумать такую ситуацию не могу.
Счастливый вы человек. Вот без подколок — искренне завидую.
А ситуацию даже выдумывать не надо, она у меня каждый рабочий день перед глазами. Огромный проект, куча клиентов со своими особыми требованиями, несколько раз менялись требования, иногда выплывали баги, которые надо было фиксить вотпрямщас. Есть исходники по мегабайту размером (и это не шутка и не автогенерация, это код ручной выделки). Очень многие вещи можно сделать по-разному — и в одних условиях это будет правильно, в других станет ошибкой.
В общем, часто по коду непонятно, почему он написан именно так и при каких условиях он должен работать. Помогает аннотация кода: если код — древний, то в нем, скорее всего, нет ошибки (но и лезть туда не стоит — грабли могут выскочить в самых неожиданных местах). Если код трогали недавно, то смотрим внимательнее, кто и зачем это делал.
Понимаю, что наш проект — далеко не эталон с точки зрения методов разработки, но тут уж какой есть.
Ну так-то да, у «размазывания» есть свои недостатки. :)
Кстати, если у вас в день было не очень много файлов (тыщ 50-100), то можно по идее один уровень вложенности папок удалить: 2018-09-21/0f/658410676819ff.file
В среднем это даст 200-300 файлов в папке, что вполне нормально.
В текущем моем проекте такие соглашения:
— никаких префиксов.
— из постфиксов — только подчеркивание для дата-мемберов класса (localData_).
— СamelCase. При этом регистр первой буквы имеет значение: с большой буквы начинаются имена типов, статических и глобальных переменных, статических функций класса. С маленькой буквы — обычные (нестатические) функции-члены класса и всяческие переменные.
— геттеры и сеттеры оформляются как value()/setValue(newValue) — т. е. никаких get_value() или getValue().
— для совсем очевидных вещей типа счетчиков цикла разрешено использовать однобуквенные переменные (обычно i). В остальном даже временные переменные должны иметь осмысленное имя.
Однако, с другой стороны перечитайте абзац про автоинкремент.
Перечитал, но не понимаю, что вы имели в виду. Если вы о том, что трех байт может не хватить для нумерации всех файлов — так я и не предлагаю укорачивать имя файла. Просто
0f/65/84/10/67/68/19/ff.file станет 0f/65/8410676819ff.file.
Если идентификатором файла будет некий хэш, а не просто порядковый номер, то файлы «размажутся» по подпапкам более-менее равномерно. В результате в каждой конечной папке будет всего несколько десятков файлов (пара сотен, если количество файлов перевалит за 16777216). Ну а если файлов станет больше, то у вас возникнут проблемы совсем другого масштаба (в частности, приходит на ум исчерпание инодов файловой системы).
У вас получилось 7 уровней вложенности папок. Это слишком много:
1. На каждый проход вглубь тратится лишнее время (а ведь на диске сектора, в которых описана каждая папка, могут лежать вразброс). По мере добавления новых файлов папки будут раскидываться по диску. В один прекрасный момент перестанет хватать буферизации и все начнет тормозить.
2. Большинство папок, кроме корневой, будет содержать ровно по одной записи. Это я вам вполне квалифицированно заявляю: у меня в одном из проектиков файлы разложены примерно так же, только структура двухуровневая (ab/cd/efgh1231231243232.file). И хотя файлов сложено уже несколько десятков тысяч, внутри папок второго уровня редко лежит больше одного-двух файлов.
Отсюда вывод: делать структуру папок с более чем двумя уровнями вложенности — нехорошее излишество.
Если уж вы интересуетесь производительностью файлового доступа, то неплохо было бы провести эксперименты, так сказать, «в натурных условиях». Создать структуру папок с определенной вложенностью, напихать в нее энцать миллионов файлов. Затем проверить производительность, вычитывая из нее случайные файлы. И так — для различных уровней вложенности и различных «наполненностей» папок (например, если резать не по два, а по три символа, то максимальное количество файлов в папке станет равно 4096). А если вы еще и на различных файловых системах эксперимент проведете, то вообще будет прекрасно — ведь, например, ReiserFS изначально разрабатывалась из расчета на быстрый поиск в папках. Думаю, результаты таких экспериментов были бы интересны многим завсегдатаям.
Погодите, трекер и так открыт, ведь вы в первую очередь в нем ищите.
В трекере открыта своя задача. Я же имел в виду ситуацию, когда нужно разобраться с уже существующим куском кода (git blame/svn annotate/etc).
В этом случае находится коммит, который последним трогал интересующие нас строки. Если в коммит-логе уже есть внятное описание изменений — все станет понятно уже на этом этапе. В случае же ссылки на трекер придется таки эту ссылку открывать отдельно и искать информацию уже там.
Только не забывайте, что вам придется прочитать сотни таких сообщений, прежде чем вы найдете нужное. Сколько на это времени уйдет?
Какие сотни, апчомвы? Commit id, трогавший интересующие нас строки, известен (см. выше). Остальные мессаджи можно не читать (git log/svn log прекрасно работают с указанием конкретных ревизий).
Смущает уточнение «по профильной области». Уж слишком оно попахивает этаким абстракционизьмом.
Расскажу историю из жизни.
В одной большой-пребольшой, международной-премеждународной компании компании была команда русских разработчиков. Одна из многих, ясен пень. И были в той команде все с высшим образованием, да только не все — с профильным.
А когда проект подошел к концу и стали подбивать бабки, выяснилось, что top performers, которые, собственно, и вытянули весь проект на себе — это почти исключительно люди именно с непрофильным высшим. Плюс единственная в команде девушка (она, как ни странно, с профильным). Остальные в течение нескольких лет радостно били баклуши и писали отчеты, делая только необходимый минимум.
Здесь самое время для возгласа «значит, менеджмент был херовый!». Заранее согласен. Ибо компания, как я уже писал, большая и международная.
Это, конечно, ничего не значащий чей-то личный опыт.
Я бы и к программисту «нешаблонному» отнесся с недоверием, если его задача — делать поддерживаемый, простой и понятный код на основе ТЗ. Навидался я «нешаблонных», спасибо… До сих пор разгребаем.
Да, и с чего вы взяли, что на чтение статьи уйдет именно 9 минут — тоже непонятно. Люди сильно разные и читают сильно по-разному. Тексты тоже бывают сильно разные — что-то читается легко, а что-то приходится по нескольку раз перечитывать, чтобы понять.
Ну да бог с ним, со вступлением. Давайте почитаем, что же вы там написали.
Лично я вижу в этих признаках только одно: профессиональное выгорание. Если человек раньше не испытывал проблем с написанием понятного кода и с общением с коллегами, а сейчас его воротит от всего этого — тут не учиться надо, а лечиться. В отпуск длительный съездить, деятельность сменить… К психологу сходить, в конце концов.
Впрочем, это мое личное субъективное. Продолжим чтение:
Главный вопрос в самообучении — не «как», а «зачем». Все эти абстрактные «прокачать навыки», «стать профессионалом», «повысить свой уровень», «профессиональный рост» — это все ни о чем. Это не цель.
Цель всегда конкретна («что именно я хочу получить?»). Цель всегда направлена на определенный результат («зачем я хочу этого добиться?»).
Здесь еще можно долго философствовать о том, что программисты бывают разные и что карьерные возможности программиста не ограничены кодингом на разных языках.
Желание обобщить чужой опыт — похвально. Только получился стандартный гуру-рецепт:
«Нужно делать как нужно, а как не нужно делать не нужно».
Это хорошо, что вы приложили инвентарную опись сразу в самом начале.
Непонятно, каким образом ее использовать.
Осталось понять, зачем все это ребенку.
В школе его «еще более интересные решения» будут только мешать учебе.
После школы, скорее всего, тоже. От инженера требуется решать задачи эффективно и понятно для других. Работал я с «творческими личностями» — спасибо, уж лучше туповатый, но исполнительный, чем вострый, но делающий непонятно что и непонятно зачем.
Ошибаетесь. Достаточно устроиться в силовые структуры, и пенсия наступит раньше. :)
Мне кажется, наивный байесовский классификатор — это сильно шире, чем н-граммы. По крайней мере, разбиение текста на токены у Байеса идет обычно по словам, а не на группы символов заданной длины.
В общем, было бы неплохо для сравнения привести и результаты работы классификатора по н-граммам. Благо в нем кода — раз-два и обчелся.
Удивительно.
То есть у Венеры магнитного поля почитай что и нет, а атмосфера тем не менее — есть, причем офигенно мощная. Заметим, солнечный ветер на орбите Венеры тоже не в пример сильнее, чем на орбите Марса.
Мне кажется, НАСА нам вешает лапшу на уши.
Счастливый вы человек. Вот без подколок — искренне завидую.
А ситуацию даже выдумывать не надо, она у меня каждый рабочий день перед глазами. Огромный проект, куча клиентов со своими особыми требованиями, несколько раз менялись требования, иногда выплывали баги, которые надо было фиксить вотпрямщас. Есть исходники по мегабайту размером (и это не шутка и не автогенерация, это код ручной выделки). Очень многие вещи можно сделать по-разному — и в одних условиях это будет правильно, в других станет ошибкой.
В общем, часто по коду непонятно, почему он написан именно так и при каких условиях он должен работать. Помогает аннотация кода: если код — древний, то в нем, скорее всего, нет ошибки (но и лезть туда не стоит — грабли могут выскочить в самых неожиданных местах). Если код трогали недавно, то смотрим внимательнее, кто и зачем это делал.
Понимаю, что наш проект — далеко не эталон с точки зрения методов разработки, но тут уж какой есть.
Кстати, если у вас в день было не очень много файлов (тыщ 50-100), то можно по идее один уровень вложенности папок удалить: 2018-09-21/0f/658410676819ff.file
В среднем это даст 200-300 файлов в папке, что вполне нормально.
— никаких префиксов.
— из постфиксов — только подчеркивание для дата-мемберов класса (localData_).
— СamelCase. При этом регистр первой буквы имеет значение: с большой буквы начинаются имена типов, статических и глобальных переменных, статических функций класса. С маленькой буквы — обычные (нестатические) функции-члены класса и всяческие переменные.
— геттеры и сеттеры оформляются как value()/setValue(newValue) — т. е. никаких get_value() или getValue().
— для совсем очевидных вещей типа счетчиков цикла разрешено использовать однобуквенные переменные (обычно i). В остальном даже временные переменные должны иметь осмысленное имя.
Страдают. Только это не так явно проявляется, как в винде, и на больших размерах каталогов.
Перечитал, но не понимаю, что вы имели в виду. Если вы о том, что трех байт может не хватить для нумерации всех файлов — так я и не предлагаю укорачивать имя файла. Просто
0f/65/84/10/67/68/19/ff.file станет 0f/65/8410676819ff.file.
Если идентификатором файла будет некий хэш, а не просто порядковый номер, то файлы «размажутся» по подпапкам более-менее равномерно. В результате в каждой конечной папке будет всего несколько десятков файлов (пара сотен, если количество файлов перевалит за 16777216). Ну а если файлов станет больше, то у вас возникнут проблемы совсем другого масштаба (в частности, приходит на ум исчерпание инодов файловой системы).
У вас получилось 7 уровней вложенности папок. Это слишком много:
1. На каждый проход вглубь тратится лишнее время (а ведь на диске сектора, в которых описана каждая папка, могут лежать вразброс). По мере добавления новых файлов папки будут раскидываться по диску. В один прекрасный момент перестанет хватать буферизации и все начнет тормозить.
2. Большинство папок, кроме корневой, будет содержать ровно по одной записи. Это я вам вполне квалифицированно заявляю: у меня в одном из проектиков файлы разложены примерно так же, только структура двухуровневая (ab/cd/efgh1231231243232.file). И хотя файлов сложено уже несколько десятков тысяч, внутри папок второго уровня редко лежит больше одного-двух файлов.
Отсюда вывод: делать структуру папок с более чем двумя уровнями вложенности — нехорошее излишество.
Если уж вы интересуетесь производительностью файлового доступа, то неплохо было бы провести эксперименты, так сказать, «в натурных условиях». Создать структуру папок с определенной вложенностью, напихать в нее энцать миллионов файлов. Затем проверить производительность, вычитывая из нее случайные файлы. И так — для различных уровней вложенности и различных «наполненностей» папок (например, если резать не по два, а по три символа, то максимальное количество файлов в папке станет равно 4096). А если вы еще и на различных файловых системах эксперимент проведете, то вообще будет прекрасно — ведь, например, ReiserFS изначально разрабатывалась из расчета на быстрый поиск в папках. Думаю, результаты таких экспериментов были бы интересны многим завсегдатаям.
В трекере открыта своя задача. Я же имел в виду ситуацию, когда нужно разобраться с уже существующим куском кода (git blame/svn annotate/etc).
В этом случае находится коммит, который последним трогал интересующие нас строки. Если в коммит-логе уже есть внятное описание изменений — все станет понятно уже на этом этапе. В случае же ссылки на трекер придется таки эту ссылку открывать отдельно и искать информацию уже там.
Какие сотни, апчомвы? Commit id, трогавший интересующие нас строки, известен (см. выше). Остальные мессаджи можно не читать (git log/svn log прекрасно работают с указанием конкретных ревизий).
Расскажу историю из жизни.
В одной большой-пребольшой, международной-премеждународной компании компании была команда русских разработчиков. Одна из многих, ясен пень. И были в той команде все с высшим образованием, да только не все — с профильным.
А когда проект подошел к концу и стали подбивать бабки, выяснилось, что top performers, которые, собственно, и вытянули весь проект на себе — это почти исключительно люди именно с непрофильным высшим. Плюс единственная в команде девушка (она, как ни странно, с профильным). Остальные в течение нескольких лет радостно били баклуши и писали отчеты, делая только необходимый минимум.
Здесь самое время для возгласа «значит, менеджмент был херовый!». Заранее согласен. Ибо компания, как я уже писал, большая и международная.
Это, конечно, ничего не значащий чей-то личный опыт.
ЗЫ: А, понял — недобитые яйца можно переиспользовать!