Я бы еще добавил, что сначала собрать данные показывающие на то, что проблема существует (логов недостаточно, ошибки в дублирующемся логовом коде и т.д.), убедить остальных что это стоит последующих шагов.
Потом провести эксперимент (как вы упоминали) и показать, что он дал какой-то положительный эффект и какие у этого решения недостатки. Потом принять решение о распространении практики.
Некоторым даже за это платят, всякие Technology Advocate.
Он синьоров обычно требуется так же умение убеждать других.
Если вы предлагаете новый стиль кода в готовой экосистеме, на самом деле вы предлагаете смесь из вашего стиля и старого стиля. Потому, что ни стандартную ни сторонние библиотеки не будут переписывать и придется читать смесь.
Значит новый стиль должен принести настолько большое преимущество, чтобы оправдать накладные расходы на смесь. По предложенным пунктам я не вижу такового. Возможно, автор пробовал это делать в команде и все сказали, что так удобнее но упоминаний про это нет и даже про то, когда он так начал писать и каковы результаты этого тоже не написано.
Префиксы и суффиксы теоретически зло, но я буду писать как принято в данной экосистеме, чтобы быть понятным. Ибо зло это небольшое. Суффикс Exception тоже нехорош, так как по названию класса должно быть понятно, что это ошибка (Например InvalidArgument).
Они и должны называться одинаково, это одинаковые по смыслу сущности
Они разные потому, что они не одно и то же. У интерфейса свой контракт, если сильно хочется назвать класс так же как интерфейс или мокать класс, то что-то не то с пониманием чем интерфейс вообще отличается от конкретной реализации и каков его контракт.
Название API кажется странным. Для внешнего потребителя все API. Например строка по такой логике тоже должна называться API. String.API.
Если хочется что-то назвать API скорее всего ответственность данного интерфейса не совсем понята и возможно, даже, что его можно разбить на куски по конкретным ответственностям.
In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior.
Статья factoring ведет на decomposition.
Decomposition in computer science, also known as factoring, is breaking a complex problem or system into parts that are easier to conceive, understand, program, and maintain.
В примере мы пишем новый мертвый код а не меняем разбиение существующего.
Я бы сказал, если такая штука называется рефакторингом то часть рассуждений в книжках стоит поменять. Например, отказаться от утверждения, что его корректность можно проверить существующими тестами или что код делится на две стадии — функциональное изменение и подготовительный рефакторинг — они начинают смешиваться: можно написать кучу мертвого кода и не покрывать его тестами и это будет типа "безопасный" рефакторинг а потом его вызвать и это будет функциональное изменение.
Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality.
Насколько я понимаю увеличение размера списка таким образом — это добавление нового кода, а не изменение структуры существующего — нет?
Это не рефакторинг, это создание мертвого кода на вырост либо увеличение функциональности.
Википедия:
Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1][2].
Это слишком большой тест для TDD. Сначала, придется написать Const(2), для этого надо будет написать Const — для текущего кусочка подсказок не будет, но будет кодогенерация
Все тесты сразу написать просто невозможно, ибо нет интерфейса\класса который тестируется, а в его отсутствие код тупо не скомпилится.
Для этого достаточно интерфейса.
Во-первых, тоже не всегда можно без рефакторинга, так как программист в порыве страсти может написать что-то что в принципе не тестируется, либо тестируется сложно, например статический коннекшин к бд.
Мы рассматриваем ситуацию когда алгоритм известен. Например вычисление выражений с приоритетами.
Исключения дает умолчание: при отсутствии роверки ошибка автоматически перебрасывается на уровень выше. В случае если большая часть вызовов не нуждается в особенной обработке это дает экономию и невозможность просто проглотить ошибку.
Я бы еще добавил, что сначала собрать данные показывающие на то, что проблема существует (логов недостаточно, ошибки в дублирующемся логовом коде и т.д.), убедить остальных что это стоит последующих шагов.
Потом провести эксперимент (как вы упоминали) и показать, что он дал какой-то положительный эффект и какие у этого решения недостатки. Потом принять решение о распространении практики.
Он синьоров обычно требуется так же умение убеждать других.
Если вы предлагаете новый стиль кода в готовой экосистеме, на самом деле вы предлагаете смесь из вашего стиля и старого стиля. Потому, что ни стандартную ни сторонние библиотеки не будут переписывать и придется читать смесь.
Значит новый стиль должен принести настолько большое преимущество, чтобы оправдать накладные расходы на смесь. По предложенным пунктам я не вижу такового. Возможно, автор пробовал это делать в команде и все сказали, что так удобнее но упоминаний про это нет и даже про то, когда он так начал писать и каковы результаты этого тоже не написано.
Префиксы и суффиксы теоретически зло, но я буду писать как принято в данной экосистеме, чтобы быть понятным. Ибо зло это небольшое. Суффикс Exception тоже нехорош, так как по названию класса должно быть понятно, что это ошибка (Например InvalidArgument).
Они разные потому, что они не одно и то же. У интерфейса свой контракт, если сильно хочется назвать класс так же как интерфейс или мокать класс, то что-то не то с пониманием чем интерфейс вообще отличается от конкретной реализации и каков его контракт.
Название API кажется странным. Для внешнего потребителя все API. Например строка по такой логике тоже должна называться API. String.API.
Если хочется что-то назвать API скорее всего ответственность данного интерфейса не совсем понята и возможно, даже, что его можно разбить на куски по конкретным ответственностям.
Про Питон Eго Величество в целом написал тут
Я нашел несколько рецептов для VS и WebStorm. Интересно, это пробовали и не подошло (ну мало ли какие там особенности). Или сеньоры специфические.
https://stackoverflow.com/questions/46500302/attach-visual-studio-debugger-to-electron-app
https://blog.jetbrains.com/webstorm/2016/05/getting-started-with-electron-in-webstorm/
Я ни разу не эксперт, но кроме гитхаба есть выступления на конференции, линкедин, блоги и так далее.
То есть это мертвый код?
Статья factoring ведет на decomposition.
В примере мы пишем новый мертвый код а не меняем разбиение существующего.
Я бы сказал, если такая штука называется рефакторингом то часть рассуждений в книжках стоит поменять. Например, отказаться от утверждения, что его корректность можно проверить существующими тестами или что код делится на две стадии — функциональное изменение и подготовительный рефакторинг — они начинают смешиваться: можно написать кучу мертвого кода и не покрывать его тестами и это будет типа "безопасный" рефакторинг а потом его вызвать и это будет функциональное изменение.
Разве изменение не было для того, чтобы доопределить его для 11?
Это уже не рефакторинг. Меняется не только факторинг но и функциональность.
Там уточнено.
Насколько я понимаю увеличение размера списка таким образом — это добавление нового кода, а не изменение структуры существующего — нет?
Это не рефакторинг, это создание мертвого кода на вырост либо увеличение функциональности.
Википедия:
Рефа́кторинг (англ. refactoring), или перепроектирование кода, переработка кода, равносильное преобразование алгоритмов — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1][2].
У вас цель не совпадает с целью из определения
А можно пример рефакторинга в результате которого возникает непокрытый код из покрытого?
Хотелось бы всё-таки точную цитату а не имхо. Вообще тесты сейчас просто фоном в процессе набора гоняются NCrunch и live unit testing.
Некоторые вообще пропагандируют подход работать и коммитить маленькими кусочками
https://medium.com/@kentbeck_7670/test-commit-revert-870bbd756864
С подсказками.
Это слишком большой тест для TDD. Сначала, придется написать Const(2), для этого надо будет написать Const — для текущего кусочка подсказок не будет, но будет кодогенерация
Или не придется
Можно написать некомпилирующийся тест
Для этого достаточно интерфейса.
Мы рассматриваем ситуацию когда алгоритм известен. Например вычисление выражений с приоритетами.
Требуется больше итераций и кода на выброс, чем если сначала написать все тесты потом весь код или наоборот.
Лайвкодинг — он разновидность кодинга. Так что он похож на то что делается на работе.
Например, в C# 8
Исключения дает умолчание: при отсутствии роверки ошибка автоматически перебрасывается на уровень выше. В случае если большая часть вызовов не нуждается в особенной обработке это дает экономию и невозможность просто проглотить ошибку.