про языки IEC 61131 уже написали? А то задолбался комменты читать..
Если нет - там это все уже сделано - хочешь текстом код пиши, хочешь диаграмами рисуй. Причем там вообще 3 разных языка и каждый может быть представлен как текстом так и графически. И все это используется в АСУТП во весь рост, уже десятки лет, без компромиссов.
Дейлики, статусы, отчеты, бонусы, успехи, вовлечение... А команда сидит и думает - мало того что очередной круд делать, так еще и менеджер клоун какой то.
Поддерживаю. Так и должно быть - для бизнеса именно тимлид пишет код. А остальные ему как бы помогают. Значит ему и оценивать и отвечать за оценки и управлять остальными девами и где то им помогать и их направлять. Реально рабочая схема
Так и надо начинать писать - одной простыней в мейн. Без классов и типов. А потом по мере написания - еще дальше упрощать код путем поиска повторяющегося кода и выноса его в отдельные функции. А потом еще больше упрощать путем объединения похожих функций в классы. А потом еще больше упрощать себе жизнь добавлением типов. Так рождается идеальная архитектура, где нет ничего лишнего и все запредельно просто
Да, очевидно что у автора на старых мониках был шим, а на новом нет. Я как то тоже мучался, на работе глаза к вечеру режут как будто песка насыпали, а дома хоть целый день сиди и ничего. Потом как то случайно псомтрел на рабочий моник через камеру телефона и вдруг все понял. Поменял на безшимный и все сразу прошло. Теперь для меня это главный критерий а не все это 100500 герц имиллионы нит.
Если работаешь в команде, то чем велосипед парня из оклахомы хуже велосипеда джуна васи из соседней комнаты? Парень из оклахомы как минимум сделал это забесплатно (для нас)
Кто нибудь коротко обьяснит - в расте управление памятью сделано через подсчет ссылок и всякого рода смартпоинтеров, или там как то все совсем по другому? А если через подсчет ссылок то как решена проблема циклических ссылок друг на друга?
Я один не понимаю как можно ревьювить только чейнжи, без контекста всего файли или проекта? Ну хорошо когда сам чейнж большой и сам имеет какой то контекст. А если там пару строчек изменено, то что хорошего по этим строчкам может сказать модель без контекста в котором эти изменнния сделаны?
Поддерживаю. Это как в случае с микросервисами, которые не упрощают, а просто выносят сложность на уровень выше. Мелкие классы "делающие что то одно" - те же микросервисы, главная боль которых - их количество
Говнокод с сотнями интерфейсов и разделением на микроклассы с парой методов написаный по принципам солид ради следования принципам солид - обладает такой же ужасной читаемостью как и лапша из функций в 1000 строк. Просто потому что довольно трудно удержать такие контексты в голове во время чтения кода.
Проблема в том что на ревью автор первого говнокода достанет из рукава козыри в виде "лучшие практики", "чистый код", "солид" и т.п. и ты его ничем не прошибешь.
Это хорошо выглядет. Если мы сразу знаем что у нас будут разные файлы, и разные алгоритмы шифрования. Тогда можно сразу так и писать.
Но в реальной жизни произойдет одно из двух. Или изначальная задача будет просто "читать файл" и тогда городить этот огород сразу нет смысла, а потом (когда мы узнаем через год теперь надо еще и расшифровать) нет возможности. Или для той же задачи "прочитать файл" юный адепт чистых архитектур нагородит на всякий случай миллион интерфейсов для расшифровки, зашифровки, валидации, конвертации и парсинга, а задача так и останется "просто прочитать файл".
Мне кажется все нормальные архитектуры рождаются только при рефакторинге, в результате обобщения уже имеющегося кода и послезнания того как именно надо было делать. Вот тут можно и вспомнить про солид, кисс и это все. Но не раньше
Таки да. Вопрос только в том - а надо ли чтобы калькулятор укладывался в 2 кб? Заплатит ли кто то именно за маленький размер? Нужно ли привлечь к разработке сурового сеньера, чтобы он на с++ переписал функцию сложения и сделал ее быстрее на 2 порядка, вместо 0.1 сек - 0.001 сек? Кто готов заплатить за неделю работы сеньера вместо джуна?
какого еще назначения?
C#
private string GenerateGuessSentence(char candidate, int count)=> count == 0 ? $"There are no {candidate}"
: count == 1 ? $"There is 1 {candidate}"
: $"There are {count} {candidate}";
Что за несовместимые версии языка с#? Это какой то новый миф? Их и так вокруг с# хватает, не усугубляйте
про языки IEC 61131 уже написали? А то задолбался комменты читать..
Если нет - там это все уже сделано - хочешь текстом код пиши, хочешь диаграмами рисуй. Причем там вообще 3 разных языка и каждый может быть представлен как текстом так и графически. И все это используется в АСУТП во весь рост, уже десятки лет, без компромиссов.
Какой незамутненный корпоративный булшит.
Дейлики, статусы, отчеты, бонусы, успехи, вовлечение... А команда сидит и думает - мало того что очередной круд делать, так еще и менеджер клоун какой то.
Поддерживаю. Так и должно быть - для бизнеса именно тимлид пишет код. А остальные ему как бы помогают. Значит ему и оценивать и отвечать за оценки и управлять остальными девами и где то им помогать и их направлять. Реально рабочая схема
Так и надо начинать писать - одной простыней в мейн. Без классов и типов. А потом по мере написания - еще дальше упрощать код путем поиска повторяющегося кода и выноса его в отдельные функции. А потом еще больше упрощать путем объединения похожих функций в классы. А потом еще больше упрощать себе жизнь добавлением типов. Так рождается идеальная архитектура, где нет ничего лишнего и все запредельно просто
Да, очевидно что у автора на старых мониках был шим, а на новом нет. Я как то тоже мучался, на работе глаза к вечеру режут как будто песка насыпали, а дома хоть целый день сиди и ничего. Потом как то случайно псомтрел на рабочий моник через камеру телефона и вдруг все понял. Поменял на безшимный и все сразу прошло. Теперь для меня это главный критерий а не все это 100500 герц имиллионы нит.
Если работаешь в команде, то чем велосипед парня из оклахомы хуже велосипеда джуна васи из соседней комнаты? Парень из оклахомы как минимум сделал это забесплатно (для нас)
Хай сири, спроси у чатгпт как улучшить менеджмент в эппле
Интересно какие мучения вы испытывали в этих редакторах.
"Раньше было лучше", "Сейчас так не делают"...
Ну вы что серьезно?
Кто нибудь коротко обьяснит - в расте управление памятью сделано через подсчет ссылок и всякого рода смартпоинтеров, или там как то все совсем по другому? А если через подсчет ссылок то как решена проблема циклических ссылок друг на друга?
Я один не понимаю как можно ревьювить только чейнжи, без контекста всего файли или проекта? Ну хорошо когда сам чейнж большой и сам имеет какой то контекст. А если там пару строчек изменено, то что хорошего по этим строчкам может сказать модель без контекста в котором эти изменнния сделаны?
Поддерживаю. Это как в случае с микросервисами, которые не упрощают, а просто выносят сложность на уровень выше. Мелкие классы "делающие что то одно" - те же микросервисы, главная боль которых - их количество
Говнокод с сотнями интерфейсов и разделением на микроклассы с парой методов написаный по принципам солид ради следования принципам солид - обладает такой же ужасной читаемостью как и лапша из функций в 1000 строк. Просто потому что довольно трудно удержать такие контексты в голове во время чтения кода.
Проблема в том что на ревью автор первого говнокода достанет из рукава козыри в виде "лучшие практики", "чистый код", "солид" и т.п. и ты его ничем не прошибешь.
Это хорошо выглядет. Если мы сразу знаем что у нас будут разные файлы, и разные алгоритмы шифрования. Тогда можно сразу так и писать.
Но в реальной жизни произойдет одно из двух. Или изначальная задача будет просто "читать файл" и тогда городить этот огород сразу нет смысла, а потом (когда мы узнаем через год теперь надо еще и расшифровать) нет возможности. Или для той же задачи "прочитать файл" юный адепт чистых архитектур нагородит на всякий случай миллион интерфейсов для расшифровки, зашифровки, валидации, конвертации и парсинга, а задача так и останется "просто прочитать файл".
Мне кажется все нормальные архитектуры рождаются только при рефакторинге, в результате обобщения уже имеющегося кода и послезнания того как именно надо было делать. Вот тут можно и вспомнить про солид, кисс и это все. Но не раньше
Тимлиду отвечать потом код эа этих двоих, поэтому его выбор имеет значение, хотя и не гарантирует что выбор правильный
Таки да. Вопрос только в том - а надо ли чтобы калькулятор укладывался в 2 кб? Заплатит ли кто то именно за маленький размер? Нужно ли привлечь к разработке сурового сеньера, чтобы он на с++ переписал функцию сложения и сделал ее быстрее на 2 порядка, вместо 0.1 сек - 0.001 сек? Кто готов заплатить за неделю работы сеньера вместо джуна?
"чтобы язык защищал от коллег" - это гениальная формулировка.