Здравствуйте, Irrbis, Вы писали:

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

Это как? Как можно сделать опечатку в коде так, чтобы код после этого еще и нормально компилировался? Всякие мелочи вроде порядка букв в идентификаторах свидетельствуют о том, что идентификаторы выбраны плохие. И следует выбрать идентификаторы лучше. А + с — (и прочие соседние буквы) перепутать при нормальном навыке не получится. Это же моторика, блин. Я прекрасно чувствую, что набираю фигню. Еще до того, как ее увижу на экране. Примерно в тот момент, когда клавиша вниз пошла. Т.е. из ошибок, не отлавливаемых "сенсорно", остаются либо порядок букв, либо регистр (оба — ошибки в синхронизации последовательности действий, а не в выборе действий). А это в 90% случаев должен компилятор отловить.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, maxkar, Вы писали:

M>>Для экспериментов нужно писать код. Много кода (hello world много интересных моментов оставляет за кадром). Ну или на этапе evaluation технологии этот код писать, но все равно писать.

AVK>Чтобы писать быстро много кода надо не десятипальцевые методы осваивать, а пользоваться средствами типа Решарпера или CodeRush.
А в чем проблема пользоваться дестипальцевым методом при использовании решарпера? Или он принципиально не совместим с набором и требует мышку использовать?

AVK>За человеком, который ими владеет, ты никогда не угонишься, даже если научится одновременно набирать еще и ногами на отдельной клавиатуре.
Не понял? Значит, им решарпер можно а мне нельзя?

M>>А как делать в нем радикальные изменения?
AVK>Решарпер

А что решарпер? Это не рефакторинг. Например, у какого-нибудь infrastructore-layer изменился API. Ну и нужно его поменять в паре сотен мест, где он использовался.

M>>Там и чисто механическая работа бывает по выкашиванию говнокода.
AVK>Для выделения кода и нажатия на кнопку Del нужен десятипальцевый метод?
Выделение то же (с клавиатуры удобнее при наличии нужных навыков). Ну и выкашивание обычно предполагает добавление какой-то замены. Метод на новый API перевести. Заменить несколько методов одним. Заменить несколько классов одним. В общем, мелочи на несколько десятков файлов в итоге.


M>>И способность мышления тоже требуется.
AVK>Не тоже, это главное, что требуется. Все остальное вторично. Если на передний план выходит что то другое — речь явно не про программиста.
Для сеньера только мышления будет не достаточно. Коммуникативные навыки нужны. Умение излагать свои мысли (иначе говнокод будет в любом случае).

Здравствуйте, maxkar, Вы писали:

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

M>Это как? Как можно сделать опечатку в коде так, чтобы код после этого еще и нормально компилировался?

void foo()
{
  int i = 10;
  while(i > 0);
  {
    --i;
  }
}

Здравствуйте, senglory, Вы писали:

S>Здравствуйте, maxkar, Вы писали:

M>>От сеньера — как раз стоит. Как он может нормально следить за тенденциями, не пробуя их на практике?

S>А с чего Вы решили, что senior — это тот, кто следит за появлением очередной трехбуквенной или еще какой пое..ни от производителей ПО?
Это я на конкретный пост отвечал. Посмотрите по ветке. Это из него я взял исходные предположения. Из той предпосылки вытекает, что набирать-то приходится. А верна ли она или нет — это другой вопрос.

Здравствуйте, opener, Вы писали:

O>Все окружающие от этого моментально поумнеют?

Не моментально, но шанс есть.

Здравствуйте, Dym On, Вы писали:

DO>senior software engineer и навык слепого десятипальцевого набора никак между собой не связаны.

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

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

Здравствуйте, maxkar, Вы писали:

AVK>>Чтобы писать быстро много кода надо не десятипальцевые методы осваивать, а пользоваться средствами типа Решарпера или CodeRush.
M>А в чем проблема пользоваться дестипальцевым методом при использовании решарпера?

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

M>Не понял? Значит, им решарпер можно а мне нельзя?

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

M>>>А как делать в нем радикальные изменения?
AVK>>Решарпер

M>А что решарпер? Это не рефакторинг.

А он не только с рефакторингом помогает, но и с любыми изменениями, в том числе радикальными.

M> Например, у какого-нибудь infrastructore-layer изменился API. Ну и нужно его поменять в паре сотен мест, где он использовался.

Во, самый сценарий для Решарпера.

AVK>>Для выделения кода и нажатия на кнопку Del нужен десятипальцевый метод?
M>Выделение то же (с клавиатуры удобнее при наличии нужных навыков).

Зачем там десять пальцев?

Здравствуйте, opener, Вы писали:

O>>>При печати слепым методом надежность и безошибочность увеличиваются

I>>Нет — уменьшаются. Вследствие возрастания скорости и большего количества опечаток при наборе десятью пальцами.

O>>>ты можешь постоянно контролировать то, что вводишь.

I>>При наборе кода опечатки могут оставаться не замеченными, это не текст.

O>Извини за нескромный вопос, ты сам печатаешь вслепую, или еще один теоретик?

А прочитать, прежде чем отвечать, слабо? Сказал же — печатаю.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, maxkar, Вы писали:

M>>А в чем проблема пользоваться дестипальцевым методом при использовании решарпера?
AVK>А ты попробуй. Большая часть нажатий клавиш — хоткеи всякие, точка и стрелки с ентером.
У меня в IDE большая часть хоткеев — на алфавитно-цифровой области с модификаторами. Так что все локально. Точка — алфавитно-цифровая часть. Энтер — тоже. А стрелки — это уже руки далеко переносить, на этом можно потягаться.

M>>Не понял? Значит, им решарпер можно а мне нельзя?
AVK>Типичный набор кода с интенсивным использованием названых тулов мало совместим с десятипальцевым методом. Если ты при наборе кода с ними много набираешь альфанумерика руками, и это не фикс варнингов про доккомменты, то ты, скорее всего, не умеешь этими тулзами хорошо пользоваться.

А мне проще пять символов не снимая руки с основной позиции набрать, чем до стрелок тянуться. Поэтому за исключением совсем грустных ситуаций у меня с алфавитно-цифровой части completion будет сокращен до одного метода, у которого потом будут плейсхолдеры заполнены. Ну или overload'ы заполнять стрелками, но это уже отдельная история (там немного по-другому работа делается).

Плюс всякие хоткеи для тех же контекстных менюшек, в которых можно стрелочками, а можно и с алфавитно-цифровой части.

Кстати, скорее всего "набор в решарпере" — это разновидность того же слепого набора, заточенного под решарпер. Я не думаю, что профессиональные спортсмены с указанных вами соревнований смотрят на клавиатуру. Т.е. "аккорды" будут совершенно другие, чем при обычном наборе текста. Но набор все равно останется слепым.

M>>>>А как делать в нем радикальные изменения?
AVK>>>Решарпер

M>>А что решарпер? Это не рефакторинг.
AVK>А он не только с рефакторингом помогает, но и с любыми изменениями, в том числе радикальными.

И чем же он может помочь кроме того, как показать все "сломавшиеся" места? Ну или find usages. Выбор "сломать" или "найти и заменить" определяется конкретными обстоятельствами. И правки там вроде "взять три строки с вызовами каких-то методов (которых больше нет) и заменить на вызов одного метода". Причем там не "копипаста", там какие-то параметры в вызовы методов готовится могут (разные в разных случаях). И прочие прелести. Ну сравнивал я как-то IDEA с Eclipse по части того, что они могут предложить при редактировании java-кода. Ничего принципиального не было. А проблемы с "неавтоматизируемыми" изменениями были.

M>> Например, у какого-нибудь infrastructore-layer изменился API. Ну и нужно его поменять в паре сотен мест, где он использовался.
AVK>Во, самый сценарий для Решарпера.
Так там не rename. Там вместо 3 методов подряд теперь нужно вызывать всего один. Как это решарпером делать? Причем раньше мог еще какой-то хэлпер нетривиальный для подготовки параметров задействоваться, например. Или вычисления чего-то, что теперь в инфраструктуре (и больше не нужно).


AVK>>>Для выделения кода и нажатия на кнопку Del нужен десятипальцевый метод?
M>>Выделение то же (с клавиатуры удобнее при наличии нужных навыков).
AVK>Зачем там десять пальцев?

expand selection в IDEA делать . В обычным IDE — именно "десятипальцевый набор" не нужен. Но слепое владение клавиатурой — нужно. Ну и можно vim при необходимости использовать. Нажали v и поехали использовать весь арсенал навигации по коду. Кстати, навигацию в vim'е я предпочитаю с алфавитной части (hjkl которая), стрелочки далеко, руки с подставки снимать лень . Это тоже не десятипальцевый метод, но из того же ряда навык.

Здравствуйте, maxkar, Вы писали:

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

M>Это как? Как можно сделать опечатку в коде так, чтобы код после этого еще и нормально компилировался?

Это так, что ты набрал и не заметил, а вылезло только при компиляции. Может, кстати, и не вылезти, например, если перепутать цифры 1 и 2 в идентификаторах. Конечно, почти наверняка все ошибки заметит компилятор. Но пока ты будешь компилировать, смотреть, где вылезла ошибка, затем идти туда и ее исправлять, затем снова компилировать — на этом потеряется весь выигрыш во времени. Вреда от этого больше чем пользы, ИМХО.

Здравствуйте, Крокотук, Вы писали:

К>Здравствуйте, maxkar, Вы писали:

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

M>>Это как? Как можно сделать опечатку в коде так, чтобы код после этого еще и нормально компилировался?

К>

К>void foo()
К>{
К>  int i = 10;
К>  while(i > 0);
К>  {
К>    --i;
К>  }
К>}
К>

Ну... В моих конвенциях не пройдет. И в большинстве используемых в Java — тоже. Основная фича — автоформат кода! В хронических случаях — при сохранении (я не помню, включено ли у меня сейчас). А так уже в привычку вошло регулярно "ctrl-shift-f" нажимать.

В конвенциях — egyptyan brackets, т.е. октрывающая фигурная скобка должна уйти на строку с закрывающей круглой. Если она туда не ушла, значит, что-то не так, нужно искать опечатки. То же автоформатирование и постоянный визуальнй контроль вообще позволяют в данном коде для цикла фигурные скобки не писать. Чем я в личных проектах повсеместно и пользуюсь. Лишняя ';' приведет к нарушению форматирования (индент не туда), так что проблем совсем нет.

А еще отдельно хочется отметить, что перепутать (или нажать вместе) ';' и 'Enter' — сложно. Там пара сантиметров в движении. И между ними еще одна клавиша. Так что это либо совсем неправильное движение (и сенсорное ощущение неправильности), либо полная потеря основной позциии (что тоже ловится за несколько символов, когда риски на клавиатуре не ощущаются в нужных местах). Да и от энтера обычно ощущения сильно другие, чем от алфавитно-цифровых клавиш.

Вот как деятельность автокомплита подобная проблема возникнуть может. Но как раз ее то и проще ловить, если постоянно смотреть на монитор, а не отвлекаться в поиске клавиш на клавиатуре.

Здравствуйте, opener, Вы писали:

O>Здравствуйте, AlexGin, Вы писали:

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

AG>>Программисту (даже НЕ синьору) — прежде всего требуется способность мышления.
AG>>Набирать десятью пальцами
AG>>Навык конечно же неплохой, но для программиста, ИМХО, абсолютно не критичный.

O>Навык, конечно, не критичный, но как-то смешно выглядит "профессионал", медленно набивающий текст двумя пальчиками, глядя на клавиатуру, а потом перебивающий набранное предложение заново потому, что забыл переключить раскладку и не посмотрел вовремя на монитор. Сразу складывается впечатление (пусть даже субъективное), что не много этот человек написал в своей жизни кода.
...не много этот человек написал в своей жизни жизни постов в соц-сетях... ИМХО как-то так.

AG>>Работа программиста ведь совсем мало состоит из набора текста...

O>Гнилая отмазка.
Простое жизненное наблюдение.
Открою маленький секрет — в наше время код НЕ пишется в простом редакторе типа "блокнота".
Сначала код генерируется в IDE, где автоматическая генерация происходит намного быстрее, чем печать хоть десятью, хоть двадцатью пальцами.
Затем идет анализ и обдумывание конкретных задач (по бизнес-логике, GUI, базам данных и т.д). На этом этапе быстрый набор текста не сэкономит сколько нибудь значительно времени.

А 2-3 тысячи строчек кода — 1 нифига не компактно, 2 добавят кучу своих багов.

Да и часто сталкиваюсь с задачами, решаемыми стандартными средствами, но для которой еще(уже) написано 100500 невменяемых велосипедов — из-за того что люди не читают RTFM.

Здравствуйте, Irrbis, Вы писали:

I>Здравствуйте, maxkar, Вы писали:

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

M>>Это как? Как можно сделать опечатку в коде так, чтобы код после этого еще и нормально компилировался?

I>Это так, что ты набрал и не заметил, а вылезло только при компиляции. Может, кстати, и не вылезти, например, если перепутать цифры 1 и 2 в идентификаторах. Конечно, почти наверняка все ошибки заметит компилятор. Но пока ты будешь компилировать, смотреть, где вылезла ошибка, затем идти туда и ее исправлять, затем снова компилировать — на этом потеряется весь выигрыш во времени. Вреда от этого больше чем пользы, ИМХО.

Это безIDE-шный вариант? Значит vim в качестве редактора. Навигация на нужную строку — набор номера строки + g. Могу еще и по индексу на позицию в строке перейти. Почти так же. Если вывод инструмента нормальный и мне не лень, сборка будет производиться прямо из vim'а. С переходом по всем ошибкам прямо оттуда же. Да и в любом случае вряд ли получится набрать полностью корректную программу с первого раза, все равно что-нибудь вылезет. Хотя я простенькие hello world набираю и они собираются сразу, но для больших файлов это не так. Так что один запуск компилятора у нас в любом случае есть. В цифрах у меня могут быть опечатки на блоке 4-6 (хотя вроде бы я их тоже наконец научился нормально набирать). Их я и визуально контроллирую. А на остальных символах "не тот" бывает очень редко, обычно ошибки в порядке букв (и лишних нажатиях).

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

Так что это все надуманные проблемы. Ну за исключением долгой сборки, которую нельзя производить инкрементально/по частям (кстати, да, это одна из причин развития сильной модульности в моих программах).

К>

К>void foo()
К>{
К>  int i = 10;
К>  while(i > 0);
К>  {
К>    --i;
К>  }
К>}
К>

не взлетит

Здравствуйте, omgOnoz, Вы писали:

O>А 2-3 тысячи строчек кода — 1 нифига не компактно, 2 добавят кучу своих багов.
Компактно. Причем "код" — это сильно сказано. 2-3 тысячи строк исходников (включая пустые строки, документацию (контракты) и т.п.). Багов там кучи быть не может (кода мало!). Все мелочи отловятся в первую неделю-месяц использования (еще до production). Все, у нас есть компактная библиотека для решения нужных задач.

O>Да и часто сталкиваюсь с задачами, решаемыми стандартными средствами, но для которой еще(уже) написано 100500 невменяемых велосипедов — из-за того что люди не читают RTFM.

Да, да, да... Видел я библиотеки. У которых нужно сначала долго читать RTFM (в моих 2-3 тысячах кода — посмотреть несколько примеров, прочитать контракты, начать использовать). Потом бороться с багами. Вот apache httpclient, например, не умеет делать пулинг на compressed-каналах. Потому что у него пул прикручен на неправильном (архитектурно) уровне. В apache dbcp вообще пулы утекают если база в момент старта/обращения не доступна. Пулы, не отдельные соединения! И потом базу долбят. Не, у себя я запатчил все, но в mainstream оно не пошло. (Вообще, пул стоит особняком, там обертки нужно автогенерировать, а на тот момент я еще не был готов к этому). В quartz scheduler при наличии небольших задержек в базе (10 секунд) кластер разваливается. И никакой мануал этому не поможет. Во-первых, в мануале не описаны процессы восстановления после сбоя. А во вторых, эта константа где-то жестко прописана в коде... Так что маленький велосипед чинить гораздо проще, чем этим монстров с мануалами.

Ну это же опенсорц

Здравствуйте, maxkar, Вы писали:

AVK>>А ты попробуй. Большая часть нажатий клавиш — хоткеи всякие, точка и стрелки с ентером.
M>У меня в IDE большая часть хоткеев — на алфавитно-цифровой области с модификаторами.

И? Ты несколько хоткеев подряд десятипальцевым методом нажимаешь?

M>А мне проще пять символов не снимая руки с основной позиции набрать, чем до стрелок тянуться.

Вот и получается, что десятипальцевый метод не дает тебе нормально освоить Решарпер, и, в итоге, скорость набора кода уменьшается

M>Кстати, скорее всего "набор в решарпере" — это разновидность того же слепого набора, заточенного под решарпер. Я не думаю, что профессиональные спортсмены с указанных вами соревнований смотрят на клавиатуру.

Вот только десятипальцевый и слепой набор это далеко не одно и тоже. Я сильно сомневаюсь, что в этом топике есть хоть один человек, который смотрит на клавиатуру для нажатия Enter, Esc или там стрелок.

M>Но набор все равно останется слепым.

Прочти сабж — с кем ты споришь?

M>И чем же он может помочь кроме того, как показать все "сломавшиеся" места? Ну или find usages.

Этого, типа, мало? Ну и открой для себя Go To Usages. Ну и есть еще Go To Definition/Derived/Implementation/Member/Symbol, Next/Prev Member, Move Refactoring, контекстные действия при несовпадении сигнатур, добавление параметров/мемберов из использования и т.д.

M>В обычным IDE — именно "десятипальцевый набор" не нужен.

Тогда о чем речь?

Здравствуйте, UVV, Вы писали:

UVV>Здравствуйте, alpha21264, Вы писали:

A>>А теперь какой это даёт выигрыш для одного рабочего дня программиста.

UVV>Я печатаю это сообщение, не глядя на клавиатуру :D
+100500
Вот и я о том же — skill слепого десятипальцевого набора — это прекрасно для тех, кто пишет в форумах (включая и этот), в блогах и соц-сетях, на всяких фейсбуках/одноклассниках и т.п. Для работы в современной IDE

В общем — один из компьютерных атавизмов...

AG>Открою маленький секрет — в наше время код НЕ пишется в простом редакторе типа "блокнота".
AG>Сначала код генерируется в IDE, где автоматическая генерация происходит намного быстрее, чем печать хоть десятью, хоть двадцатью пальцами.
AG>Затем идет анализ и обдумывание конкретных задач (по бизнес-логике, GUI, базам данных и т.д). На этом этапе быстрый набор текста не сэкономит сколько нибудь значительно времени.
Секрет ваш бесполезен, пока жива каста пишущая код без IDE, дебагера и т.п.