О, только что выяснил на себе, что общаться с автором положительно невозможно. Так что читаем текст, киваем интересным мыслям, пропускаем непонятное, идем к следующей статье.
Вообще-то недостаток в текстах есть. Разжеванное и в рот положенное в виде видео на ютубе или развлекательной статьи вполне можеть быть создано с коммерческой целью — пиара какого-то продукта, компании или себя лично и не страдать излишней объективностью. Много текстов, много мусора.
К примеру, для поиска инженерных знаний интернет уже не подходит, приходится идти ногами в библиотеку — любой, кто делал ремонт в своей квартире, меня поймет.
Новому поколению программистов тоже желательно помнить, что лучший способ стать хорошим программистом — изучение чужих программ.
Пусть автор пишет на сях как на ассемблере, с именами переменных не шибко информативнее eax/ebx/ecx/edx
Пусть его стиль кодирования настолько стар (суперстар), что требует наличия текстовых комментариев на каждую строчку
Пусть он отказывается опнсорсить свои наработки
Пусть он называет свой алгоритм идеальным (идеальных алгоритмов не бывает, для любого алгоритма можно придумать условия, когда он будет неоптимальным)
Но идеи-то он излагает интересные!
И местами он прав, и меня это тоже печалит — практически религиозная вера в непогрешимость best practices, в O-большое (это все-таки достаточно грубая оценка времени выполнения алгоритма), в то, что технические решения называют хорошими или плохими вне зависимости от контекста их применения.
У них есть коварный план, которым они регулярно пользуются — налагать санкции на всех, кто работает с санкционными компаниями. В том числе за пределами США.
ООП ничего не противоречит, включая ФП и процедурное программирование. Речь о "классическом" ооп — объекты с мутабельным состоянием, инкапсулирующие в себе поведение.
что есть API? Если мы говорим про публичное API модуля, то его тесты, скорее, интеграционные.
Если мы говорим про API отдельных классов, то оно может меняться часто и быстро.
Рецепт "советский": на килограмм свинины 4-5 небольших луковиц, вода, уксус.
Свинина нарезать кусками по 3-4 см, лук нарезать кольцами, положить всё в эмалированную посуду, хорошо перемешать, примять. Подготовить маринад: добавить в воду немного уксуса, чтобы вода была немного кислой. Залить мясо, чтобы мариант закрывал его. Закрыть крышкой и поставить в холодильник минимум на ночь, лучше на двое суток.
Как готовить:
Когда дрова прогорят до почти полного отсутствия пламени, собрать шампуры, чередуя мясо и луковые кольца, чтобы кусочки мяса не касались друг друга. В процессе жарки следить за углями и сбивать появляющееся пламя остатками маринада или просто водой.
Писал по TDD, эта методология действительно позволяет писать код с минимумом ошибок. Но TDD не бесплатен, написание большого кол-ва тестов требует времени, еще больше времени требуется на обновление написанных тестов при крупных рефакторингах. TDD тесты, как правило, активно используют моки и поэтому хрупкие: чтобы проверить одну строчку кода, часто необходимо написать два мока.
Попытки писать так, чтобы в тестах моки не были нужны, усложняет код. В то же время, интеграционный TDD тест, это, как правило, хорошая идея.
Хорошая статья, прямо светлое пятно бесценного собственного негативного опыта на фоне переводных новостей и рекламных постов.
Моё мнение о причинах и как этого избежать:
MVP лучше назвать прототипом и выкинуть сразу после получения контракта. Для ускорения процесса и устранения желания сэкономить, взяв прототип в основу проекта, лучше писать прототип на отдельном языке и технологии для быстрой разработки. рельсах, ангуляре, реакт+js тяп-ляп без стора.
толпа миддлов должна компенсироваться активным архитектором и жестко поставленным процессом разработки. Включая ревью всех коммитов, автоформаттеры, требования к коду и тестам и т.п.
Команда не должна пермаментно делать больше функционала, чем она может делать, иначе качество кода закономерно падает. Защищать команду от заказчиков — обязанность тимлида с PM, похоже, они не справились.
Часть конфигурации становится известна только на этапе деплоймента, например, если для ноды поднимается новый инстанс в AWS с новым IP, или если пароли хранятся централизованно и доступны только деплоеру. Как это решить со статической конфигурацией?
если статическая конфигурация компилируется в отдельный jar, как определить, совместим ли конкретный jar конфигурации с конкретной версией приложения?
страдает повторное использование? Хорошо написанный микросервис — это "вещь в себе", его можно использовать через годы после последней компиляции и не заглядывая в исходники. Со статической конфигурацией придется перекомпилировать приложение, что может оказаться проблемой для старого кода.
Для продуктовой команды — наверное, да. В бюджет закладывается годовой ФОТ команды, а дальше она работает, как умеет. Для проектной разработки так не получится.
О, только что выяснил на себе, что общаться с автором положительно невозможно. Так что читаем текст, киваем интересным мыслям, пропускаем непонятное, идем к следующей статье.
Вообще-то недостаток в текстах есть. Разжеванное и в рот положенное в виде видео на ютубе или развлекательной статьи вполне можеть быть создано с коммерческой целью — пиара какого-то продукта, компании или себя лично и не страдать излишней объективностью. Много текстов, много мусора.
К примеру, для поиска инженерных знаний интернет уже не подходит, приходится идти ногами в библиотеку — любой, кто делал ремонт в своей квартире, меня поймет.
Новому поколению программистов тоже желательно помнить, что лучший способ стать хорошим программистом — изучение чужих программ.
Пусть автор пишет на сях как на ассемблере, с именами переменных не шибко информативнее eax/ebx/ecx/edx
Пусть его стиль кодирования настолько стар (суперстар), что требует наличия текстовых комментариев на каждую строчку
Пусть он отказывается опнсорсить свои наработки
Пусть он называет свой алгоритм идеальным (идеальных алгоритмов не бывает, для любого алгоритма можно придумать условия, когда он будет неоптимальным)
Но идеи-то он излагает интересные!
И местами он прав, и меня это тоже печалит — практически религиозная вера в непогрешимость best practices, в O-большое (это все-таки достаточно грубая оценка времени выполнения алгоритма), в то, что технические решения называют хорошими или плохими вне зависимости от контекста их применения.
Неужели даже питонисты начали понимать, что объект с методами лучше, чем россыпь функций?
Молодцы, и схема монетизации симпатичная.
Что могу посоветовать:
У них есть коварный план, которым они регулярно пользуются — налагать санкции на всех, кто работает с санкционными компаниями. В том числе за пределами США.
ООП ничего не противоречит, включая ФП и процедурное программирование. Речь о "классическом" ооп — объекты с мутабельным состоянием, инкапсулирующие в себе поведение.
DI, иммутабельность, монады
Так это же называется модульность, а не ООП?
Нам вовремя зарегистрировали покупку квартиры, хватило просто угрозы, что напишем заявление в прокуратуру.
Ну я фиг его знает, на практике всё получается хорошо.
что есть API? Если мы говорим про публичное API модуля, то его тесты, скорее, интеграционные.
Если мы говорим про API отдельных классов, то оно может меняться часто и быстро.
например, вместо
Приходится писать:
Рецепт "советский": на килограмм свинины 4-5 небольших луковиц, вода, уксус.
Свинина нарезать кусками по 3-4 см, лук нарезать кольцами, положить всё в эмалированную посуду, хорошо перемешать, примять. Подготовить маринад: добавить в воду немного уксуса, чтобы вода была немного кислой. Залить мясо, чтобы мариант закрывал его. Закрыть крышкой и поставить в холодильник минимум на ночь, лучше на двое суток.
Как готовить:
Когда дрова прогорят до почти полного отсутствия пламени, собрать шампуры, чередуя мясо и луковые кольца, чтобы кусочки мяса не касались друг друга. В процессе жарки следить за углями и сбивать появляющееся пламя остатками маринада или просто водой.
Писал по TDD, эта методология действительно позволяет писать код с минимумом ошибок. Но TDD не бесплатен, написание большого кол-ва тестов требует времени, еще больше времени требуется на обновление написанных тестов при крупных рефакторингах. TDD тесты, как правило, активно используют моки и поэтому хрупкие: чтобы проверить одну строчку кода, часто необходимо написать два мока.
Попытки писать так, чтобы в тестах моки не были нужны, усложняет код. В то же время, интеграционный TDD тест, это, как правило, хорошая идея.
Хорошая статья, прямо светлое пятно бесценного собственного негативного опыта на фоне переводных новостей и рекламных постов.
Моё мнение о причинах и как этого избежать:
Сформулирую это так: Либо вы платите за поддержку стабильной версии джавы, либо работаете бесплатными тестерами последней версии.
Часть конфигурации становится известна только на этапе деплоймента, например, если для ноды поднимается новый инстанс в AWS с новым IP, или если пароли хранятся централизованно и доступны только деплоеру. Как это решить со статической конфигурацией?
если статическая конфигурация компилируется в отдельный jar, как определить, совместим ли конкретный jar конфигурации с конкретной версией приложения?
страдает повторное использование? Хорошо написанный микросервис — это "вещь в себе", его можно использовать через годы после последней компиляции и не заглядывая в исходники. Со статической конфигурацией придется перекомпилировать приложение, что может оказаться проблемой для старого кода.
Для продуктовой команды — наверное, да. В бюджет закладывается годовой ФОТ команды, а дальше она работает, как умеет. Для проектной разработки так не получится.