тогда мне непонятно, почему это интерфейс, а не неймспейс, и как он может быть у Http клиента менеджер лицензий или это не HttpClient а RestClient? Тогда слово Web должно быть уже внутри слова HTTP.
Скорее всего пользователь сначала определяется какой конкретный API использует, а потом уже оперирует сущностями.
using KingOfDevs.SpecificRest.WebApi;
// если по-вашему а не по стандарту
License.Repository licenses = GetSpecificRestClient().Licenses;
licenses.Remove(myLicense);
Т.е. я бы все эти слова про API вынес бы в контекст определяемый юзингами то, что внутри неймспейса сделал бы максимально похожим на доменный язык.
Ну вообще, я ниже написал, что мой выбор, чтобы все писали по стайл гайду принятом в данной экосистеме. Если C# — то скобки на отдельной строке. И желательно проверять все стайлкопом.
А в другой экосистеме я буду по другому. Вот в питоне и F# вообще только отступы.
Я бы еще добавил, что сначала собрать данные показывающие на то, что проблема существует (логов недостаточно, ошибки в дублирующемся логовом коде и т.д.), убедить остальных что это стоит последующих шагов.
Потом провести эксперимент (как вы упоминали) и показать, что он дал какой-то положительный эффект и какие у этого решения недостатки. Потом принять решение о распространении практики.
Некоторым даже за это платят, всякие 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 — для текущего кусочка подсказок не будет, но будет кодогенерация
Все тесты сразу написать просто невозможно, ибо нет интерфейса\класса который тестируется, а в его отсутствие код тупо не скомпилится.
Для этого достаточно интерфейса.
Во-первых, тоже не всегда можно без рефакторинга, так как программист в порыве страсти может написать что-то что в принципе не тестируется, либо тестируется сложно, например статический коннекшин к бд.
Мы рассматриваем ситуацию когда алгоритм известен. Например вычисление выражений с приоритетами.
тогда мне непонятно, почему это интерфейс, а не неймспейс, и как он может быть у Http клиента менеджер лицензий или это не HttpClient а RestClient? Тогда слово Web должно быть уже внутри слова HTTP.
Скорее всего пользователь сначала определяется какой конкретный API использует, а потом уже оперирует сущностями.
Т.е. я бы все эти слова про API вынес бы в контекст определяемый юзингами то, что внутри неймспейса сделал бы максимально похожим на доменный язык.
Я не знаком с современной экосистемой, из того, что мне прилетает, я вижу что большинство кода без типов. Скорее всего мало кто использует.
Ну вообще, я ниже написал, что мой выбор, чтобы все писали по стайл гайду принятом в данной экосистеме. Если C# — то скобки на отдельной строке. И желательно проверять все стайлкопом.
А в другой экосистеме я буду по другому. Вот в питоне и F# вообще только отступы.
Эти "нравится" и "не нравится" — вопрос привычке. Вон в Джаве так все пишут.
Я бы еще добавил, что сначала собрать данные показывающие на то, что проблема существует (логов недостаточно, ошибки в дублирующемся логовом коде и т.д.), убедить остальных что это стоит последующих шагов.
Потом провести эксперимент (как вы упоминали) и показать, что он дал какой-то положительный эффект и какие у этого решения недостатки. Потом принять решение о распространении практики.
Он синьоров обычно требуется так же умение убеждать других.
Если вы предлагаете новый стиль кода в готовой экосистеме, на самом деле вы предлагаете смесь из вашего стиля и старого стиля. Потому, что ни стандартную ни сторонние библиотеки не будут переписывать и придется читать смесь.
Значит новый стиль должен принести настолько большое преимущество, чтобы оправдать накладные расходы на смесь. По предложенным пунктам я не вижу такового. Возможно, автор пробовал это делать в команде и все сказали, что так удобнее но упоминаний про это нет и даже про то, когда он так начал писать и каковы результаты этого тоже не написано.
Префиксы и суффиксы теоретически зло, но я буду писать как принято в данной экосистеме, чтобы быть понятным. Ибо зло это небольшое. Суффикс 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 — для текущего кусочка подсказок не будет, но будет кодогенерация
Или не придется
Можно написать некомпилирующийся тест
Для этого достаточно интерфейса.
Мы рассматриваем ситуацию когда алгоритм известен. Например вычисление выражений с приоритетами.