Pull to refresh
151
582.4
Денис Пешехонов @Enfriz

Фулстек разработчик: Vuejs, .NET

Send message

Что-то вы себе противоречите. Так всё-таки удобный сервис или "дельцы, которые возят"?

Удобный сервис это залил файлы, оплатил картой, указал адрес, через месяц пришло. А дельцы это дельцы, серая зона, сложность поиска и коммуникации, переводы как правило на личный счёт итд.

Почти всё, что я запомнил, есть в статье. Ну ещё по опыту поспрашивали: как у нас в компании было планирование, что делали лиды, какие возникали трудности и как решал.

Для меня существование и проникновение в стандарты разработки огромной дополнительной надстройки над технологией является признаком проблем у технологии. Например, для HTML+JS таких надстроек много: Dart, TS, React/Vue/Angular, препроцессоры CCS, а до этого jQuery. Если сообществу нужно так много свистелок поверх языка, с языком точно что-то не так (с JS + HTML сильно много чего не так, очевидно).

Так вот в Java это Spring. Если сообществу в таких критически больших объёмах потребовался фреймворк, который превращает Java чуть ли не в новый язык, то это признак наличия больших недостатков. Ну и Kotlin, опять же, он даже гуглом принят, как стандарт для Андроида, а появился же не на пустом месте.

большую часть времени играю один, но пару раз в неделю собираюсь играть с друзьями

Считаю, что если человек может пару раз в неделю (!) собираться с друзьями, то у него вообще нет никаких проблем с организацией таких собраний, и бот не нужен. Я со своими могу собраться раз в два месяца, если повезёт. У всех работа, семьи, дети (у меня тоже). Синхронизировать расписания нереально, если вам 30+.

сектантство

Блин, а ведь точно. Теперь у меня в голове модель укладывается. Структура, очевидно, работает: компания прибыльная, продукт продаётся и функционирует. И люди внутри, кажется, действительно верят в их систему, вон как тут защищают её. Но при этом у системы есть много сомнительных для внешнего наблюдателя признаков, начиная от показного противопоставления себя общепринятому и заканчивая более специфичным ритуалом отбора, чем это обычно бывает.

Это же секта. Прямо по пунктам: противопоставление обычному, ритуалы, замкнутость, отличие своих и не своих, истовая вера адептов в учение, и даже фактическая стабильность и работоспособность системы. Дословно прям, теперь идеально всё сошлось, спасибо!

Но... это ведь та же вакансия, на которую я откликнулся. А как же два кандидата на более поздней стадии найма? Я уже неделю как работаю в другом месте, а вы всё вакансию не закрыли?

Вот вам пришлось добавить композицию там, где по бизнесу её нет (включить документ в письмо). Это усилило coupling. На таком мелком примере проблем нет, но что если на самом деле таких сценариев много, и к письму кроме документа может быть приложен протокол, отчет, акт сверки итд. И у каждого свои правила. Вы не только в письмо добавите кучу полей, но и письмо начнет становиться божественным объектом, бизнес-логика из других контекстов протечет в него.

Первым же голосованием тебя уволят )

Но в обычной здоровой корпоративной среде я тоже ставлю себе продуктовые цели и тоже могу с любым коллегой любого ранга, который в контексте, обсуждать решение. Просто в обычной среде мне не нужно одобрение джунов, чтобы доказать свою экспертизу )

Извольте. Есть в одном сервисе две сущности: письмо и документ.

Пусть у письма бывают статусы: создано, отправлено.

У документа бывают статусы: создано, согласовано.

Никакая из этих сущностей не является композиционно составной частью второй: они вполне себе живут изолировано. Но иногда к письму может быть приложен документ. И в таком случае сменить статус письма с "Создано" на "Отправлено" (то есть отправить письмо) можно только тогда, когда документ в нём согласован. Типичная энтерпрайз задача на минималках.

Как на Go будет выглядеть модель данных, которая не даст использующему её программисту сломать инвариант?

Вижу прямое противоречие между "твоя экспертиза ценнее" и "твоё решение не имеет большего веса". Конечно, имеет. Это буквально определение экспертизы: более высокий вес мнения эксперта.

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

Привет, спасибо за отзыв. Но почему нельзя было так и сказать в обратной связи? Я бы абсолютно нормально это воспринял. И было бы понятнее, чем то, что мне написали, причём только после моего вопроса :)

я бы головы отрезал всем тем гениям которые взяли за моду поголовно в каждом ЯП считать с 0

Но у этого же есть математическая подоплёка. Индексация с нуля это не мода, а удобство вычислений. Например, когда нужно разместить элементы с шагом N, то координата i-го элемента будет равна i*N, и таких задач очень много. Размещения, сортировки, группировки, выборки, там везде математика красиво сходится, если считать с нуля, и некрасиво, если с единицы.

Хаты по 20-50 млн стоят

Москва, видимо? Налог на пафос же :)

Ну, нанимали всё-таки разработчика, а не промпт-инженера )

Кажется, про R снова заговорили последние годы

Ну вот смотрите, у вас почти по всем пунктам ответы: "есть но урезано", "не так красиво", "можно самому написать" и так далее. Язык это инструмент. Если мне инструмент сначала нужно самому допиливать под довольно типовые задачи энтерпрайза, то это, на мой взгляд, неудачный инструмент.

Вроде СА никак не привязана к языку.

Указанные мной средства нужны, чтобы очертить разработчику зону его власти, за которую он не должен выходить, или его прямо компилятор по рукам ударит. Чтобы на уровне статического анализа показывать, как ведёт себя домен. Если домен сложный (в энтерпрайзе это часто), то для описания его поведения нужна сложная система типов. Вот в DDD один из корневых принципов это изоляция доменных моделей и агрегатов от слоя приложения, как гошники решают эту проблему?

Конкретный список у меня не сохранился, но самые полезные в моём случае вещи я привёл в финале статьи.

1
23 ...

Information

Rating
2-nd
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity