#1517037Anonymous=95017574и что за покемон у нее в руке ?#1516923itsnotrobotsАвтор=95065926Про звёздочки всё правильно. Если вы чувствуете от девушки пассивную агрессию, вам не кажется)#1516898Dremlin=95070719А почему у демонетки смайликов нет? Я чувствую пассивную агрессию!#1516886Anonymous=95076973...а в звездочках - это репутация в конторе?
и за пропущенный ланч она падает?
типа, тимбилдинг на минималках, в китайском стиле?
нефиг выделяться?#1516884Anonymous=95077067вот и не будь тут NPC...
специальная магия для тех, кто хотел как проще? #1516845itsnotrobotsАвтор=95089184Дело в том, что я тот специальный программист, который не любит писать код, но любит его читать. Я обожаю рефакторить, у меня масса личных техник для работы с легаси и я превосходно умею это. Утверждение "давайте всё перепишем лучше" для меня является сарказмом, потому что так я описываю людей, которые читать не хотят, задачи не знают, зато имеют огромное самомнение. Но поскольку большинство программистов не умеет читать код, а умеет только писать, никто меня не понимает, и меня заставляют работать как все. В последнее время это настолько выносит мне мозги, что я стараюсь уже не думать о программировании, а думать больше про свой комикс.
Это потому что иногда всего написать с нуля "нормально" просто нельзя. Нельзя "нафантазировать" нормальный результат, нужно писать и смотреть что получится. А потом переписать несколько раз, когда требования и архитектура стабилизировалась по опыту эксплуатации поделия.
И вот когда большой массив кода (и коллектив разрабов) уже есть, он работает как справочник / инструмент понимания - в результате возникает иллюзия что "они идиоты а я такой умный и все переписал". На самом деле ты хорошо переписал потому что твоя нейронка в голове научилась на основе этого кода проекта и теперь может выдавать хорошие решения (для этого проекта). Эту иллюзию усиливает то что программисты очень не любят читать код, но любят его писать - что разумно потому что платят им за написанное, прочитанное контролировать сложно. Так то часто действительно проще что-то переписать с нуля, но до определенного предела. Ну и на истории "я все переписал", находятся истории "переписал всё не учитывая кое-чего" и "сказал что переписать проще, но проебался с учетом времени".
#1516819Anonymous=95124887"Чистое небо", выход с болот... Пулемётчику конфиги править! У него пули от снайперки.#1516708Anonymous=95177951восхищен.
сперва взгляд обнял картину в целом без проблем, но потом глаз зацепился за круло от самолета, и далее везде... кричал и плакал :)#1516695itsnotrobotsАвтор=95204888Ещё такая байка. Как-то раз я работал в проекте на 60 человек. Один из разработчиков был наиболее укоренившийся в этой конторе, ему явно было скучно, и он лез без мыла во все обсуждения со своим мнением. Причем сам сидел на модуле, в который никого не пускал, и который был ключевым для системы. В какой-то момент я распарсил весь этот модуль, нашел там несколько критических багов, и сделал про это дизайн документ. Ничего не исправилось. В другой момент мой коллега переписал весь этот модуль, и у него получилось 500 строк на Яве. Опять ничего не исправилось. В результате этот автор модуля получил повышение до принципала.#1516677SVlad=95210228Был у меня такой случай:
Контекстное меню в пользовательском редакторе диаграмм, в котором десяток пунктов, видимость и активность которых зависит от типа и состояния выбранного объекта и режима работы всего приложения.
Пункты меню запихивались в массив, после чего над ним происходили какие-то странные действия на на протяжении 600 строк, смысл которых мне понять так и не удалось.
Первый раз, когда мне понадобилось добавить туда пункт меню, я воткнул его рядом с пунктом с такими же правилами отображения и поправил размер массива.
Когда понадобилось добавить ещё пункт меню с уже более сложными правилам, я понял, что в этом магии с массивом мне не разобраться.
К счастью, у нас была инструкция к программе, где было описано, как пункты меню должны (!) работать. В общем, я выкинул весь этот класс, и написал заново. Всего 20 строк: 7 строк получения булевых переменных состояний, и 13 строк добавления 13 пунктов меня с условиями из булевых формул из тех 7 переменных.
Кто, как и, главное, зачем, написал изначальный алгоритм на 600 строк магических преобразований массива, для меня так и осталось тайной.
Отредактировано «SVlad» 25.02.2023 23:36:49
#1516543HJK=95305058Это так образно описан else или switch case? Странно что эти спагетти не разрисовали при первой разборке на блоки на бумажке со всеми возможными состояниями.
Отредактировано «HJK» 24.02.2023 23:29:33
#1516525T-Fishka=95321605Гармонично %)#1516466hruser=95372603#1516456 говно в сортире (через который осуществляется вход в систему).
но вообще типичный legacy code в духе https://i.stack.imgur.com/4JkeC.jpg
Отредактировано «hruser» 24.02.2023 17:58:15
#1516456Dremlin=95380631Палки вижу, где говно? :)
И изоленту вижу.#1515990ToX=95672442OKR - план на период, KPI - твой вклад в сделанное командой. Не взаимосвязаны.#1515935itsnotrobotsАвтор=95725606Я честно даже хз, это так или иначе некий очередной баззворд для "запланированный результат"#1515930SVlad=95726464KPI что ли?#1515865itsnotrobotsАвтор=95761228OKR, objective key results, это некий результат, к которому стремится команда разработчиков в заданный период времени. Я даже как-то не подумал сделать сноску, потому что Михалыч тоже не понимает, что это такое)
и за пропущенный ланч она падает?
типа, тимбилдинг на минималках, в китайском стиле?
нефиг выделяться?
специальная магия для тех, кто хотел как проще?
Это потому что иногда всего написать с нуля "нормально" просто нельзя. Нельзя "нафантазировать" нормальный результат, нужно писать и смотреть что получится. А потом переписать несколько раз, когда требования и архитектура стабилизировалась по опыту эксплуатации поделия.
И вот когда большой массив кода (и коллектив разрабов) уже есть, он работает как справочник / инструмент понимания - в результате возникает иллюзия что "они идиоты а я такой умный и все переписал". На самом деле ты хорошо переписал потому что твоя нейронка в голове научилась на основе этого кода проекта и теперь может выдавать хорошие решения (для этого проекта). Эту иллюзию усиливает то что программисты очень не любят читать код, но любят его писать - что разумно потому что платят им за написанное, прочитанное контролировать сложно. Так то часто действительно проще что-то переписать с нуля, но до определенного предела. Ну и на истории "я все переписал", находятся истории "переписал всё не учитывая кое-чего" и "сказал что переписать проще, но проебался с учетом времени".
сперва взгляд обнял картину в целом без проблем, но потом глаз зацепился за круло от самолета, и далее везде... кричал и плакал :)
Контекстное меню в пользовательском редакторе диаграмм, в котором десяток пунктов, видимость и активность которых зависит от типа и состояния выбранного объекта и режима работы всего приложения.
Пункты меню запихивались в массив, после чего над ним происходили какие-то странные действия на на протяжении 600 строк, смысл которых мне понять так и не удалось.
Первый раз, когда мне понадобилось добавить туда пункт меню, я воткнул его рядом с пунктом с такими же правилами отображения и поправил размер массива.
Когда понадобилось добавить ещё пункт меню с уже более сложными правилам, я понял, что в этом магии с массивом мне не разобраться.
К счастью, у нас была инструкция к программе, где было описано, как пункты меню должны (!) работать. В общем, я выкинул весь этот класс, и написал заново. Всего 20 строк: 7 строк получения булевых переменных состояний, и 13 строк добавления 13 пунктов меня с условиями из булевых формул из тех 7 переменных.
Кто, как и, главное, зачем, написал изначальный алгоритм на 600 строк магических преобразований массива, для меня так и осталось тайной.
но вообще типичный legacy code в духе https://i.stack.imgur.com/4JkeC.jpg
И изоленту вижу.