а для подвоза результата к сроку, на который босс забился с заказчиком
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
В какой-то момент стало понятно, что нам не хватает одного окна, в котором собраны все ключевые процессы
Окей вы делаете комбайн. И скорее всего у вас получится утка, которая умеет и плавать и ходить и летать. Но всё хреново. Может всё-таки оставить почту почтописателям?
Я не говорю уже про интерфейс. Я себе слабо такое представляю. Хотя видел комбайны, когда на экране всё, что может понадобится, но под каждое окно три пикселя. И потом как с этим работать? Я наоборот ухожу от этой модной тенденции, выделяя в приложении отдельные окна для фокусировки на текущей задаче.
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Интересно, что никто, похоже, не задумывается, почему всех этих проблем нет на бэке
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Нет у честного знака работы в оффлайне. У них есть апи с доступом по сертификатам крипто-про. Выданным по учередительным документам. А на кассах стоит ПО, которое может это обрабатывать. Смысл в том, что если не отправить проданные коды в честный знак, то могут предложить сесть на стеклянный сосуд с узким горлышком.
Возможно даже у спортмастера свой обрабатыватель чеков, который аггрегирует инфу и передаёт в ЧЗ. Но там нюансов столько, что не возьмёшь флешку и не пойдёшь передавать. И за пять минут не переделаешь.
Я просто писал похожую штуку для своей компании (в последней статье часть "Третья задача") вот оттуда и знаю
Так это каждый решает сам за себя, учитывая конкретику своих обстоятельств. Хорошо, когда есть выбор: забить на обучение и сделать из палок и промптов, или заморочиться и сделать, переделать, а потом понять как надо было и сделать нормально
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.
То есть между реляционными рядами RDBMS и объектами языка с ООП?
А Object-Relational Mapper назвать можно?
Так это же ORM. Да, не полный, да самописный, но это уже ORM.
А ещё если босс пообещал конкретный срок заказчику - это проблемы самого босса. Даже если вы сами сказали ему эту дату.
Потому что разработка - это не упаковка конфет на конвейере со строго регламентированной скоростью. Тут каждая задача - уникальна. И в каждой попадаются свои подводные камни. И чем больше задача - тем больше в ней встречаются камушки.
Если босс не знает про специфику разработки - это его проблемы. Если он пытается перевесить свои договорённости на вас - это его проблемы. Вы продаёте своё время за его деньги, о чём и был трудовой договор.
Риски не успеть - это риски босса. Это он владеет бизнесом, он управляет обещаниями клиентам, он управляет методами решения этих проблем. Он ДОЛЖЕН разбираться в специфике работы своих сотрудников. Он ДОЛЖЕН брать риски на себя и понимать, чем он рискует.
Окей вы делаете комбайн. И скорее всего у вас получится утка, которая умеет и плавать и ходить и летать. Но всё хреново. Может всё-таки оставить почту почтописателям?
Я не говорю уже про интерфейс. Я себе слабо такое представляю. Хотя видел комбайны, когда на экране всё, что может понадобится, но под каждое окно три пикселя. И потом как с этим работать? Я наоборот ухожу от этой модной тенденции, выделяя в приложении отдельные окна для фокусировки на текущей задаче.
Если не выбрасывать контекст, то не выглядит. Я не против инструментов управления сложностью. Сам топлю за типизацию и всякие ORM. Но в этом примере показывал, что источник бардака - гуй. И гуй ты чего сделаешь со сложность, пока у тебя всратый UX.
Я вертел на болту ОРП, вертел реакт, жаваскрипт и весь веб в целом. Десктопщик я. А для своего сайта сделал ssr и мне за глаза хватает.
Застал-застал. Я и фидонет застал, и на сях ббс писал. Я всё пытаюсь простую мысль донести: из огромной кучи параметров достаточно просто сделать одну страницу, просто потому что это поддаётся декомпозиции. А вот когда этот клубок змей шевелится и каждая змея каждую кусать начинает - вот тогда приходит пятилапый зверь
Ну не бывает волшебных библиотек, которые решают всё. И технологий таких нет. И подходов, хотя они называются "серебрянными пулями". Ну допустим один подход работает лучше другого. В UI ад и израиль, но вот сейчас вытягивает. А потом приходят эффективные совы и в клювике приносят новые правки гуя. И волшебная библиотека говорит "кря". Потому что надо UI перепроектировать, а не кровати двигать, вот что.
Вот и ответ. Бэк рендерит ровно один стейт, а не следит за связностью какая кнопка тебе таблицу загрузит, а какая в подвал нагадит
На бэке нет гуя. Если копнуть тот же шарп у него есть mvvm, который вырождается в реактивную ахинею со временем и очень сложно отследить, что как и куда меняет во вьюмодели и в какое место вью это полетит. Есть винформс, где сложность вырождается в кучу методов, которые по событию пытаются привести гуй в актуальное состояние.
В запущенных случаях и то и то ужасно. А чтобы держать в порядке, надо переосмысливать сам дизайн гуя, подходы к подаче инфы да и вообще весь UX.
Так что моё подозрение в том, что сложность возникает после работы с интерфейсом нескольких команд с разными целями в течении долгого времени.
Нет у честного знака работы в оффлайне. У них есть апи с доступом по сертификатам крипто-про. Выданным по учередительным документам. А на кассах стоит ПО, которое может это обрабатывать. Смысл в том, что если не отправить проданные коды в честный знак, то могут предложить сесть на стеклянный сосуд с узким горлышком.
Возможно даже у спортмастера свой обрабатыватель чеков, который аггрегирует инфу и передаёт в ЧЗ. Но там нюансов столько, что не возьмёшь флешку и не пойдёшь передавать. И за пять минут не переделаешь.
Я просто писал похожую штуку для своей компании (в последней статье часть "Третья задача") вот оттуда и знаю
Спасибо за статью! Это действительно хороший и интересный материал. Напомнило серию "техногенка, котаны?". А, ну да...
Так это каждый решает сам за себя, учитывая конкретику своих обстоятельств. Хорошо, когда есть выбор: забить на обучение и сделать из палок и промптов, или заморочиться и сделать, переделать, а потом понять как надо было и сделать нормально
Демократы хотят демократии, а не громить почему-то. Ну могут и погромить, если им обещали, но наврали, как в LA
Радиаторы на излучение начинают работать от тысячи по цельсию примерно. И у них эффективность зависит от четвёртой степени температуры. Нюанс - в кельвинах. Вот когда начал металл потихоньку светиться, как советский светодиод - вот тогда хоть чуть излучения пошло наружу.
Так что покрасить в чёрный цвет поможет как ленину педикюр. А при эффективных температурах почему-то не хочет надёжно работать электроника. Кожанные мешки вообще бастуют после такого и на работу не выходят.
Естественно, оно ещё и во все стороны светит, включая обшивку корабля и уже от этого защищаться надо. Естественно, должно быть сделано из дико тугоплавкого сплава вольфрама с адамантием. И надо ещё теплоноситель найти такой, чтобы тысяча по цельсию для него было холодно и жидко. Потому что ниже такие радиаторы не охладят. И трубы под такой фреон, чтобы в горячем состоянии его везти охлаждать.
Здесь как раз проблем нет. Синтез, в отличие от распада, не самоподдерживающаяся реакция. Она требует запредельных условий, и в бомбуэ такие условия создают ядерные заряды первой ступени.
Проблем с термоядом две:
Тратить энергии на поддержание реакции меньше, чем результативно снимать с неё же.
Специфическая для космоса проблема, где нет водоёма под рукой. Ну нагрели мы вещество, дальше что? Надо же перепад температур, а у нас разогревается ВЕСЬ корабль и его даже обдуть нечем
А никто не пробовал твиты Трампа прогнать через него? Вдруг Дональд - программист?
Мне вот сатисфактори больше разработку напоминает. Особенно на поздних стадиях ты видишь, что твой проект разросся и состоит из костылей и палок. И случайный затык где-нибудь ставит раком всю систему. И масштабироваться сложно, безумно сложно, потому что в начале ты этого не предусмотрел.
И как в жизни, там есть миллион способов решить одну задачу. Можно кинуть соплю конвеера, а потом об неё спотыкаться, можно провести линию поезда, можно поставить порт для дронов или пустить бегать трактор. Каждый способ специфический и имеет свои ограничения. Почти каждый ресурс имеет несколько способов производства, требуемые ресурсы надо понять откуда лучше везти.
Вообще карты соответствия делают даже англоговорящие разрабы. Просто, чтобы в коде и в обсуждениях с бизнесом термины совпадали.
Но не хотите - не делайте. Кто я такой, чтобы вам указывать, что делать?
Это ваши проблемы будут дальше, когда (или если) вы попадёте в другую компанию, а там будет всё незнакомо. Думаете почему люди стремятся стандартизировать что-то? Вот именно поэтому. Чтобы на одном языке шёл разговор.
Как я уже сказал - международный язык для разработки - английский. Если вы пишете переменные по-русски, то я не имею права вас осуждать. Но осуждаю.