#1517758cheburen=54753059когда крыша немного того - это плохо, когда поправил крышу и понял почему и от чего - это прикольно, когда с новыми знаниями присмотрелся к окружающему миру - понял что ещё легко отделался и пушистый северный зверёк он вообще везде.#1517730SVlad=54763188Неправильный выбор абстракции ведёт к ошибкам. Чем ему Стартрек то не понравился?#1517728SVlad=54763257Автор, береги себя! Здесь и так слишком много комиксов, авторы которые умерли, так и не закончив свой труд. И про "умерли" я не шучу. #1517692Gektansir=54816116такой большой текст, а причину не рассказали, вот теперь придется думать об этом.#1517688dsche=54817634Есть два стола: за одним ложки верчёные, за другим палки точёные…#1517037Anonymous=55132880и что за покемон у нее в руке ?#1516923itsnotrobotsАвтор=55181232Про звёздочки всё правильно. Если вы чувствуете от девушки пассивную агрессию, вам не кажется)#1516898Dremlin=55186025А почему у демонетки смайликов нет? Я чувствую пассивную агрессию!#1516886Anonymous=55192279...а в звездочках - это репутация в конторе?
и за пропущенный ланч она падает?
типа, тимбилдинг на минималках, в китайском стиле?
нефиг выделяться?#1516884Anonymous=55192373вот и не будь тут NPC...
специальная магия для тех, кто хотел как проще? #1516845itsnotrobotsАвтор=55204490Дело в том, что я тот специальный программист, который не любит писать код, но любит его читать. Я обожаю рефакторить, у меня масса личных техник для работы с легаси и я превосходно умею это. Утверждение "давайте всё перепишем лучше" для меня является сарказмом, потому что так я описываю людей, которые читать не хотят, задачи не знают, зато имеют огромное самомнение. Но поскольку большинство программистов не умеет читать код, а умеет только писать, никто меня не понимает, и меня заставляют работать как все. В последнее время это настолько выносит мне мозги, что я стараюсь уже не думать о программировании, а думать больше про свой комикс.
Это потому что иногда всего написать с нуля "нормально" просто нельзя. Нельзя "нафантазировать" нормальный результат, нужно писать и смотреть что получится. А потом переписать несколько раз, когда требования и архитектура стабилизировалась по опыту эксплуатации поделия.
И вот когда большой массив кода (и коллектив разрабов) уже есть, он работает как справочник / инструмент понимания - в результате возникает иллюзия что "они идиоты а я такой умный и все переписал". На самом деле ты хорошо переписал потому что твоя нейронка в голове научилась на основе этого кода проекта и теперь может выдавать хорошие решения (для этого проекта). Эту иллюзию усиливает то что программисты очень не любят читать код, но любят его писать - что разумно потому что платят им за написанное, прочитанное контролировать сложно. Так то часто действительно проще что-то переписать с нуля, но до определенного предела. Ну и на истории "я все переписал", находятся истории "переписал всё не учитывая кое-чего" и "сказал что переписать проще, но проебался с учетом времени".
#1516819Anonymous=55240193"Чистое небо", выход с болот... Пулемётчику конфиги править! У него пули от снайперки.#1516708Anonymous=55293257восхищен.
сперва взгляд обнял картину в целом без проблем, но потом глаз зацепился за круло от самолета, и далее везде... кричал и плакал :)#1516695itsnotrobotsАвтор=55320194Ещё такая байка. Как-то раз я работал в проекте на 60 человек. Один из разработчиков был наиболее укоренившийся в этой конторе, ему явно было скучно, и он лез без мыла во все обсуждения со своим мнением. Причем сам сидел на модуле, в который никого не пускал, и который был ключевым для системы. В какой-то момент я распарсил весь этот модуль, нашел там несколько критических багов, и сделал про это дизайн документ. Ничего не исправилось. В другой момент мой коллега переписал весь этот модуль, и у него получилось 500 строк на Яве. Опять ничего не исправилось. В результате этот автор модуля получил повышение до принципала.#1516677SVlad=55325534Был у меня такой случай:
Контекстное меню в пользовательском редакторе диаграмм, в котором десяток пунктов, видимость и активность которых зависит от типа и состояния выбранного объекта и режима работы всего приложения.
Пункты меню запихивались в массив, после чего над ним происходили какие-то странные действия на на протяжении 600 строк, смысл которых мне понять так и не удалось.
Первый раз, когда мне понадобилось добавить туда пункт меню, я воткнул его рядом с пунктом с такими же правилами отображения и поправил размер массива.
Когда понадобилось добавить ещё пункт меню с уже более сложными правилам, я понял, что в этом магии с массивом мне не разобраться.
К счастью, у нас была инструкция к программе, где было описано, как пункты меню должны (!) работать. В общем, я выкинул весь этот класс, и написал заново. Всего 20 строк: 7 строк получения булевых переменных состояний, и 13 строк добавления 13 пунктов меня с условиями из булевых формул из тех 7 переменных.
Кто, как и, главное, зачем, написал изначальный алгоритм на 600 строк магических преобразований массива, для меня так и осталось тайной.
Отредактировано «SVlad» 25.02.2023 23:36:49
#1516543HJK=55420364Это так образно описан else или switch case? Странно что эти спагетти не разрисовали при первой разборке на блоки на бумажке со всеми возможными состояниями.
Отредактировано «HJK» 24.02.2023 23:29:33
#1516525T-Fishka=55436911Гармонично %)#1516466hruser=55487909#1516456 говно в сортире (через который осуществляется вход в систему).
но вообще типичный legacy code в духе https://i.stack.imgur.com/4JkeC.jpg
Отредактировано «hruser» 24.02.2023 17:58:15
#1516456Dremlin=55495937Палки вижу, где говно? :)
И изоленту вижу.
и за пропущенный ланч она падает?
типа, тимбилдинг на минималках, в китайском стиле?
нефиг выделяться?
специальная магия для тех, кто хотел как проще?
Это потому что иногда всего написать с нуля "нормально" просто нельзя. Нельзя "нафантазировать" нормальный результат, нужно писать и смотреть что получится. А потом переписать несколько раз, когда требования и архитектура стабилизировалась по опыту эксплуатации поделия.
И вот когда большой массив кода (и коллектив разрабов) уже есть, он работает как справочник / инструмент понимания - в результате возникает иллюзия что "они идиоты а я такой умный и все переписал". На самом деле ты хорошо переписал потому что твоя нейронка в голове научилась на основе этого кода проекта и теперь может выдавать хорошие решения (для этого проекта). Эту иллюзию усиливает то что программисты очень не любят читать код, но любят его писать - что разумно потому что платят им за написанное, прочитанное контролировать сложно. Так то часто действительно проще что-то переписать с нуля, но до определенного предела. Ну и на истории "я все переписал", находятся истории "переписал всё не учитывая кое-чего" и "сказал что переписать проще, но проебался с учетом времени".
сперва взгляд обнял картину в целом без проблем, но потом глаз зацепился за круло от самолета, и далее везде... кричал и плакал :)
Контекстное меню в пользовательском редакторе диаграмм, в котором десяток пунктов, видимость и активность которых зависит от типа и состояния выбранного объекта и режима работы всего приложения.
Пункты меню запихивались в массив, после чего над ним происходили какие-то странные действия на на протяжении 600 строк, смысл которых мне понять так и не удалось.
Первый раз, когда мне понадобилось добавить туда пункт меню, я воткнул его рядом с пунктом с такими же правилами отображения и поправил размер массива.
Когда понадобилось добавить ещё пункт меню с уже более сложными правилам, я понял, что в этом магии с массивом мне не разобраться.
К счастью, у нас была инструкция к программе, где было описано, как пункты меню должны (!) работать. В общем, я выкинул весь этот класс, и написал заново. Всего 20 строк: 7 строк получения булевых переменных состояний, и 13 строк добавления 13 пунктов меня с условиями из булевых формул из тех 7 переменных.
Кто, как и, главное, зачем, написал изначальный алгоритм на 600 строк магических преобразований массива, для меня так и осталось тайной.
но вообще типичный legacy code в духе https://i.stack.imgur.com/4JkeC.jpg
И изоленту вижу.