Ну, запутать можно и внутреннюю структуру вызовов внутри монолита, так что черт ногу сломит — откуда что берется, поэтому хорошо сделанный монолит — это уже по факту тесно связанная куча «микросервисов», только их интерфейсы взаимодействия не сетевые.
Отторгнуть такие квазимикросервисы из монолита вовне не составит проблемы, но есть ли в этом смысл — это зависит от контекста задачи. При отторжении мы естественно получаем необходимость выстраивания взаимодействия с «потребителями», ранее решаемое платформой, на которой крутится монолит, а как бонус — получаем возможность вынести сервис на другие серверные мощности, возможность использования сервиса другими приложениями и определенную свободу по изменению внутренних механизмов сервиса, не оказывающих влияния на интерфейс взаимодействия, а так же возможности более легкого масштабирования и резервирования сервиса.
О серебристости GraphQL речи не идет, но есть два фактора, которые позволяют его эффективно применить в ряде задач. Во-первых — это его явные преимущества, которые я перечислил выше, а если говорить коротко — то это его высокая гибкость по сравнению с тем же REST.
Второе же заключается в том, что используя graphql необходимо и мыслить в концепции graphql, попытки же сделать «как в REST, только GraphQL» к хорошему явно не приведут, что, в общем-то, справедливо для любой технологии.
Верно — graphql. Избавляет от боли модификации api, кача избыточных данных, разрастания набора эндпоинтов. Запихнул его в свой проект с микросервисами — теперь у меня свой проект с graphql и микросервисами: )))
А кроме шуток, и говоря о заметке уровнем выше про опыт с микросервисами — я полагаю, что надо еще и осторожнее быть со связями между сервисами, то есть в идеале один сервис связан не более чем с двумя другими сервисами, обеспечивая иерархическое дерево, иначе геморрой при изменениях начинает расти экспоненциально как функция от количества связей на сервис. С одной стороны такое ограничение вроде как и противоречит концепции широкого переиспользования, с другой — это продиктовано соображениями локализации и сдерживания сложности. Если в такой ограниченной микросервисной архитектуре возникает необходимость изменений какого-либо сервиса, то это хотя бы не порождает слишком много изменений, а те, что неизбежны — по-крайней мере распространяются в известном направлении — вдоль своей ветви. Но это так — интуитивные соображения безопасности, реального опыта эксплуатации пока мало.
Микросервисы иногда напрашиваются на старте — когда есть куски работы, слабо связанные по времени исполнения (имеется ввиду процессорное время) и результаты работы этих кусков допускают возможность краша. Сейчас работаю над проектом, в котором есть основной сервис со своей базой данных, и есть добытчик данных, которые основной сервис периодически запрашивает у добытчика. Оба сервиса, конечно, синхронизированы по времени обновления данных, но если у добытчика отказ, то основной процесс от этого не страдает — он работает на уже собранных данных — тут изначально напрашивалось разделение на сервисы, что и было реализовано в архитектуре. И здесь проявляются преимущества микросервисов — добытчики данных могут менять алгоритмы сбора данных как угодно без необходимости править весь проект — требуется лишь поддерживать стандарт интерфейса передачи данных между сервисами, можно балансировку и резервирование легко сделать для добычи данных — надо лишь на основном сервисе добавить адреса добытчиков. Сервисы в данном случае занимаются каждый своей работой.
Накладными расходами тут являются поддержание интерфейсов между сервисами — как в архитектурном плане (согласованность форматов), так и в физическом (доступность сети), и, конечно, мониторинг. Изначально я хотел вообще сделать основной сервис с функциями контроля над добытчиками, но лимит времени на разработку не позволил чрезмерно углубляться, будет развитие проекта — вот тогда и можно будет дальше эту тему развить.
Статья же — однобокая, но она так и задумана, наверное. Ведь действительно лучше сделать работающее приложение, которое еще сто раз поменяется, чем стараться изначально все эти сто предстоящих изменений предусмотреть — и, конечно, все равно ошибиться, ибо всего не учтешь. Но то, что изначально хорошо можно вынести в отдельный сервис — почему бы и не вынести, если есть время и ясное понимание и обоснование преимуществ такого решения.
Тут даже вопрос не про выставление статуса, а про адекватность и ответственность разработчика. Верно то, что адекватному и ответственному просто не нужен этот контроль от слова совсем — он только мешает, а вот неадекватного и безответственного человека — хоть законтролируйся — все равно в лучшем что-то ну очень посредственное получишь. В итоге вся идея контроля — не от большого ума и высокой компетенции менеджмента компании, сама цель непонятно — что хотят контролировать и чего добиться? Самоудовлетворения своей значимости (ай эм биг босс!) или поддерживать иллюзию контроля? В самом деле, вот просто житейски — какой из этого прок и кому?
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Очень возможно — я не претендую на исчерпывающую полноту своего личного опыта, однако он имеет место быть, и, насколько мне известно — он у меня не уникален и довольно распространен. Соответственно здесь, в рамках обсуждения ваших методов контроля мы и делимся своими соображениями и опытом, что потенциально могло бы и вам пригодиться, если смотреть на излагаемое как на источник информации, а не попытку подорвать ваш авторитет или чего-то в этом роде.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
А на чем эти построения о «командной работе» основаны? Я, например, как человек приземленный, предпочитаю свои соображения соотносить с практикой. И мой опыт говорит, например, о том, что есть очень большие интервалы, когда никакой командной работы — не требуется, и даже сидя в офисе — ты сам в себе, в своей работе. Есть, разумеется, и напротив — интервалы, когда требуется командная работа — это особенно важно на этапе выработки концепции, на этапе тестирования большого блока, на этапе запуска и первых дней жизни проекта — тут разговора нет и никакому вменяемому разработчику не придет в голову уклоняться от этого. Но жесткая структура митапов — ежедневно, например, вне зависимости от контекста — это не более чем синдром контроля головного мозга, а не необходимость в виду реальных предпосылок. Это тот же микроменеджмент, задекорированный под благие намерения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Значит вы пока не работали над проектами, где один человек уже не в силах справляться со всеми этими функциями.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
Мои 3-4 часа — это наиболее плодотворные часы, когда создается что-то новое в проекте, естественно, бывает и больше, но в среднем — примерно столько в день. Больше 4 часов такой активной работы по моим наблюдениям — это уже приглаживание кода, пробы, отладка и т.д., но никак не наращивание функционала проекта. Поэтому я свой день и делю на две половины — в первую у меня обычно творческий подъем, я с прошлого вечера наметил и обдумал что и как сделать — а с утра начинаю воплощать. Заряда и придумок хватает как раз где-то на 3-4 часа.
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
Плюсанул бы, но нет правов: ) Я в последние полтора года работаю на фрилансе. Точнее — на подряде, проектно и со свободным графиком — есть план с дедлайнами по этапам, а внутри этого периода я могу работать где и сколько угодно — моя задача принести в клювике к обозначенному сроку результат.
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Ну, раз вы за эти два с половиной года еще не устали, значит либо не всегда такой подход был, либо действительно за архитектурой приглядывают. Потому что говнокод — здесь я под говнокодом подразумеваю не забагованный и/или криво писаный код, а код, который пишется не в какую-то хорошо продуманную структуру, а произвольно лепится — неизбежно приводит к тому, что в продукте начинаются суровые проблемы согласованности работы компонентов. Это как строить здание без плана, прифигачивая, что в голову пришло. Я поэтому не люблю «хакеров», которые могут — да — сделать финт в каком-то фрагменте, но этот финт на самом деле часто представляет собой сокрытие проблемы архитектуры, в виду чего и приходится изворачиваться; да и даже будучи к месту — зачастую наращивается сложность проекта без крайней на то необходимости — а это, как говорят знающие люди, самое «дорогое» в разработке — сложность.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
А сколько времени проект существует с таким подходом к разработке?
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
Тоже посчитал — 3-4 часа в день именно на написание кода. Тому несколько причин:
1. Прежде чем писать — надо понять что именно надо написать. Придумать архитектуру решения, если речь не идет об узкой задаче. На это уходит много времени, в рамках проекта — до 30%.
2. Поняв что надо сделать — надо понять как это сделать. Есть, конечно, наработки, но всегда есть и альтернативы, всегда есть что-то свежее. В итоге, требуется написать прототип решения, иногда — несколько, чтобы оценить что выбрать. Если сроки сильно ограничены — делаю так, как наиболее знакомо, но при этом заказчик получит возможно не лучшее решение. Это еще 30% времени.
3. Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость. Производительность со временем падает, ничего хорошего не получается. Можно работать больше, если не прикладывать усилий для разбирательства в делаемом — то есть шпарить по шаблонам, но это опять же в ущерб возможностям и не всегда вообще это доступно в силу специфики задачи. — Это еще 30%
Еще 10 оставшихся процентов — это развертывания всего на свете, деплои, тесты и прочая.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа — итого шесть, еще около 2-3 часов отвожу на изучение платформ, инструментов, технологий, на эксперименты. Работая больше — ловлю себя на том, что острота мысли падает и в итоге работаешь отнюдь не лучше и продуктивнее, а совсем напротив.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить… Что тут сложного! На всякие раздумья и прочее их жаба смотрит осуждающее и с полным непониманием.
Отторгнуть такие квазимикросервисы из монолита вовне не составит проблемы, но есть ли в этом смысл — это зависит от контекста задачи. При отторжении мы естественно получаем необходимость выстраивания взаимодействия с «потребителями», ранее решаемое платформой, на которой крутится монолит, а как бонус — получаем возможность вынести сервис на другие серверные мощности, возможность использования сервиса другими приложениями и определенную свободу по изменению внутренних механизмов сервиса, не оказывающих влияния на интерфейс взаимодействия, а так же возможности более легкого масштабирования и резервирования сервиса.
Второе же заключается в том, что используя graphql необходимо и мыслить в концепции graphql, попытки же сделать «как в REST, только GraphQL» к хорошему явно не приведут, что, в общем-то, справедливо для любой технологии.
А кроме шуток, и говоря о заметке уровнем выше про опыт с микросервисами — я полагаю, что надо еще и осторожнее быть со связями между сервисами, то есть в идеале один сервис связан не более чем с двумя другими сервисами, обеспечивая иерархическое дерево, иначе геморрой при изменениях начинает расти экспоненциально как функция от количества связей на сервис. С одной стороны такое ограничение вроде как и противоречит концепции широкого переиспользования, с другой — это продиктовано соображениями локализации и сдерживания сложности. Если в такой ограниченной микросервисной архитектуре возникает необходимость изменений какого-либо сервиса, то это хотя бы не порождает слишком много изменений, а те, что неизбежны — по-крайней мере распространяются в известном направлении — вдоль своей ветви. Но это так — интуитивные соображения безопасности, реального опыта эксплуатации пока мало.
Накладными расходами тут являются поддержание интерфейсов между сервисами — как в архитектурном плане (согласованность форматов), так и в физическом (доступность сети), и, конечно, мониторинг. Изначально я хотел вообще сделать основной сервис с функциями контроля над добытчиками, но лимит времени на разработку не позволил чрезмерно углубляться, будет развитие проекта — вот тогда и можно будет дальше эту тему развить.
Статья же — однобокая, но она так и задумана, наверное. Ведь действительно лучше сделать работающее приложение, которое еще сто раз поменяется, чем стараться изначально все эти сто предстоящих изменений предусмотреть — и, конечно, все равно ошибиться, ибо всего не учтешь. Но то, что изначально хорошо можно вынести в отдельный сервис — почему бы и не вынести, если есть время и ясное понимание и обоснование преимуществ такого решения.
И, вообще — есть в этом всём что-то такое… Novell Netware, OS/2… деревья раньше были не только большими, но и разными: ) И это было прекрасно.
И еще справедливости ради надо таки сказать, что как без повара нет ресторана, так нет его и без хорошего администратора, официантов, дяди Васи, отвечающего за закуп продуктов, даже без — прости господи — без маркетолога, который этот ресторан пропиарит хорошо и поэтому будет спрос на него… Так что это всё же общий труд и в нём нет главных. Правда высокие менеджеры порой стараются убедить всех своих сотрудников в обратном — так ими легче управлять.
Впрочем, я не настаиваю на обсуждении. Если же вы не против — с интересом познакомлюсь с вашим взглядом на командную работу. Я всегда рад ознакомиться с иной точкой зрения.
Если вы такая продвинутая компания, то я бы порекомендовал вам к действительности и обратиться — да вот хотя бы провести ненавязчивый опрос среди своих же сотрудников — что дают им эти ваши контролирующие рамки? Тот же Гугл с его квазианархией — по крайней мере как это преподносится — про возможность работы над своими проектами «в рабочее время», про возможность работать как удобнее и прочие плюшки — вы думаете они там просто зажрались? А я полагаю, что там умные люди просто воспользовались старым добрым тезисом: «Если не можешь прекратить безобразие — возглавь его.» И поимели профит с этого вместо затрат на контроль.
А ваша позиция уже становится чисто защитной — типа возражающий вам просто неправильный (согласно вашим правильным правилам). Ясен пень, что навязываться вам никто не навязывается и не переубеждает — мы лишь говорим о ДЕЙСТВИТЕЛЬНОСТИ, как оно на самом деле происходит, и что можно эту действительность обратить себе на пользу, а не пытаться с невеликим успехом подогнать под свои представления о правильном.
Работал в команде и очень хорошо себя чувствовал — там да, мог погружаться и на более продолжительное время. Сейчас — нарабатываю опыт, и пока вся свистопляска с ролями при всех неудобствах, в целом — хороший и ценный опыт. Поднаторею — начну искать более специализированных рамок деятельности.
Уже есть мечтания, как я такой клёвый в клёвой команде, где каждый своим занят, где тесты покрывают всё, ревью кода проводят, устраивается внутренний обмен знаний на постоянной основе между сотрудниками, сеньоры доброжелательны и мегакомпетентны и т.д.: )))
Кстати сказать, еще одна программистская особенность — это необходимость периодической ревизии сделанного. Конечно в моем случае накладывается пока еще не слишком большой опыт в работе с той платформой, что я работаю, хотя и не только это влияет — те же неизбежные, постоянные и достаточно высокого темпа обновления самих платформ, приводят к тому, что постоянно смотришь на код и видишь новые возможности реализации, новые подходы. Это не говоря уже о том, что сам заказчик подкидывает новые соображения, в свете которых архитектура решения требует изменений.
Ну и конечно особенность моей работы — в почти полном цикле: я проясняю ТЗ, придумываю архитектуру, сам же пишу функционал, тестирую и сам его выкатываю в продакшн — фактически объединяя в себе несколько ролей: аналитика, менеджера, программиста, тестировщика и DevOps. И это не хваставство — это в некотором роде недостаток в моей работе, ибо я не могу себе позволить концентрироваться полностью на чем-то одном. А вот заказчик зачастую воспринимает меня — как исключительно программиста, совершенно упуская из виду очень большую часть проделываемой мной работы, и попытки разъяснить это часто натыкаются на непонимание:
— Аналитика? Какая нафиг аналитика?! Мы же тебя ясно сказали — хотим сайт. С кнопочками! Что тут анализировать? А про архитектуру… так зачем тебе архитектура — садись да пиши! Всё ж ясно!
— Менеджмент? Да ладно, просто сделай к такому-то числу.
— Тесты? Какие тесты?! Пиши сразу правильно и хорошо — и тестировать не надо будет. Или ты часом может не профессионал?
— DevOps… слов понавыдумывают! Наш Вася легко тебе предоставит сервер с облака?! Настраивать там что-то? Да что там настраивать — это ж сервер, и Вася тебе его даст!
При наличие более узкой области работы — возможно и получалось бы больше погружаться, хотя и тогда от постоянного изучения никуда не денешься, а вот со стороны заказчика это выглядит как конструктор собрать из уже готовых деталей — и на что там еще можно время потратить как не на отлынивание от работы!
За полтора года я сделал «от и до» 3 средних проекта, 1 маленький, 1 сняли с разработки заказчики (полпроекта так сказать среднего) и еще 2 средних проекта сейчас в разработке в разной стадии готовности. Ну то есть вполне результативно время прошло, если иметь ввиду, что проекты я тяну от составления ТЗ до выкатки в продакшн со всеми этими DevOps делами включительно.
И вот я читаю иногда — не в этой статье — про офисные квадратно-гнездовые методы программирования — и уже, знаете, ужасаюсь. Страшно, как в дурдоме. Непонятно кому и зачем надо это вот такое вот. Создается впечатление, что настаивающие на контроле люди просто неадекватны — никакой эффективности от сидения в офисе не прибавляется, подконтрольные никакого удовольствия от работы не испытывают и, как следствие, тихо саботируют, вместо того, чтобы в творческом полете поражать и себя и заказчика плодами своего труда, метрики к изначально творческому процессу применяются нерелевантные и контрпродуктивные, заставляющие исполнителя симулировать деятельность, а не действительно делом заниматься. В общем — реально страшная картина помешательства.
Что же до плохо написанного кода (истинный говнокод так сказать: ), кода, написанного второпях (костыли) и прочий «ад» — то это не страшно, если эти фрагменты существенно изолированы, тут как раз ситуация лечится локальным рефакторингом. Но изолировано что-то может быть только в соответствующей продуманной структуре — отсюда снова и опять про бдение архитектуры.
Грань тут очень тонкая, и проект при таком подходе рискует превратиться в большой ком допущений. Сделанные допуски — никуда не исчезнут сами собой, и сумма их — отнюдь не арифметическая, а вызывает тут же синергию, только со знаком «плохо». Единственное спасение — это продуманная архитектура, которая позволяет облагородить приложение со временем рефакторингом функциональных блоков, но из сказанного автором статьи, не видно, что контроль над архитектурной чистотой приложения свято блюдется, да и слабо верится, что такое возможно в условиях постоянного фичегенрирования — концепт неизбежно начинает развиваться хаотически.
В общем, что-то мне подсказывает, что этому проекту не более года или около того, и вкушение всех последствий — впереди.
1. Прежде чем писать — надо понять что именно надо написать. Придумать архитектуру решения, если речь не идет об узкой задаче. На это уходит много времени, в рамках проекта — до 30%.
2. Поняв что надо сделать — надо понять как это сделать. Есть, конечно, наработки, но всегда есть и альтернативы, всегда есть что-то свежее. В итоге, требуется написать прототип решения, иногда — несколько, чтобы оценить что выбрать. Если сроки сильно ограничены — делаю так, как наиболее знакомо, но при этом заказчик получит возможно не лучшее решение. Это еще 30% времени.
3. Концентрироваться на активной интеллектуальной задаче более 3-4 часов в день — значит накапливать усталость. Производительность со временем падает, ничего хорошего не получается. Можно работать больше, если не прикладывать усилий для разбирательства в делаемом — то есть шпарить по шаблонам, но это опять же в ущерб возможностям и не всегда вообще это доступно в силу специфики задачи. — Это еще 30%
Еще 10 оставшихся процентов — это развертывания всего на свете, деплои, тесты и прочая.
Я сейчас стараюсь разбивать свой рабочий день на две части по 3 часа — итого шесть, еще около 2-3 часов отвожу на изучение платформ, инструментов, технологий, на эксперименты. Работая больше — ловлю себя на том, что острота мысли падает и в итоге работаешь отнюдь не лучше и продуктивнее, а совсем напротив.
У многих же заказчиков, полное впечатление, представление о программировании как о копании траншеи — от забора до заката. Причем сразу — сел и давай кодить… Что тут сложного! На всякие раздумья и прочее их жаба смотрит осуждающее и с полным непониманием.