• АМА с Хабром #21. Тестируем новый WYSIWYG
    0
    Нововведение очень не удобно. Редактирование очень отличается от традиционного, как например в ворде, когда есть одно пространство — лист, и на нём происходит всё редактирование. Теперь этого нет. Взять и выделить через CTRL+A весь текст теперь не возможно. Вообще процесс нестандартный. Это какой-то VIX-конструктор для статей
  • Представление модели предметной области (МПО) и точек интеграции
    –1
    за все диаграммы не отвечу)
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    сейчас подумал, вообще архитектурный слой нет проблем использовать в любом проекте, где используется ООП язык, так как анемичная модель — это частный случай применения ООП. Любой функциональный метод можно обернуть в ООП обёртку из которой можно сформировать анемичную модель.
  • Ремонтные работы или IT-трансформация? Как мы разработали архитектуру с нуля и создали платформу для малого и среднего бизнеса
    0
    По сути, вы выполнили такие технологические внедрения как:
    — CI/DI
    — демостенды (которые позволяют выполнять проверенную приёмку заказчиком)
    — разделение на микросервисы
    — замена Legacy монолита на адаптацию Spring+Comunda

    С точки зрения реальности, в использовании данных технологий нет ничего нового и есть проекты 2014 года, в которых уже замечательно реализуются микросервисы, то есть потенциал уже давно обоснован, как и с другими технологиями.

    Вы выполнили рациональные внедрения и получили ожидаемый результат. Сами по себе идеи не новы. Поздравляю вас. Хорошо было бы узнать как вы сдавали релизы заказчику без демостанедов ранее и как ваша жизнь изменилась после.

    И интересно узнать более подробно, как вам удалось обосновать подобные внедрения? Ведь контакт менеджера с клиентом можно было бы реализовать в виде набора костылей на скорую руку, как это чаще всего происходит в российском ИТ :)
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    не интересует ваш короткий фидбек, спасибо, не пишите сюда
    «Ну рально то что вы описываете это не об архитектуре» — чувствуется 15 летний опыт…
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    у вас слишком много времени для троллинга…
    не пишите сюда больше
    удачи!
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    чтобы дать ответ как у вас, можно даже не иметь никакого опыта в разработке
    зайдите для начала на википедию, прочитайте определение Архитектура ПО и всё что в статье, потом можем пообщаться
  • Основные функции ETL-систем
    0
    Спасибо, даёт общее представление.
    А как по вашему, может ли конфигурация 1C Конвертация данных считаться ETL системой? Там по сути то же самое просходит
    its.1c.ru/db/metod8dev/content/2943/hdoc
  • Как делать в два раза больше и получать от этого удовольствие
    +8
    Я вчитался в статью и вот что я вижу.
    1. У вас была старая команда, которая сделала проект как можно быстрее, но из-за этого накопила тех. долга, на который бизнес не хотел выделять времени.
    2. Из-за тех.долга в команде большая токсичность плюс бизнес влезает в ИТ процессы, видимо чтобы ускорить работу.
    3. Из-за тех.долга ваш проект напоминает ведро с гайками, поэтому релиз каждый раз долго готовится

    Что вы сделали
    1. Решили перейти на другой стэк, вместо выполнения бэклога. Бизнес вложил деньги в методику соседнего проекта
    2. Ретро решили проводить только в карайних случаях. Хотя пишете что ретро проводите раз в месяц, что нормально, если спринт 2 недели
    3. Разогнали старую команду и наняли новую
    4. Централизовали роль архитектора
    5. Отказались от спринтов и заменили их на некие due-даты (кстати что это?)

    Интересно откуда вы пригласили архитектора (из старой команды, из соседнего проекта или со стороны).
    Получил ли руководитель соседнего проекта повышение и куда пошёл руководитель старого легаси проекта.
    И как вам удаётся контроллировать бизнес? Так как если появится менеджер от бизнеса, скажет впаять вот эту кнопку в релиз или какую-то таблицу в бд, что вы будете делать? :)
  • Методика проектирования архитектурных слоев на основе анемичной модели и DDD
    0
    Эта статья прежде всего ориентирована на разработку корпоративных приложений, но возможно может быть использована в любом месте, где можно использовать объектно ориентированный подход.

    Информационные технологии тем и хороши, что здесь как раз можно хрущёвку превратить небоскрёб. Под этим надо понимать программный продукт, которым пользуется бизнес-пользователь.
    1. Берётся хрущевка
    2. Проводится функциональный анализ -> выделяется документация, все возможные виды кейсов действий пользователя, тест кейсы, что формируется в тз
    3. Проводится технический анализ, выделяются структуры БД, слои, настройки, инфораструктура, точки интеграции.
    4. Дальше 2 пути, либо постепенный рефакторинг, либо waterflall проект

    Когда я работал над проектом, я выбрал waterfall. Получился один марафон в 2 недели, когда я полностью переписал всю систему, которая инкрементно копила функционал в течение почти года. Далее замена у пользователей одной версии на другую и вот — небоскрёб, на работу по ошибкам уходило 0 минут в неделю.
  • Методика проектирования архитектурных слоев на основе анемичной модели и DDD
    0
    Я здесь кратко упоминаю в шаге 1 о тест-кейсах. Конечно их роль огромна, как и роль тестировщика. Изначально в статье были пункты Реализация и Тестирование, а в аналитике было подробное описание того как составлять скрипты, одновременно являющиеся и задачами на разработку по BDD и тест кейсами для приёмки таких задач, но это выросло в 2 отдельных статьи, которые я сейчас параллель пишу. Так что всё впереди)
  • Методика проектирования архитектурных слоев на основе анемичной модели и DDD
    0
    Есть ощущение, что класс CloudManager нарушает принцип SRP — это видно даже по нарисованной схеме, как будто бы нужно разделить на три разных класса.


    Здесь принцип разделения по порождающей среде. Документы могут быть в виде файлов на жёстком диске, а могут быть в виде документов в облаке (у какого-либо из операторов). Таким образом есть 2 среды.

    Набор операций может относится к той или иной среде. Общее между этими средами — это доменная модель.

    Фигурными скобками я отметил сущности к котором относятся методы. Сервис FSManager не работает с сущностями Company, Signer — эти сущности порождаются только облаком, а облако одно для всех сущностей. Можно было бы сделать ещё большую декомпозицию, в рамках декорации сервиса CloudManager, но мне достаточно было приведённой.

    Как, взглянув на проект, понять сколько тут слоев, и какой класс к какому слою относится? И где границы слоя.


    Анализируя стэк вызова от UI до БД или точки интеграции.
    Например, в MVC приложении, перейдя на страницу
    — нажимаете какую-то кнопку, напирмер создать заказ. — это начальная точка стэка вызова
    — ловите в отладчике точку останова в обработчике
    — следуете по шагам до тех пор пока не провалитесь из контекста контроллера, в какой-либо вложенный/связанный контекст — это 1 слой
    — во вложенном контексте так же следуете до вызова следующего вложенного контекста — это 2 слой
    — выпоняете это до тех пор, пока не дойдёте до обращения к БД, файлу или точке интеграции (вызывающией связанную систему) — это конечная точка стэка вызова
    — выполняете такой анализ для всех вызово вложенных контекстах во всех слоях, таким образом поняв к каким конечным точкам происходит обращение при клике заданной кнопки и через какие контексты происходит этот вызов
    — выписав и увидев так все контексты вы можете сориентироваться какие слои они образуют, от каких можно отказаться, а какие можно объединить в один слой
  • Методика проектирования архитектурных слоев на основе анемичной модели и DDD
    0
    эту статью-методику я пишу один раз, чтобы на неё в дальнейшем ссылаться
    написание подобных статей трудозатратно и на её написание ушло несколько недель и это кусочек от общей серии методик которые я собираюсь написать
    поэтому сразу всё включить в эту статью не получилось и я решил зафиксироаться пока на текущей редакции, а потом дополнить её в соответствии с вопросами, поэтому добавляйте статью в закладки, она будет дополняться

    про анемичную модель — я ещё добавлю описание в этой статье и ссылки на неё из этапов методики (пункт 3)

    роль DDD здесь частична и используется для образования одного из слоёв (слой бизнес логики DocumentSDK), термины я выделил и выписал, чтобы в дальнейшем использовать их в этой статье. Подобные короткие локоничные определения вам будет не просто найти в интернете. Их я нашёл перелопатив Вернона и Эванса, так что если вам понадобятся, можете их в дальнейшем найти в этой статье.
    так же с течением времени я свяжу эти определения и создам представление о том какую роль DDD принимает в проектировании многослойного приложения
  • Методика проектирования архитектурных слоев на основе анемичной модели и DDD
    0
    по документации скоро будет несколько статей по опыту создания предметно-ориентированной пользовательской документации
    и архитектурной документации
  • История одного удачного применения SRP в Legacy проекте
    0
    описал примеры и инструкцию в статье habr.com/ru/post/509452
  • 15 базовых советов по Git для эффективной работы каждый день
    +2
    Я предпочитаю работать в консоли и большая часть команд и советов в этой заметке будет про консольный клиент. Это своего рода первая рекомендация — используйте консольный клиент для ежедневной работы с репозиторием и регулярно его обновляйте. В консольном клиенте в первую очередь появляются новые возможности и исправления ошибок.


    Какая-то странная у вас аргументация.
    Ни разу не сталкивался с ошибками git клиента
    А вот то что в VS 2019 появился squash, мне во многом облегчило жизнь
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    Чувство, что меня троллят, но отвечу)
    Слой архитектуры воспринимается, как будто есть слой архитектуры, а есть ещё какой-то слой (не архитектуры)
    Когда я говорю Архитектурный слой, подразумевается, что сама архитектура состоит из слоёв
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    какой был бы лучше?
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    Спасибо за ссылку, почитаю.
    А вы можете сейчас сказать на сколько отличается определение архитектурного слоя в этой книге и в статье?
    Чем-то можно определение дополнить?
    Суть в том, чтобы выработать короткое и понятное определение, чтобы всем ими пользоваться.
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    FilesAPI и ConverterPlugin используется одним из классов DocumentsLogic. На этом слое есть класс-менеджер FS, который представляет собой обёртку над файловой системой. Все действия с файловойсистемой внутри этого слоя выполняются черезе класс FS. В реализации класса FS есть непосредственные вызовы FilesAPI и ConverterPlugin.
    ConverterPlugin — это отдельная сборка dll, которая через рефлексию подключается к основному проекту и расширяет возможности FS.
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    Спасибо за замечание. Я думал об этом но не упомянул. В gamedev и микроконтроллеры не лезу. Только корпоративные приложения.
    Доработал статью, заголовок уточнил
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    до архитектурного слоя останавливался на понятии Прикладной слой, но Архитектурный слой понятие уже закрепилось более остальных (уровни абстракции, слои абстракции, слои приложения...)
  • Архитектурный слой (в корпоративной разработке). Понятие, определение, представление
    0
    Применительно к слоям эта метафора уже давно применяется, я решил остановиться именно на ней (есть ещё метафора уровни, слои абстракции), так как она часто используется в Мартине Фаулере — Шаблоны корпоративных приложений.
  • Ты добавил всего две строчки. Почему на это ушло два дня?
    0
    Вам ничего не мешает попросить саппорт уточнения задачи и продолжать ей заниматься самостоятельно, так как будто вы и не просили. Вы ничего не потеряете от этого, но вам могут помочь.

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

    По вашему случаю я вижу, что у вас есть какой-то сырой функционал, который не совсем подходит клиентам. И нет недостатка сил разработки, то есть вы бы сделали, если бы точно знали как. Это показывает в чём у вас узкое место.

    Вы можете отказаться и не тратить время на сырой функционал.
    Либо реализовать его в точности по запросам клиента. Так как «ошибки» — это могут быть не ошибки вовсе, а неточность изначальной задачи и вы выяснили новую фичу.

    Пока что я вижу, что вы берёте на себя чужую ответственность.
  • Ты добавил всего две строчки. Почему на это ушло два дня?
    0
    Это как клиент не видет никаких действий во втором варианте?
    Вы обратились к первой линии за уточнением. Первая линия обратилась к клиенту. Клиент видит как минимум, что его проблемой занимаются.

    В первом случае, когда разраб сам что-то пыхтит, никто ничего не видит и потом приходится объяснять куда уходит время.

    Равзе нет?
  • Ты добавил всего две строчки. Почему на это ушло два дня?
    0
    Ничего не мешает задавать вопросы саппорту, как авторам задачи. У них есть все возможности общаться с бизнес-пользователями, а если нет, то стоит эту возможность найти.

    Или понять что дороже, 1) ждать когда разраб сам догодается что от него нужно 2) организовать коммуникацию с бизнес-пользователями.
  • Ты добавил всего две строчки. Почему на это ушло два дня?
    –2
    Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование. Я стараюсь получить как можно больше из той информации, которая есть в наличии.


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

    Я хочу понять, вы никогда по своим задачам не связываетесь с их создателем, чтобы уточнить их?
  • Как Греф с программистами боролся
    0
    Греф говорит, что сейчас время АКТИВНЫХ людей. Я примерно представляю, что Грефу не нравится в программистах сбера и почему он хочет что-то поменять. Но активность это скорее человеческая черта, чем профессиональная, поэтому неясно причём тут программисты. Видимо просто крайние оказались в сбере
  • Предвзятый и субъективный взгляд на резюме разработчика
    +2
    Мысли, что чем больше опыта тем лаконичнее стараешься описывать свои достижения) иначе резюме становится слишком большим
  • Мой опыт разработки приложения, как PM
    0

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


    Если вы лендинг за 30к делаете, то тоже можно без документации обойтись.
    Не торопитесь с ответом. Обдумайте

  • О стартапах и стартаперах
    0

    Складно пишете

  • Мой опыт разработки приложения, как PM
    0
    И ещё вариант обоснования — посчитать
    — на сколько уменьшится время интеграции нового разраба в проект, за счёт того, что он сможет самостоятельно освоить систему
    — сколько будет сэкономлено времени на обращение и отвлекание коллег
    — сколько будет времени сэкономлено на уменьшении времени на анализ и вспоминание того как что должно работать

    Все эти моменты выливаются в трудочасы, сдвигание сроков, что в конечном итоге выливается в деньги для клиента и может выйти не мало.

    Это если проект крупный. Если проект мелкий, то можно и забить
  • Мой опыт разработки приложения, как PM
    0
    У нас тема про процессы разработки, а не про продажи.
    Для того чтобы объяснить клиенту разницу в стоимости надо развивать навыки продаж.

    Опять же, если клиенту нужен MVP, собранный на коленке — отсутствие документации не такой ужасный фактор. Но если идёт речь о массовом продукте с тысячами пользователей планируемом на долгосрок, то отсутствие документации это боль. Обосновать тут можно хотя бы количеством запросов новых пользователей, у которых будут возникать вопросы по продукту — всё это вопросы в тех поддержку либо недополученная прибыль из-за того, что пользователь просто забил не разобравшись. Потом если система корпоративная и это крупная компания — то ИТ не примет продукт без документации и ваш клиент не сможет продать вами разработанный продукт, если вы делаете ПО на заказ.
  • Agile учит нас истинному смыслу Архитектуры
    0
    Философия
  • Мой опыт разработки приложения, как PM
    0
    Странная у вас аналогия.
    Есть пользовательская документация, есть техническая документация. Их много видов. Я выше привёл ситуации в которых мне интересно как бы поступил ПМ при отсутствии той или другой.

    Описать API в коде может быть сложнее чем в отдельном word документе. Допустим используется SOAP API с автогенерацией кода…
  • Code review Терминатор. Ревью, за которое вам скажут спасибо
    0
    Хороший ревью сейчас убережёт от технического долга в дальнейшем — это вы классно подметили
  • Архитектурные методы: что это и зачем они нужны
    0
    Одна философия…
  • Мой опыт разработки приложения, как PM
    +1
    В документации описывается факт, а стратегия и тактика имеет отношение к плану.
    Без документации по хорошему можно обойтись на этапе MVP так как бизнес-требования формируются. Но когда продукт масштабируется, обрастает функционалом и у него появляется большое количество пользователей, то банально без пользовательской документации будет больно.
    Заказчик может и будет рад увидеть красивый интерфейс, и подтвердит выполнение. Но массово продавать и внедрять этот продукт без банальной пользовательской документации будет больно. А у многих сегодняшних систем нет банальной пользовательской документации. Как правило такие продукты не отличаются качеством…
  • Как думают программисты-сеньоры?
    0
    Мы становимся тем, о чём думаем — это одна из ступеней Йоги.
    Того кто поставил на этой фразе свой копирайт ещё в проекте не было, когда техника уже была.
  • Мой опыт разработки приложения, как PM
    +1
    Вы пишете, что не нужно писать документацию, достаточно комментариев в коде.

    А представьте, что у вас проект, которому 10 лет, в котором куча интеграций и реализованных процессов, и люди, которые начинали разрабатывать этот проект — уже не работают в нём. И вот вы приходите на такой проект как PM, и команда у вас новая.

    Что будете делать, когда разрабы начнут задавать вопросы по интеграции со смежными системами? В комментариях вы sequence диаграмму не построите, а для самостоятельного разбора разработчиком — может понадобится дополнительное время, которого можно было бы не тратить, в случае если существовала документация.

    Документацию писать не надо, а в коде такое не опишешь, таким образом, на деле информации нигде не останется и каждому разрабу придётся тартить время на анализ. На сколько это рационально?

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

    К этим ситуациям еще интересно как вы будете себя вести в случае других вопросов по бизнес-процессам, реализованным в системе. Люди меняются, документации не остаётся, в комментах БП не описать. Что делать?