Search
Write a publication
Pull to refresh
4
0
Send message

про языки IEC 61131 уже написали? А то задолбался комменты читать..

Если нет - там это все уже сделано - хочешь текстом код пиши, хочешь диаграмами рисуй. Причем там вообще 3 разных языка и каждый может быть представлен как текстом так и графически. И все это используется в АСУТП во весь рост, уже десятки лет, без компромиссов.

Какой незамутненный корпоративный булшит.

Дейлики, статусы, отчеты, бонусы, успехи, вовлечение... А команда сидит и думает - мало того что очередной круд делать, так еще и менеджер клоун какой то.

Поддерживаю. Так и должно быть - для бизнеса именно тимлид пишет код. А остальные ему как бы помогают. Значит ему и оценивать и отвечать за оценки и управлять остальными девами и где то им помогать и их направлять. Реально рабочая схема

Так и надо начинать писать - одной простыней в мейн. Без классов и типов. А потом по мере написания - еще дальше упрощать код путем поиска повторяющегося кода и выноса его в отдельные функции. А потом еще больше упрощать путем объединения похожих функций в классы. А потом еще больше упрощать себе жизнь добавлением типов. Так рождается идеальная архитектура, где нет ничего лишнего и все запредельно просто

Да, очевидно что у автора на старых мониках был шим, а на новом нет. Я как то тоже мучался, на работе глаза к вечеру режут как будто песка насыпали, а дома хоть целый день сиди и ничего. Потом как то случайно псомтрел на рабочий моник через камеру телефона и вдруг все понял. Поменял на безшимный и все сразу прошло. Теперь для меня это главный критерий а не все это 100500 герц имиллионы нит.

Если работаешь в команде, то чем велосипед парня из оклахомы хуже велосипеда джуна васи из соседней комнаты? Парень из оклахомы как минимум сделал это забесплатно (для нас)

Хай сири, спроси у чатгпт как улучшить менеджмент в эппле

Интересно какие мучения вы испытывали в этих редакторах.

"Раньше было лучше", "Сейчас так не делают"...

Ну вы что серьезно?

Кто нибудь коротко обьяснит - в расте управление памятью сделано через подсчет ссылок и всякого рода смартпоинтеров, или там как то все совсем по другому? А если через подсчет ссылок то как решена проблема циклических ссылок друг на друга?

Я один не понимаю как можно ревьювить только чейнжи, без контекста всего файли или проекта? Ну хорошо когда сам чейнж большой и сам имеет какой то контекст. А если там пару строчек изменено, то что хорошего по этим строчкам может сказать модель без контекста в котором эти изменнния сделаны?

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

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

Проблема в том что на ревью автор первого говнокода достанет из рукава козыри в виде "лучшие практики", "чистый код", "солид" и т.п. и ты его ничем не прошибешь.

Это хорошо выглядет. Если мы сразу знаем что у нас будут разные файлы, и разные алгоритмы шифрования. Тогда можно сразу так и писать.

Но в реальной жизни произойдет одно из двух. Или изначальная задача будет просто "читать файл" и тогда городить этот огород сразу нет смысла, а потом (когда мы узнаем через год теперь надо еще и расшифровать) нет возможности. Или для той же задачи "прочитать файл" юный адепт чистых архитектур нагородит на всякий случай миллион интерфейсов для расшифровки, зашифровки, валидации, конвертации и парсинга, а задача так и останется "просто прочитать файл".

Мне кажется все нормальные архитектуры рождаются только при рефакторинге, в результате обобщения уже имеющегося кода и послезнания того как именно надо было делать. Вот тут можно и вспомнить про солид, кисс и это все. Но не раньше

Тимлиду отвечать потом код эа этих двоих, поэтому его выбор имеет значение, хотя и не гарантирует что выбор правильный

Таки да. Вопрос только в том - а надо ли чтобы калькулятор укладывался в 2 кб? Заплатит ли кто то именно за маленький размер? Нужно ли привлечь к разработке сурового сеньера, чтобы он на с++ переписал функцию сложения и сделал ее быстрее на 2 порядка, вместо 0.1 сек - 0.001 сек? Кто готов заплатить за неделю работы сеньера вместо джуна?

"чтобы язык защищал от коллег" - это гениальная формулировка.

У меня проект который я начинал с нуля и командую им уже 20 лет. Люди приходили-уходили, а я был на нем всегда и в силу этого там очень много именно моего кода. И этот код - полная деградация. Хотя сам по себе я в каждый момент времени - молодец. Вот только навыки, опыт и знания растут, подходы меняются, а уже написанный код остается. И начинает выглядеть как коричневая субстанция. И я более чем уверен что мой сегодняшний код через 5 лет будет выглядеть так же. И никак не спихнешь это на нерадивых джунов или торопящихся менеджеров, хотя и такого много.

Просто есть одно правило - если вам нравится код, написанный вами несколько лет назад - значит все эти годы вы не развивались.

Это что за модель и в коде какого размера она так знатно ориентируется?

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

1
23 ...

Information

Rating
8,461-st
Registered
Activity