Угу. Сидишь пишешь весь день код, думаешь, стараешься, а на следующий день запускаешь и начинаешь изучать, что же он делает.
18.06.2020, 17:39
Отсутствие комментов - это проблема будущего меня, или того, кто меня заменит. Мне их не жалко.
Если адаптировать это к коду как пример что-то типа токарного станка то, да это кнопка самоуничтожения а кнопка включения находится с обратной стороны под крышкой, без каких либо опознавательных знаков, но если если ты запнулся о порог при входе в комнату с прибором, то кнопка самоуничтожения и кнопка включения меняются местами.
А теперь как это работает.
Изначально прибор делал что-то другое, но выяснилось что если его немного переделать то он будет делать то что надо. Но в комплекте к нему идёт кнопка самоуничтожения и кнопка включения. И что расположены они должны быть определённым образом чтоб прибор работал, так как при попытке их переместить прибор отказывается работать. И получается так что кнопка включения должна стоять в жопе мира, а кнопка самоуничтожения на самом видном месте. Тогда приняли такое решение, сделать неудобный порог чтоб об него каждый раз запинались, и этот костыль менял бы местами функционал кнопок. А для безопасности другую не используемую кнопку запрятали замуровали, чтоб о ней никто и не знал.
И продолжение специально для capNEMO
Вот такая ситуация со станком, а теперь масштабируем всё до завода, только там например угол цеха должен быть обоссан чтоб в него электричество шло, но тот человек который проектирует завод не разбирается в станках он просто берёт те которые есть, а есть вот эти с порогом и кнопками, он получает их смотрит на эту фигню и решает разместить допустим 5 таких станков в одном цеху, а зачем ему на входе 5 порогов? поэтому он оставляет один или вообще их убирает так как ему нужны только станки. А дальше цех взлетает на воздух, и путём проб и ошибок получается решение перед каждым станком поставить этот самый порожек и в инструкции будет сказано пнуть его перед запуском, так как это самое быстрое и простое решение и оно будет работать.
Почему так? Потому что он проектирует завод, и изобретать станки при проектировании завода сам понимаешь глупо, и этим должны заниматься разные люди с разными компетенциями.
А теперь переложим это на IT где подобных абстракций на несколько порядков больше, а абстракции в программировании это как раз самая мякотка. И да формулировка не совсем точная, программист всегда точно знает что делает его код, но далеко не всегда знает как он это делает, это как раз и есть абстракция.
Вот пример из реально жизни, как купить телефон? ну тут всё просто ты приходишь в магазин платишь деньги а они дают тебе телефон. Но тебе просто даже не интересно а как телефоны оказываются в магазине, почему? а потому что и без этих знаний ты можешь пользоваться магазином и он выполняет свои функции. Точно так же как магазину пофиг на производство телефонов, главное что их со складов доставляют, ну и так далее. В итоге ты как и программист знаешь что магазин продаёт телефоны и что надо сделать что бы он тебе его продал, но ты не представляешь какая работа проделана для этого.
А теперь как это работает.
Изначально прибор делал что-то другое, но выяснилось что если его немного переделать то он будет делать то что надо. Но в комплекте к нему идёт кнопка самоуничтожения и кнопка включения. И что расположены они должны быть определённым образом чтоб прибор работал, так как при попытке их переместить прибор отказывается работать. И получается так что кнопка включения должна стоять в жопе мира, а кнопка самоуничтожения на самом видном месте. Тогда приняли такое решение, сделать неудобный порог чтоб об него каждый раз запинались, и этот костыль менял бы местами функционал кнопок. А для безопасности другую не используемую кнопку запрятали замуровали, чтоб о ней никто и не знал.
И продолжение специально для capNEMO
Вот такая ситуация со станком, а теперь масштабируем всё до завода, только там например угол цеха должен быть обоссан чтоб в него электричество шло, но тот человек который проектирует завод не разбирается в станках он просто берёт те которые есть, а есть вот эти с порогом и кнопками, он получает их смотрит на эту фигню и решает разместить допустим 5 таких станков в одном цеху, а зачем ему на входе 5 порогов? поэтому он оставляет один или вообще их убирает так как ему нужны только станки. А дальше цех взлетает на воздух, и путём проб и ошибок получается решение перед каждым станком поставить этот самый порожек и в инструкции будет сказано пнуть его перед запуском, так как это самое быстрое и простое решение и оно будет работать.
Почему так? Потому что он проектирует завод, и изобретать станки при проектировании завода сам понимаешь глупо, и этим должны заниматься разные люди с разными компетенциями.
А теперь переложим это на IT где подобных абстракций на несколько порядков больше, а абстракции в программировании это как раз самая мякотка. И да формулировка не совсем точная, программист всегда точно знает что делает его код, но далеко не всегда знает как он это делает, это как раз и есть абстракция.
Вот пример из реально жизни, как купить телефон? ну тут всё просто ты приходишь в магазин платишь деньги а они дают тебе телефон. Но тебе просто даже не интересно а как телефоны оказываются в магазине, почему? а потому что и без этих знаний ты можешь пользоваться магазином и он выполняет свои функции. Точно так же как магазину пофиг на производство телефонов, главное что их со складов доставляют, ну и так далее. В итоге ты как и программист знаешь что магазин продаёт телефоны и что надо сделать что бы он тебе его продал, но ты не представляешь какая работа проделана для этого.
Говно вопрос. У меня уже пару проектов в загашнике, где надо проводить синхронизацию данных в 2х системах. Т.е. данные могут меняться с двух сторон. Все +/- ок до того момента, когда вылазит, что данные несовместимы и невозможно преобразовать один в один или там с другой стороны есть логика, которая отличается от нашей, и приходится строить иногда такой говнокод, что в дрожь бросает от мысли править там баги. Только покрытие тестами (которые по коду больше, чем логика) спасает от пиздеца хоть как-то.
у меня такое чувство, что я уже видел этот мем на реакторе
да вот он нашёл: http://joyreactor.cc/post/4230960
Смысл разный
В наше время ничего не обычного.
В сообществе полно RESTfull-программистов. Одно из основных требований к RESfull системе - отсутствие какого либо состояния на сервере, которое бы оставалось от выполнения запроса. RESTfull программисты пишут RESTfull системы и сами в какой-то момент превращаются в RESTfull системы. Ты направляешь им запрос сделать что-нибудь, как только обработка запроса закончена, никакого состояния в программисте не остается.
RESTfull программисты пишут write-only код. Будучи однажды написан и отлажен, он никогда больше не может быть изменен. Другие программисты могут лишь писать новый write-only код, чтобы добавить системе новых свойств или обойти дефекты в результатах выдаваемых старым кодом.
В сообществе полно RESTfull-программистов. Одно из основных требований к RESfull системе - отсутствие какого либо состояния на сервере, которое бы оставалось от выполнения запроса. RESTfull программисты пишут RESTfull системы и сами в какой-то момент превращаются в RESTfull системы. Ты направляешь им запрос сделать что-нибудь, как только обработка запроса закончена, никакого состояния в программисте не остается.
RESTfull программисты пишут write-only код. Будучи однажды написан и отлажен, он никогда больше не может быть изменен. Другие программисты могут лишь писать новый write-only код, чтобы добавить системе новых свойств или обойти дефекты в результатах выдаваемых старым кодом.
Чтобы написать коммент, необходимо залогиниться
