В разных организациях встречаются люди которые работают намного производительнее, секрет оказывался достаточно прост — они умело используют инструменты.
Например когда я только начинал программирование я "не умел" пользоваться поиском, например если я не помнил точное название процедуры то просто пролистывал весь код в файле поисках нужного места в программе ( благо тогда не приходилось смотреть очень объемный код). Потом увидев это недоразумение коллега мне "напомнил" что поиск работает не только по полному названию а можно искать по частям которые помнятся. И таких моментов очень много на самом деле которые сильно снижают производительность. Начиная от организации расположений окон в ide, эффективных горячих кнопок заканчивая различными дополнениями и их фичами.
Вот может есть какой-то канал twitch и прочие который именно для подобного опыта ориентированы и делает видео ролики.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>В разных организациях встречаются люди которые работают намного производительнее, секрет оказывался достаточно прост — они умело используют инструменты. O>Например когда я только начинал программирование я "не умел" пользоваться поиском, например если я не помнил точное название процедуры то просто пролистывал весь код в файле поисках нужного места в программе ( благо тогда не приходилось смотреть очень объемный код). Потом увидев это недоразумение коллега мне "напомнил" что поиск работает не только по полному названию а можно искать по частям которые помнятся. И таких моментов очень много на самом деле которые сильно снижают производительность. Начиная от организации расположений окон в ide, эффективных горячих кнопок заканчивая различными дополнениями и их фичами.
Скорость моей работы почти не зависит от того, с какой скоростью я вбиваю код — даже если я замедлю его ввод в 100 раз, общее время разработки увеличится совсем незначительно. Основную работу я выполняю на бумажке ручкой, а также в програмке SMath Studio (пользуясь случаем, рекомендую её всем, чья работа связана с математикой в том или ином виде, ну или просто нужен подобный инструмент, а также передаю мой низкий поклон и сердечную благодарность её автору Андрею Ивашову, если вдруг он присутствует на форуме и читает эти строки), ну и в некоторых других более специализированных софтинах.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, okon, Вы писали:
O>>В разных организациях встречаются люди которые работают намного производительнее, секрет оказывался достаточно прост — они умело используют инструменты. O>>Например когда я только начинал программирование я "не умел" пользоваться поиском, например если я не помнил точное название процедуры то просто пролистывал весь код в файле поисках нужного места в программе ( благо тогда не приходилось смотреть очень объемный код). Потом увидев это недоразумение коллега мне "напомнил" что поиск работает не только по полному названию а можно искать по частям которые помнятся. И таких моментов очень много на самом деле которые сильно снижают производительность. Начиная от организации расположений окон в ide, эффективных горячих кнопок заканчивая различными дополнениями и их фичами.
K>Скорость моей работы почти не зависит от того, с какой скоростью я вбиваю код — даже если я замедлю его ввод в 100 раз,
Ну поиск который я привел это не вбивание кода, это анализ кода. С бумажкой и ручкой все зависит конечно от специфики но в большинстве случаев, программу не отладишь и производительность не измеришь. Как правило большая часть работы происходит обычно все таки в IDE и других тулзах, а не на бумажке. А правильно пользоваться данными инструментами может существенно повысить производительность.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Ну поиск который я привел это не вбивание кода, это анализ кода. С бумажкой и ручкой все зависит конечно от специфики но в большинстве случаев, программу не отладишь и производительность не измеришь. Как правило большая часть работы происходит обычно все таки в IDE и других тулзах, а не на бумажке. А правильно пользоваться данными инструментами может существенно повысить производительность.
У меня основное время уходит на разработку алгоритма, параметров FSM и переходов между отдельными состояниями. Всё это делается в основном на бумажке в виде псевдокода. Ну ещё куча времени уходит на раскуривание даташитов и спецификаций на всевозможные железки, с которыми планируется работать, и протоколов, а также написанием прототипов и proof-of-concept.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, okon, Вы писали:
O>>Ну поиск который я привел это не вбивание кода, это анализ кода. С бумажкой и ручкой все зависит конечно от специфики но в большинстве случаев, программу не отладишь и производительность не измеришь. Как правило большая часть работы происходит обычно все таки в IDE и других тулзах, а не на бумажке. А правильно пользоваться данными инструментами может существенно повысить производительность.
K>У меня основное время уходит на разработку алгоритма, параметров FSM и переходов между отдельными состояниями. Всё это делается в основном на бумажке в виде псевдокода. Ну ещё куча времени уходит на раскуривание даташитов и спецификаций на всевозможные железки, с которыми планируется работать, и протоколов, а также написанием прототипов и proof-of-concept.
Ну я в подобной сфере не работаю но неужели State Machine и переходы не проще моделировать и анализировать через автоматизированные средства чем на бумажке.
С отладкой State Machine я как-то сталкивался использовал инструмент он визуализировал прохождение состояний через логику State Machine , намного нагляднее и удобнее искать ошибки чем на бумажке в уме моделировать ( может конечно если состояний мало то бумажка быстрее ).
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Ну я в подобной сфере не работаю но неужели State Machine и переходы не проще моделировать и анализировать через автоматизированные средства чем на бумажке. O>С отладкой State Machine я как-то сталкивался использовал инструмент он визуализировал прохождение состояний через логику State Machine , намного нагляднее и удобнее искать ошибки чем на бумажке в уме моделировать ( может конечно если состояний мало то бумажка быстрее ).
Иногда проще, иногда нет. Но даже если я делаю это в коде, всё равно скорость его набора не имеет совершенно никакого значения.
Здравствуйте, koandrew, Вы писали:
K>Скорость моей работы почти не зависит от того, с какой скоростью я вбиваю код — даже если я замедлю его ввод в 100 раз, общее время разработки увеличится совсем незначительно.
По большей части это верно — люди вообще раньше разрабатывали код без интерактивного доступа к компьютеру, и ничего.
Тут в первую очередь речь идёт не о скорости набора кода, а об удобстве и расширении горизонта возможностей, что таки может влиять на производительность.
Например можно вообще набирать код двумя пальцами таращась на клавиатуру, но таки слепой метод печати удобнее — и например сразу видны опечатки и т.п.
Здравствуйте, koandrew, Вы писали:
K>Ну ещё куча времени уходит на раскуривание даташитов и спецификаций на всевозможные железки, с которыми планируется работать, и протоколов, а также написанием прототипов и proof-of-concept.
Тоже время от времени приходится раскуривать сырые спецификации — и удобно например по мере раскуривания вести заметки с интерактивными гиперссылками на конкретные страницы в PDF, на места в коде, на примеры, вставлять картинки в заметки, и даже код вычислений с выводом.
Естественно можно обойтись и без всего этого, но так намного удобнее.
Имхо bottleneck больше в прокрастинации (вроде кывта), или усталости (т.е. замедлении мышления, совершения неполностью продуманных действий и пр.), или именно постановки конкретной задачи (подзадачи) на ближайшие пару часов для себя. А скорость кликанья или проведения конкретных операций особо на производительность не влияет.
Здравствуйте, RiNSpy, Вы писали:
RNS>Имхо bottleneck больше в прокрастинации (вроде кывта)
Прокрастинацию можно оседлать и направить в полезное русло, например на изучение/создание вспомогательного инструмента
RNS>или усталости (т.е. замедлении мышления, совершения неполностью продуманных действий и пр.),
Удобство работы влияет на усталость.
RNS>А скорость кликанья или проведения конкретных операций особо на производительность не влияет.
Влияет не скорость кликанья, а объём сэкономленных "кликов". В том чтобы закликиваться до изнеможения и тратить лишние переключения контекста на вспомогательные операции — ничего хорошего нет
Здравствуйте, RiNSpy, Вы писали:
RNS>А скорость кликанья или проведения конкретных операций особо на производительность не влияет.
Простой пример — отключи (не используй) копирование/вырезание/вставку текста/кода/etc некоторое время, а перенабирай всё вручную.
Сможешь ли ты выполнить свои задачи? — разумеется, возможно даже за приемлемое время, но это будет совершенно неудобно
Но это конечно немного другой формат нежели сабж — тут целенаправленно рассказывают о выбранных фичах. В то время как некоторые из неизвестных тебе они могут использовать на автомате при своей работе, и поэтому сабжевый формат тоже имеет свои плюсы.
Здравствуйте, koandrew, Вы писали:
K>Здравствуйте, okon, Вы писали:
O>>Ну я в подобной сфере не работаю но неужели State Machine и переходы не проще моделировать и анализировать через автоматизированные средства чем на бумажке. O>>С отладкой State Machine я как-то сталкивался использовал инструмент он визуализировал прохождение состояний через логику State Machine , намного нагляднее и удобнее искать ошибки чем на бумажке в уме моделировать ( может конечно если состояний мало то бумажка быстрее ).
K>Иногда проще, иногда нет. Но даже если я делаю это в коде, всё равно скорость его набора не имеет совершенно никакого значения.
Ну вот еще пример, допустим код при определенных достаточно непонятных условиях по частому событию сгенерил неожиданное исключение, например на MouseMove. Не понятно что происходит, логировать все объекты их состояние и анализировать что с ними происходит из-за чего ошибка сложно. Написать тест можно но это время + не понятны начальные условия.
Однако с фичей студии когда можно "отмотать" на несколько шагов назад точку останова может спасти кучу времени чтобы вернуться и отладить процедуру которая не отработала сразу как только словилась ошибка и упала в отладчик, а не пытаться ее воспроизвести повторно потратив на это кучу времени.
Или просто программа относительно долго запускается, проскочили точку — приходилось раньше перезапускать начинать заново. Вот экономия времени, ни одной строчки при этом не написано. Причем тут скорость писание строк, я говорю про скорость работы а это не только печать символов, хотя и на них можно экономить снипетами и пр.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Ну вот еще пример, допустим код при определенных достаточно непонятных условиях по частому событию сгенерил неожиданное исключение, например на MouseMove. Не понятно что происходит, логировать все объекты их состояние и анализировать что с ними происходит из-за чего ошибка сложно. Написать тест можно но это время + не понятны начальные условия. O>Однако с фичей студии когда можно "отмотать" на несколько шагов назад точку останова может спасти кучу времени чтобы вернуться и отладить процедуру которая не отработала сразу как только словилась ошибка и упала в отладчик, а не пытаться ее воспроизвести повторно потратив на это кучу времени.
Я уже достаточно давно не занимаюсь формошлёпством, но вообще большое преимущество FSM как раз и заключается в чётко и формально определённых критериях смены состояния. Вот их и надо логировать. А отладчик далеко не всегда бывает доступен на production системе. По крайней мере у нас.
O>Или просто программа относительно долго запускается, проскочили точку — приходилось раньше перезапускать начинать заново. Вот экономия времени, ни одной строчки при этом не написано. Причем тут скорость писание строк, я говорю про скорость работы а это не только печать символов, хотя и на них можно экономить снипетами и пр.
Это косяк дизайна и/или кривые руки реализаторов, если невозможно быстро изолировать причину сбоя из-за каких-то взаимных зависимостей разных частей кода. Опять же FSM позволяет формализировать все переходные процессы, и потому по логам этих переходов легко восстановить/имитировать последовательность событий, которые привели к сбою. Особенно это эффективно, если приходится иметь дело с железом, реальное поведение которого разительно отличается от описанного в документации, и потому приходится полагаться на некие допущения, полученные по результатам испытаний и наблюдений за поведением железки. У меня такое происходит постоянно, потому если бы код был обычным для гуёвых программ "процедурно-лапшеобразным" последовательным, то я бы постарел раньше, чем мы сумели протащить такое "чудо" через safety аудит и довести проект до внедрения. А так — проект уже год работает в цехах, и имеет минимум замечаний, а также ни одной остановки производства по его вине.
