Ну хорошо. А теперь в версию с массивом коэффициентов (дальше я код не анализировал) добавьте код для вычисления площади параллелограмма. Какие там данные для хранения параллелограмма? Уж точно не только ширина и высота. Сколько придется переписывать программу? Всю?
Чистый код - это про то, как поддерживать скорость разработки и далее, после того, как написал программу вычисления площадей круга и квадрата.
Орел, конечно, выявил паттерн для квадрата, круга и треугольника. А если добавить фигуру, не вписывающийся в ВАШ паттерн? Параллелограмм, у которого, как я сказал, три параметра - ширина, высота (я про стороны) и угол наклона? А если добавить еще одну операцию в интерфейс - расчет периметра? Сколько придется переписывать? Всю программу?
Ну хорошо. Объясните тогда. Два тела сближаются друг с другом в космосе. На каждом из этих тел сидит по блондинке. Кто из них "самом деле двигается" - ни блондинки, вследствии отсутствия ускорений в данный момент (которые они обе проспали в хибернации), не знают, ни мы. С точки зрения одной блондинки, вторая приближается к ней со скоростью 0,999C. И делает все очень-очень медленно. С точки зрения второй блондинки первая приближается к ней со скоростью 0,999С. И двигается очень-очень медленно. Если они обе двигаются очень-очень медленно, значит они двигаются одинаково и обе блондинки видят, что они не двигаются очень-очень медленно. Время ни у той, ни у другой с точки зрения обоих не замедляется, значит, теория относительности врет.
Если же все-таки, одна из них стоит на месте (в реальности), а у второй время замедляется, и первая это ВИДИТ, значит вопреки теории относительности, можно в отсутствии ускорений обнаружить, кто двигается, а кто стоит, а это противоречит теории относительности и более того - свидетельствует о наличии глобальной точки отсчета и наличии всемирного эфира.
Либо вы неправильно объясняете, либо теория относительности врет. Объясняйте.
А как там жениться? Детей воспитывать? Как без русского родного общества жить? С кем дети будут расти? Совесть как - не мучает? Что потеряли после переезда? Вообще цены и погода не интересует. Волнует один вопрос - вы переезд оправдываете этим постом?
Я проясню, почему людям, и мне тоже, не нравятся читалки на андроиде. Читалка должна выполнять только одну функцию - показ книги. У андроида просто чудовищно перегруженный интерфейс. Куча приложений, куча окон, настроек, меню. Пока откроешь книгу, найдешь и откроешь нужное приложение, до дому доедешь. У меня покетбук на линуксе, я специально покупал читалку, чтобы в ней никаких приложений не было. Включаешь, в списке книг находишь нужную книгу и читаешь. Пока андроид загрузится. Все эти бесящие заставки, мельтешение и прочее. Включаться должно мгновенно.
Повторю еще раз. Люди покупают читалки доя того, чтобы в устройстве, кроме книг ничего не было. Нажал кнопку - открылась книга.
Эта китайщина, когда в устройство пихают как можно больше приложений и выдают это за плюс - уже порядком надоела.
Простите, но что дает SOLID в данном примере с аккаунтами? Идею абстрактного класса, наследования и дерева классов ввели в оборот задолго до книги Мартина. Собственно, ООП и предполагает такую иерархию. ООП и был спроектирован и разработан в расчете на это. Класс, работающий с абстрактным классом, ничего не знает о подклассах и все такое. В любом учебнике по ООП двадцатилетней давности будет представлен этот пример с аккаунтами. С автомобилями. Это студенческие примеры для обучения азам ООП.
При чем тут SOLID вообще, Мартин и его книга в частности? Из статьи, к сожалению, не понятно, что полезного добавляет SOLID к парадигме ООП.
Простите, но все эти методы кодирования информации на чертежах - это какой-то прошлый век. Двадцать первый век, АИ, все дела. Программы для набора номера телефона, при наведении на основную надпись, должны САМИ распознавать должности и фамилии, лезть в корпоративную базу данных и предлагать соответствующий контакт для пользователя. Тем более, шрифт гостовский, а не рукописный. Та-же штука для поиска чертежа в базе чертежей - соответствующая программа на телефоне конструктора должна сама распознать номер чертежа в основной надписи, отправить этот номер на комп для презентаций, а он отобразить чертеж с помощью проектора. Ну или прога на компе с помощью веб-камеры должна сама все это сделать.
Современное состояние дел таково, что от АИ ожидается, что вы вебкой навели на чертеж, а чатжпт вам тут-же сказал, где вы наврали в схеме, предложить методы улучшения и и подобрать детали. Ну и черт с ним, сразу же разводку на плате сделать.
А вы какое-то кодирование. Совком пахнет, окститесь.
Агитировать работников быть пассионарияии (как вы акцентировали - чтобы они работали больше, чем от них ожидаешь) - это как прийти в магазин и за те-же деньги требовать больше товара. В разы. Кивать при этом на Наполеонов, Путина и прочих императоров - просто неприлично. Они за свою пассионарность получают дворцы, власть, деньги и любовниц (ну, кроме может Сталина). Вы можете это предложить рядовым офисным хомякам?
Это раз. Во-вторых, если автор не пишет сейчас на Delphi, это не значит, что систем на Delphi сейчас нет. Полно. Программистов на Delphi найти - раз плюнуть, если предложить им зарплату, которую они сейчас получают, работая на Джаве. С удовольствием пойдут, даже если меньше дадите процентов на 15 (если вы понимаете почему, ха-ха).
Я, как бывший инженер-технолог, а сейчас разработчик, могу взять на себя смелость заявить, что в статье тема промпроизводства не раскрыта чуть менее чем полностью и никакой связи с ИТ не развернуто.
Не отмечено:
Разделение этапов производства. В развитом промпроизводстве все производство разделено на этапы, и вообще, на очень мелкие операции. Каждая штука изделия изготовляется не целиком, а по частям, при этом каждая операция применяется ко всей партии.
Разделение по специальности. Каждый рабочий знает и умеет только определенное множество операций. А не как мастер допетровских времен, изготовляет ружье от и до самолично. Сейчас же в ИТ является нормальным требовать, искать и быть full-stack программистом.
Разделение по деталям и участкам работ. Ответственность. В машиностроении каждый инженер отвечает только за определенное множество деталей ("картотека"). Он разрабатывает чертежи только определенных деталей и сборок, только за них отвечает, только их поддерживает и изменяет (никаких гитов в машиностроении не требуется по определению! Никаких конфликтов и накладок, бгг.). Ни одному руководителю в машиностроении не придет в голову дать менять конструкторскую или технологическую документацию детали, которую ведет другой инженер, если он еще жив (ну, кроме отпусков, конечно, люди подменяют друг друга). В ИТ же нормально, когда разработчик правит какие угодно классы у всего проекта. Кстати, микросервисы ценны в первую очередь тем, что дают возможность изолировать сферы ответственности. Каждому разработчику выделяется свой набор микросервисов, за которые он ответственен. Другие проекты в гитлабе ему просто не открываются. Разделить же классы по отдельным разработчиками - это никому в ИТ в голову не придет, как нет и инструментов реализации этого требования ни в гите, ни в других системах.
Разделение по технологи. Каждый участок, цех изготавливает детали только по определенной технологии. В ИТ же даже идеи такой нет. Отдел разработки только один и делает ВСЕ.
Наличие проекта. В машиностроении есть: Техническое предложение, Эскизный проект, Технический проект, Рабочая конструкторская документация. Только после прохождения всего проектного цикла чертежи уходят в цех на изготовление. В ИТ в большинстве ничего этого нет. Максимум - "проект" с хотелками, по которому ни изготовить нормально, ни пронормировать трудоемкость изготовления, ни протестировать готовый продукт невозможно.
Нормирование трудоемкости и материалов. В машиностроении, даже единичном, а также в строительстве, обязательно конструкторская документация (после разработки технологической документации и вместе с ней!) отправляется нормировщикам и экономистам, которые расчитывают трудоемкость изготовления и конечную стоимость каждой детали. В ИТ ничего этого нет. Планово-экономического отдела нет ни в одной софтверной конторе, даже там, где тысяча раразрабочиков пашут, даже в СБЕРЕ, я гарантирую вам это! Все софтверные конторы сейчас по-сути - разожравшиеся стартапы. Ни о какой экономике, ни о каких сроках, ценах и управляемости вообще в ИТ речи идти не может по определению. "Как пасти котов" - вот ваше все.
Возможно, что-то еще пропустил. Но то, что автор акцентирует только по величине предприятия - просто смешно. Величина и количество работников вообще ни о чем не говорит.
Может, грамотных руководителей (а не амбициозных) поискать? Которые умеют наладить производственный процесс, найти исполнителей, распределить адекватно загрузку? Короче, поработать? Директора что делаются в этой конторе?
иррациональность, бессмысленность, отрицание искусства - это и есть генерация НОВЫХ образов и смыслов, доведенных до предела и абсурда (Европа и Запад вообще в этом мастак).
Что-то мне говорит, что фанатичное следование (а джависты по-другому не могут) этим советам приведет к большим проблемам, чем представляют из себя три параметра в функции.
Полиморфизм вместо булевого параметра (по-хорошему, необходимо просто разделить метод на два, и if переместить из этой в функции в функцию, где эти две разные функции вызываются, заодно и параметр исчезнет) приведет к умножению ненужных классов и к сложности.
Сайд-эффекты неизбежны. На то он и класс с методами, что вызов методов меняет состояние объекта класса. Методы, не меняющие состояние объекта, вырождают ООП до состояния наборов функций и структур, то есть процедурное программирование. Хотя, иммутабельность во многих случаях полезно применять, но джависты не умеют без фанатизма.
"Математику уже затем учить надо, что она ум в порядок приводит".
Сколько ни работал, всегда видел, имеет ли программист высшее образование или не имеет. Изучал ли он высшую математику или нет.
Люди с вышкой имеют научный склад ума. Для них мир вокруг, программирование в частности не является магией. Они стремятся понимать, почему так. Программист с вышкой стремится к упрощению (это не размещение выражения в return!). Писать как можно меньше кода. "Что это за херня?" - вот его самый главный вопрос.
"Программист" без вышки пишет как можно больше. Для него высшая доблесть - наворотить кода как можно больше. Тысяча строк в день. Десятикратный программист. То, что в его коде без бутылки не разобраться, его не волнует - вы все дебилы.
А знаете почему? Потому что основная задача математики - упрощение выражений. Вы в школе чем на уроках математики занимались? Упрощали десятиуровневые выражения. Причем так, чтобы без ошибок, чтобы результирующее выражение выдавало тот-же результат, что и исходное.
В программировании мы в основном занимаемся тем-же самым - упрощаем код и выражения таким образом, чтобы готовый код выполнял то-же самое, что и исходный, но был простой и понятный. Причем много раз, при добавлении функционала.
Программирование - это математика.
Когда проектируется и реализуется база данных на несколько таблиц, необходимо продумывать их состав и состав их полей. Приводить их к РБНФ. Таким образом, чтобы количество таблиц и связей между ними были минимум. Строить схемы, графы. Анализировать.
Что это, если не математика?
У "программиста" без вышки нет абстрактного мышления. Он не может представить, как его код будет работать до того, как он налепит его.
Отдельный разговор про проектировщиков и постановщиков. С одной стороны у него должен быть математическое мышление, чтобы проанализировать все требования и выдать максимально простое решение. Все эти формулы, расчеты, алгоритмы и так далее. Сформулировать это для себя, математически точно. С другой стороны, у него должно быть гуманитарное образование, чтобы уметь написать буквами так, чтобы его требования и проект поняли как заказчик, так и начальники, программисты, тестировщики.
Фашизму без разницы.
Ну хорошо. А теперь в версию с массивом коэффициентов (дальше я код не анализировал) добавьте код для вычисления площади параллелограмма. Какие там данные для хранения параллелограмма? Уж точно не только ширина и высота. Сколько придется переписывать программу? Всю?
Чистый код - это про то, как поддерживать скорость разработки и далее, после того, как написал программу вычисления площадей круга и квадрата.
Орел, конечно, выявил паттерн для квадрата, круга и треугольника. А если добавить фигуру, не вписывающийся в ВАШ паттерн? Параллелограмм, у которого, как я сказал, три параметра - ширина, высота (я про стороны) и угол наклона? А если добавить еще одну операцию в интерфейс - расчет периметра? Сколько придется переписывать? Всю программу?
Нафиг, нафиг.
Ну хорошо. Объясните тогда. Два тела сближаются друг с другом в космосе. На каждом из этих тел сидит по блондинке. Кто из них "самом деле двигается" - ни блондинки, вследствии отсутствия ускорений в данный момент (которые они обе проспали в хибернации), не знают, ни мы. С точки зрения одной блондинки, вторая приближается к ней со скоростью 0,999C. И делает все очень-очень медленно. С точки зрения второй блондинки первая приближается к ней со скоростью 0,999С. И двигается очень-очень медленно. Если они обе двигаются очень-очень медленно, значит они двигаются одинаково и обе блондинки видят, что они не двигаются очень-очень медленно. Время ни у той, ни у другой с точки зрения обоих не замедляется, значит, теория относительности врет.
Если же все-таки, одна из них стоит на месте (в реальности), а у второй время замедляется, и первая это ВИДИТ, значит вопреки теории относительности, можно в отсутствии ускорений обнаружить, кто двигается, а кто стоит, а это противоречит теории относительности и более того - свидетельствует о наличии глобальной точки отсчета и наличии всемирного эфира.
Либо вы неправильно объясняете, либо теория относительности врет. Объясняйте.
А как там жениться? Детей воспитывать? Как без русского родного общества жить? С кем дети будут расти? Совесть как - не мучает? Что потеряли после переезда? Вообще цены и погода не интересует. Волнует один вопрос - вы переезд оправдываете этим постом?
[].find(e=> {e.id === id}) - это стандарт в нашем проекте!
Бедненькие. Как мне их жалко. Если серьезно, я дважды читал, и не понял, в чем проблема.
Смахивает на алгоритм B-Tree
Лексикон там есть?
Я проясню, почему людям, и мне тоже, не нравятся читалки на андроиде. Читалка должна выполнять только одну функцию - показ книги. У андроида просто чудовищно перегруженный интерфейс. Куча приложений, куча окон, настроек, меню. Пока откроешь книгу, найдешь и откроешь нужное приложение, до дому доедешь. У меня покетбук на линуксе, я специально покупал читалку, чтобы в ней никаких приложений не было. Включаешь, в списке книг находишь нужную книгу и читаешь. Пока андроид загрузится. Все эти бесящие заставки, мельтешение и прочее. Включаться должно мгновенно.
Повторю еще раз. Люди покупают читалки доя того, чтобы в устройстве, кроме книг ничего не было. Нажал кнопку - открылась книга.
Эта китайщина, когда в устройство пихают как можно больше приложений и выдают это за плюс - уже порядком надоела.
Простите, но что дает SOLID в данном примере с аккаунтами? Идею абстрактного класса, наследования и дерева классов ввели в оборот задолго до книги Мартина. Собственно, ООП и предполагает такую иерархию. ООП и был спроектирован и разработан в расчете на это. Класс, работающий с абстрактным классом, ничего не знает о подклассах и все такое. В любом учебнике по ООП двадцатилетней давности будет представлен этот пример с аккаунтами. С автомобилями. Это студенческие примеры для обучения азам ООП.
При чем тут SOLID вообще, Мартин и его книга в частности? Из статьи, к сожалению, не понятно, что полезного добавляет SOLID к парадигме ООП.
Простите, но все эти методы кодирования информации на чертежах - это какой-то прошлый век. Двадцать первый век, АИ, все дела. Программы для набора номера телефона, при наведении на основную надпись, должны САМИ распознавать должности и фамилии, лезть в корпоративную базу данных и предлагать соответствующий контакт для пользователя. Тем более, шрифт гостовский, а не рукописный. Та-же штука для поиска чертежа в базе чертежей - соответствующая программа на телефоне конструктора должна сама распознать номер чертежа в основной надписи, отправить этот номер на комп для презентаций, а он отобразить чертеж с помощью проектора. Ну или прога на компе с помощью веб-камеры должна сама все это сделать.
Современное состояние дел таково, что от АИ ожидается, что вы вебкой навели на чертеж, а чатжпт вам тут-же сказал, где вы наврали в схеме, предложить методы улучшения и и подобрать детали. Ну и черт с ним, сразу же разводку на плате сделать.
А вы какое-то кодирование. Совком пахнет, окститесь.
Агитировать работников быть пассионарияии (как вы акцентировали - чтобы они работали больше, чем от них ожидаешь) - это как прийти в магазин и за те-же деньги требовать больше товара. В разы. Кивать при этом на Наполеонов, Путина и прочих императоров - просто неприлично. Они за свою пассионарность получают дворцы, власть, деньги и любовниц (ну, кроме может Сталина). Вы можете это предложить рядовым офисным хомякам?
Автор не понимает смысла термина https://ru.wikipedia.org/wiki/Технический_долг.
Это раз. Во-вторых, если автор не пишет сейчас на Delphi, это не значит, что систем на Delphi сейчас нет. Полно. Программистов на Delphi найти - раз плюнуть, если предложить им зарплату, которую они сейчас получают, работая на Джаве. С удовольствием пойдут, даже если меньше дадите процентов на 15 (если вы понимаете почему, ха-ха).
Еще немного поживете и начнете писать на Delphi. Ну или на Питоне как на Delphi.
Я, как бывший инженер-технолог, а сейчас разработчик, могу взять на себя смелость заявить, что в статье тема промпроизводства не раскрыта чуть менее чем полностью и никакой связи с ИТ не развернуто.
Не отмечено:
Разделение этапов производства. В развитом промпроизводстве все производство разделено на этапы, и вообще, на очень мелкие операции. Каждая штука изделия изготовляется не целиком, а по частям, при этом каждая операция применяется ко всей партии.
Разделение по специальности. Каждый рабочий знает и умеет только определенное множество операций. А не как мастер допетровских времен, изготовляет ружье от и до самолично. Сейчас же в ИТ является нормальным требовать, искать и быть full-stack программистом.
Разделение по деталям и участкам работ. Ответственность. В машиностроении каждый инженер отвечает только за определенное множество деталей ("картотека"). Он разрабатывает чертежи только определенных деталей и сборок, только за них отвечает, только их поддерживает и изменяет (никаких гитов в машиностроении не требуется по определению! Никаких конфликтов и накладок, бгг.). Ни одному руководителю в машиностроении не придет в голову дать менять конструкторскую или технологическую документацию детали, которую ведет другой инженер, если он еще жив (ну, кроме отпусков, конечно, люди подменяют друг друга). В ИТ же нормально, когда разработчик правит какие угодно классы у всего проекта. Кстати, микросервисы ценны в первую очередь тем, что дают возможность изолировать сферы ответственности. Каждому разработчику выделяется свой набор микросервисов, за которые он ответственен. Другие проекты в гитлабе ему просто не открываются. Разделить же классы по отдельным разработчиками - это никому в ИТ в голову не придет, как нет и инструментов реализации этого требования ни в гите, ни в других системах.
Разделение по технологи. Каждый участок, цех изготавливает детали только по определенной технологии. В ИТ же даже идеи такой нет. Отдел разработки только один и делает ВСЕ.
Наличие проекта. В машиностроении есть: Техническое предложение, Эскизный проект, Технический проект, Рабочая конструкторская документация. Только после прохождения всего проектного цикла чертежи уходят в цех на изготовление. В ИТ в большинстве ничего этого нет. Максимум - "проект" с хотелками, по которому ни изготовить нормально, ни пронормировать трудоемкость изготовления, ни протестировать готовый продукт невозможно.
Нормирование трудоемкости и материалов. В машиностроении, даже единичном, а также в строительстве, обязательно конструкторская документация (после разработки технологической документации и вместе с ней!) отправляется нормировщикам и экономистам, которые расчитывают трудоемкость изготовления и конечную стоимость каждой детали. В ИТ ничего этого нет. Планово-экономического отдела нет ни в одной софтверной конторе, даже там, где тысяча раразрабочиков пашут, даже в СБЕРЕ, я гарантирую вам это! Все софтверные конторы сейчас по-сути - разожравшиеся стартапы. Ни о какой экономике, ни о каких сроках, ценах и управляемости вообще в ИТ речи идти не может по определению. "Как пасти котов" - вот ваше все.
Возможно, что-то еще пропустил. Но то, что автор акцентирует только по величине предприятия - просто смешно. Величина и количество работников вообще ни о чем не говорит.
Может, грамотных руководителей (а не амбициозных) поискать? Которые умеют наладить производственный процесс, найти исполнителей, распределить адекватно загрузку? Короче, поработать? Директора что делаются в этой конторе?
иррациональность, бессмысленность, отрицание искусства - это и есть генерация НОВЫХ образов и смыслов, доведенных до предела и абсурда (Европа и Запад вообще в этом мастак).
Я не понял, это обертка для общения с чатомГПТ через апи? Нужно где-то зарегистрироваться, оплатить, получить собственный код?
Что-то мне говорит, что фанатичное следование (а джависты по-другому не могут) этим советам приведет к большим проблемам, чем представляют из себя три параметра в функции.
Полиморфизм вместо булевого параметра (по-хорошему, необходимо просто разделить метод на два, и if переместить из этой в функции в функцию, где эти две разные функции вызываются, заодно и параметр исчезнет) приведет к умножению ненужных классов и к сложности.
Сайд-эффекты неизбежны. На то он и класс с методами, что вызов методов меняет состояние объекта класса. Методы, не меняющие состояние объекта, вырождают ООП до состояния наборов функций и структур, то есть процедурное программирование. Хотя, иммутабельность во многих случаях полезно применять, но джависты не умеют без фанатизма.
"Математику уже затем учить надо, что она ум в порядок приводит".
Сколько ни работал, всегда видел, имеет ли программист высшее образование или не имеет. Изучал ли он высшую математику или нет.
Люди с вышкой имеют научный склад ума. Для них мир вокруг, программирование в частности не является магией. Они стремятся понимать, почему так. Программист с вышкой стремится к упрощению (это не размещение выражения в return!). Писать как можно меньше кода. "Что это за херня?" - вот его самый главный вопрос.
"Программист" без вышки пишет как можно больше. Для него высшая доблесть - наворотить кода как можно больше. Тысяча строк в день. Десятикратный программист. То, что в его коде без бутылки не разобраться, его не волнует - вы все дебилы.
А знаете почему? Потому что основная задача математики - упрощение выражений. Вы в школе чем на уроках математики занимались? Упрощали десятиуровневые выражения. Причем так, чтобы без ошибок, чтобы результирующее выражение выдавало тот-же результат, что и исходное.
В программировании мы в основном занимаемся тем-же самым - упрощаем код и выражения таким образом, чтобы готовый код выполнял то-же самое, что и исходный, но был простой и понятный. Причем много раз, при добавлении функционала.
Программирование - это математика.
Когда проектируется и реализуется база данных на несколько таблиц, необходимо продумывать их состав и состав их полей. Приводить их к РБНФ. Таким образом, чтобы количество таблиц и связей между ними были минимум. Строить схемы, графы. Анализировать.
Что это, если не математика?
У "программиста" без вышки нет абстрактного мышления. Он не может представить, как его код будет работать до того, как он налепит его.
Отдельный разговор про проектировщиков и постановщиков. С одной стороны у него должен быть математическое мышление, чтобы проанализировать все требования и выдать максимально простое решение. Все эти формулы, расчеты, алгоритмы и так далее. Сформулировать это для себя, математически точно. С другой стороны, у него должно быть гуманитарное образование, чтобы уметь написать буквами так, чтобы его требования и проект поняли как заказчик, так и начальники, программисты, тестировщики.