Кажется, это не тот опыт, который говорит о том что вы успешно решили проблему и которым стоит поделиться.
Пока больше похоже, что вы просто «отложили» решение вопроса: уходит один из «ведущих» участников, команде нужно «деливерить», а вы взяли новичка на вырост в которого потребуется инвестировать время команды, что еще сильнее снизит показатели.
Вместо продолжения поисков вы «успокоили/успокоились» красивыми словами и сделали эту проблему проблемой «будущего себя»/«кого-то еще». (Либо, изначальная ситуация была не совсем такой как описано и на самом деле человек был не так чтобы и нужен)
Это хорошо, что вам еще не приходилось оказываться в ситуации, когда «сейлы так продали» или «выиграли тендер» и книжные методы начинают работать очень со скрипом
Согласен.
Я бы тоже в реальном проекте скорее поставил на "внутреннюю инкапсуляцию")
Каждая потенциальная обязанность инкапсулируется в своем приватном методе, с разграничением по данным. Если вдруг будущее настанет — перенести метод в новый класс, интерфейс, внедрение зависимости — это несколько тривиальных модификаций.
Конечно, package private классы тоже могли бы решить проблему, но я в это "не верю": чаще всего заходишь в пакет, а там тысячи и тысячи классов из разных областей
Это конечно здорово, но, гораздо чаще у людей стоит вопрос: что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшить.
Что грамотные менеджеры делают в этой ситуации?
А что плохого в 1с?
Толковый 1сник с правильными ценностями на вес золота в прямом смысле и может приносить реальную пользу бизнесу, если готов общаться.
Все так. Зп разработчиков таковы, что это давит на экономику компаний поэтому да х-х ив продакшн.
Но! Вот тут и проявляется настоящее мастерство, когда:
1) совместно с бизнесом делите всю систему на части с разной степенью критичности ошибок.
2) критические части делаете тщательно и без суеты с кучей тестов и qa в несколько слоев
3) некритичные — хх, максимально частый деплой, максимально дешёвая архитектура: лишние обобщения скорее вредны. Изменилась предметная область? Не жалко выкинуть и снова сделать быстро. Опирается на ядро из п 2.
Это позволяет и двигаться быстрее и экономить бюджет и явно управлять качеством, а если баг -сорян, у нас лапки, за счёт частого деплояпопрпвим и выложим через 30 минут
Кмк важно помнить, что опыт Мартина который сформировал его взгляды и кочует из книги в книгу (и из эссе в эссе новых адептов) пришелся на «другое время»: разработчики стоили дешевле, разнообразие направлений было меньше, а мир (бизнеса) менялся медленнее. Но даже в те времена, судя по тексту, ему всего пару раз посчастливилось участвовать в проектах где все было «грамотно».
Сейчас ситуация такова, что важнее не повторять старые мантры о том как мы все сделаем грамотно по книгам (а по факту все-равно «все переписывать» каждые 2-3 года), а стремиться гибко и осознанно подходить и к фичас и к архитектуре.
Статья выглядит не полной, без упоминания важности того чтобы давать обратную связь «правильно».
В «западной» корпоративной культуре это может быть и не так заметно с их любовью к эвфемизмам («что за дерьмо ты сделал?!» vs «хорошее начало, давай подумаем что можно улучшить»), но в exUSSR — вопрос правильного фидбэка стоит в полный рост. И как мне кажется — вносит гораздо больший вклад в неприятие такого фидбэка, чем какие-то «личные проблемы» получателя.
Если сделают систему достаточно открытой, чтобы могли принять участие крупные поставщики образовательных услуг, то это будет очень хорошо.
За условные пол-года при наличии желания вполне могут получаться сносные стартовые фронтендеры, аналитики, QA, UI/UXеры. Если там еще в комплекте инглиш будет — ваще красота.
Рассуждения про скорость доступа тут не причем (формально -возможно, но это на 'похвастаться"/«помериться», когда больше не чем)
Читаемость увеличит, если (some.foo()+someOther.prop)+2 присвоить переменной с осмысленным названием -то дальше по коду это будет легче пониматься.
Про «плохость» доступа черезмногие "." — все верно, у этого есть ь название (закон Деметры), Но это скорее относится к дизайну системы. Codestyle не исправит ошибки в архитектуре
Пока получается, что у вас были «какие-то процессы», вы «что-то сделали», и у вас стали «какие-то другие процессы». Это здоровое, но…
Да уж. Офисный мачизм, как он есть.
Почему все же решил остаться?
Вы так категорично рассуждаете о единственно верном подходе для абсолютно любых ситуаций, скажите, Судья Дред не ваш родственник?
Пока больше похоже, что вы просто «отложили» решение вопроса: уходит один из «ведущих» участников, команде нужно «деливерить», а вы взяли новичка на вырост в которого потребуется инвестировать время команды, что еще сильнее снизит показатели.
Вместо продолжения поисков вы «успокоили/успокоились» красивыми словами и сделали эту проблему проблемой «будущего себя»/«кого-то еще». (Либо, изначальная ситуация была не совсем такой как описано и на самом деле человек был не так чтобы и нужен)
А чего хочется получить таким кодом?
Почему не?
Просто немного странно удивляться, если пишешь
Напр pl/sql.
Сложно найти, легко потерять и невозможно забыть, а при этом на хранимках систем сделана куча.
По моим ощущениям тудаже стремиться j2ee, и возможно, в принципе java: "молодежь" выбирает js,python,go
Согласен.
Я бы тоже в реальном проекте скорее поставил на "внутреннюю инкапсуляцию")
Каждая потенциальная обязанность инкапсулируется в своем приватном методе, с разграничением по данным. Если вдруг будущее настанет — перенести метод в новый класс, интерфейс, внедрение зависимости — это несколько тривиальных модификаций.
Конечно, package private классы тоже могли бы решить проблему, но я в это "не верю": чаще всего заходишь в пакет, а там тысячи и тысячи классов из разных областей
"Kotlin как будущее..."?
По моим ощущениям он уже продолжительное время "настоящее"
Это конечно здорово, но, гораздо чаще у людей стоит вопрос: что делать с нереальными дедлайнами и в ситуации, когда доп.ресурсов не получить и скоуп работ не уменьшить.
Что грамотные менеджеры делают в этой ситуации?
А что плохого в 1с?
Толковый 1сник с правильными ценностями на вес золота в прямом смысле и может приносить реальную пользу бизнесу, если готов общаться.
Все так. Зп разработчиков таковы, что это давит на экономику компаний поэтому да х-х ив продакшн.
Но! Вот тут и проявляется настоящее мастерство, когда:
1) совместно с бизнесом делите всю систему на части с разной степенью критичности ошибок.
2) критические части делаете тщательно и без суеты с кучей тестов и qa в несколько слоев
3) некритичные — хх, максимально частый деплой, максимально дешёвая архитектура: лишние обобщения скорее вредны. Изменилась предметная область? Не жалко выкинуть и снова сделать быстро. Опирается на ядро из п 2.
Это позволяет и двигаться быстрее и экономить бюджет и явно управлять качеством, а если баг -сорян, у нас лапки, за счёт частого деплояпопрпвим и выложим через 30 минут
Сейчас ситуация такова, что важнее не повторять старые мантры о том как мы все сделаем грамотно по книгам (а по факту все-равно «все переписывать» каждые 2-3 года), а стремиться гибко и осознанно подходить и к фичас и к архитектуре.
В «западной» корпоративной культуре это может быть и не так заметно с их любовью к эвфемизмам («что за дерьмо ты сделал?!» vs «хорошее начало, давай подумаем что можно улучшить»), но в exUSSR — вопрос правильного фидбэка стоит в полный рост. И как мне кажется — вносит гораздо больший вклад в неприятие такого фидбэка, чем какие-то «личные проблемы» получателя.
Норадреналин побежден.
Скажите, удалось получить какие-то измеримые повышения производительности?
Если сделают систему достаточно открытой, чтобы могли принять участие крупные поставщики образовательных услуг, то это будет очень хорошо.
За условные пол-года при наличии желания вполне могут получаться сносные стартовые фронтендеры, аналитики, QA, UI/UXеры. Если там еще в комплекте инглиш будет — ваще красота.
Особенно радует порт сонара.
Читаемость увеличит, если (some.foo()+someOther.prop)+2 присвоить переменной с осмысленным названием -то дальше по коду это будет легче пониматься.
Про «плохость» доступа черезмногие "." — все верно, у этого есть ь название (закон Деметры), Но это скорее относится к дизайну системы. Codestyle не исправит ошибки в архитектуре
Спасибо за статью! Выглядит очень интересно, чтобы узнать о ней подробнее.
Будет здорово, если поделитесь потом вашими тестами.