Полковник
  • Почему программирование — это сложно

    Динамика другая. В этом вихре и подходы к документации устаревают быстрее чем жизненный цикл самого документа :)
    Я вот этим пользуюсь: c4model.com
    Хороший баланс практичности к временным затратам на поддержку и ридабилити

  • Нищая Европа 2021

    ЗеБот?

  • Почему программирование — это сложно

    Так у вас же наоборот, заказчики требовали убрать комментарии или я что-то не уловил?

  • Почему программирование — это сложно

    Оно то все есть, но это к проблеме актуации и наличия документации. Это роскошь. А вот понятный код это скилл.

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    Потому что гавношлепство и аутсорсинг по fixed price схеме :) Зачем там DDD или высокие материи? Там клей и сопли и немного знаний жабаскрипта

  • Почему программирование — это сложно

    Большинство ЯП не считая жабаскрипта и немного питона (ахтунг! троллинг :)), достаточно информативны и выразительны чтобы код читался как хорошая книга или хорошая шутка. Если не достаточно словарного запаса и грамотности то тогда приходится языками жестов пояснять.
    Комментарии имеют смысл когда поясняешь например работу сложного алгоритма или почему некое решение было принятно изначально, т.е. на контекстуальном и реже семантическом уровнях.

  • Почему программирование — это сложно

    Открываем. Оттуда же:

    Comments are not like Schindler’s List. They are not „pure good.” Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all.

    Ну и не единым Мартином же.

    Don’t comment bad code—rewrite it.

    — Brian W. Kernighan and P. J. Plaugher ©

  • Почему программирование — это сложно

    Проблема актуализации документации вечна. Никакой технический писака не будет поспевать за кодом который пишут команды разрабов. Да и смысла в этом нет. Что полезно, так это иметь high-level архитектурную документацию по контексту и компонентам, их связям. Команды разрабов в тестах, особенно E2E описывают что да как используя Gherkin Language, чтобы читабельно было. Ну и по хорошему бы flow diagrams иметь в актуальном состоянии

    Підтримали: Olexandr, anonymous
  • Почему программирование — это сложно

    Прям таки антиреклама EPAMу

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    Так это же не техническая проблема, а организационная. Наладить коммуникацию, понять домен, выработать общий язык (Ubiquitous Language), разбить по контекстам (Bounded Context) используя например Event Storming, выстроить workflows, определить контракты между ними на уровне DTOs. Кто сказал что легко будет? DDD, он не о паттернах больше, а о том как понять доменную область и занести ее в имплементацию системы.

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    Вопрос к квалификации архитектора, коммуникации с экспертами и зрелости команд разрабов. На то и разрабатываем итеративно, чтобы во время фидбек получать и курс корректировать. Если запустили до такого состояния, то тут уже как истинный самурай — сэппуку.

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    Зачем сидеть в песочнице? Заимплементил и выкатился, прошёл тесты свои и пользователи потыкали и в прод. Но это никак не коррелирует с DDD и другой внутренней кухней. Если чего будет и не так, то от кривых реквайроментов. Ну на это есть следующие итерации

  • Стоит ли идти в PM, пока обучаюсь на разработчика?

    С одной стороны- в качестве ПМ я смогу посмотреть на внутрянку сферы

    Это каким же образом? ПМы так-то в основном на раздаче пряников, кнутом пощелкать и щеки понадувать.

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

    Если нравится программировать да еще и переживаете по этому поводу, то с поиском работы тоже не должно возникнуть проблем, учитывая нынешние реалии рынка.

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    Собирать грабли в проде неблагодарное дело. Для этого должны быть всякие там UAT энвайроменты, E2E тестирование и прочий Agile который помогает мелкими интерациями выкатываться и смотреть на фидбек от пользователя. Тут все с умом нужно, а то так любой красивый подход можно гавном измазать или поддаться на провокации.

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    Классики от горя взяли и написали книги по Domain-Driven-Design чтобы по граблям не топтаться :)
    Тут же человек пишет про то что им яйца в тиски бизнес загоняет, а свои не достаточно большие чтобы сказать погодьте ребята, не гоните коней, давайте сядем и разберем что к чему и как оно работать должно.

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    До речі, мені приходилось проєктувати з нуля декілька таких працюючих проєктів так як технічний борг був настільки великим, що рефактор зайняв би 70% роботи. Клієнти самі приходили і казали «ось є старий ми хочемо з нуля новий».

    Так это и есть результат прототипов с душком, запущенных в продакшн. Долг он ведь не с ровного места растёт. Рефакторинг это лекарство от таких запоров и непроходимости — и тесты будут и архитектура стройная и конвенции кода и CI/CD вылизанный до полного автоматизма и так далее. А с тем подходом что вы описали, вы обречены с нуля переписывать в следующий ноль и так в рекурсии

  • Які етапи проходить задача в гнучкій розробці ПЗ та як оптимізувати час на її виконання

    В принципе вы описали стандартный процесс гавношлепства так знакомый каждому гребцу на галере. И каким боком тут вообще гибкая разработка ПО? И без Жиры конечно никуда.

    Знаючи, на що витрачається час на кожному етапі розробки і при аналізі проєкту загалом, можна прискорити час виконання кожного таску в короткій або довшій перспективі

    Это понятно. Но вы обещали рассказать

    як оптимізувати час на її виконання

    И все-таки как?

    Зазвичай, бізнес не вдається в деталі технічної частини і вимагає якомога швидше викотити новий функціонал на прод

    Это как не интересоваться планированием и ходом постройки собственного дома бригадой строителей и требовать как можно быстрей выполнить все работы. Очень дальновидно. Хотя если дом не для себя строите, а как подрядчик, то и хер с ним.

    Під тиском програмісти часто нехтують хорошими практиками, щоб в короткій перспективі розробити функціонал якомога швидше, і що в довгій перспективі збільшує час на виконання кожного наступного таску

    Это описание классического гавнокодера, а не программиста. А где же этика и профессионализм? Или в вашей компании практикуют пытки? Так это запрещено конвенцией ООН. Чесслово, не инженеры пошли, а кикие-то мамкины кодошлеперы. Постоянный и беспощадный рефакторинг на проекте залог его успеха.

    своїм досвідом оптимізації часу на проєктах

    Да не нужно его оптимизировать. Для бизнеса нужен работающий софт, производящий профит.
    Короче говоря, стоимость поддержки многократно выше стоимости реализации и внедрения, с течением времени. Усилие по внедрению — это одноразовая стоимость, которая никогда не меняется, поэтому на нее практически не влияет время.

    Підтримав: Артем Доценко
  • Как обучиться на Python и найти первую работу

    В каком порядке и вообще какие шаги сделать, чтобы найти первую работу?

    С чего-то попроще чем нейронные сети, сайтики там всякие на Django или Flask. Сюда же Git и базовый SQL как must have

    Прошёл курс python-для новичка на сайте stepik. Сейчас прохожу курс python-для продвинутых.

    Их не только проходить нужно, но еще и применять полученные знания и чем скорей тем лучше.

    Підтримав: Symonenko Volodymyr
  • Что такое ретроспектива и как с ней работать, чтобы бэклог не стремился к бесконечности

    Если есть проблема/предложение то зачем ждать 1-4 недели до ретро?

    Ну как же зачем? Есть фреймворк и его церемонии. Scrum ведь agile? Вот и развивайте гибкость памяти чтобы не забыть это озвучить через 2 недели на ретро :)

    Очередной аджали булшит. Как переливать из пустого в порожнее что бы тебя не уволили с работы

    Так в этом и суть этих весьма интерсных социальных игрищ — гибко подстраивать себя под все правила и обряды и делать хорошую мину при плохой игре

    Scrum/SAFe — имеющие ничего общего с Agile, созданные для чисто комерческих целей и зарабатывания на всем движении гибких методологий. Или компания считает свои команды разработчиков такими тупыми что они не могут освоить 10 страниц гайда и им нужны скрам мастера для этого?
    А полюбился и прижился скрам еще за то, что там есть estimation-ы, которые не работают, но на которые так уповают еще одни дармоеды, ценители хлыста и пряника.

    В этом плане, куда более симпатичен Kanban, который осваивается за пол часа, не требует гайдов, курсов и сертификаций для канбан-мастеров и строится таки на базе основных принципов Agile.

    Підтримав: User
  • Каким видом спорта вы занимаетесь?

    главное чтобы нравилось

    Підтримав: Andrii Shchurkov
← Сtrl 123456...8 Ctrl →