Ну да, скажите это инженерам НАСА. Там тысячи инженеров-конструкторов. Или на УВЗ, в одном только Уральском Конструкторском Бюро Вагоностроения - порядка 500 конструкторов. Все там прекрасно со взаимозаменяемостью (ну, кроме Главных, конечно). И со специализацией отлично - конструктора двигателисты, прочнисты, ....-ты, каждый только по своей специальности работают годами.
Это только в ИТ есть понятие, немыслимое нигде в других отраслях - Fullstack, который есть суть мастеровой, который и ложе вытачивает, и ствол кует, и замок пилит, и резьбу делает.
Можно делать по-нормальному, читайте "Делай как в Гугл" - у них есть подвижки в правильную сторону.
Бгг. Вы на производстве-то вообще были? Прежде чем писать предложение с многоточием, неплохо бы и в цехе поработать. Полно женщин и среди токарей. Среди шлифовщих - большинство женщин. Штамповики (которые на листоштамповочных прессах работают, ну кроме тех, которые с большими тяжелыми деталями работают) - одни женщины. Крановщицы - одни женщины.
Вы сравниваете сейчас нормальное промышленное производство (токари и сварщики) с гаражным и индивидуальным производством.
Да, в гаражном и частном производство есть такая "шляпа" - работники невзаимозаменяемые. В промышленности, уже с восемнадцатого века, когда цеховая система производства ушла, работники взаимозаменяемые. Это один из главнейших основ промпроизводства.
ИТ находится в состоянии цехового производства, где работники невзаимозаменяемые, стандартизации, специализации и разделения труда нет. Любая ИТ-фирма (кроме в некоторой степени Гугла и Сбера) - это разожравшийся на бешеных деньгах стартап, не смогший и не пожелавший из гаражного производства превратиться в нормальное промышленное предприятие.
Все это прикольно, но обладает единственным пороком, ставящим крест на идее генерить тесты с помощью АИ.
Только что прочитал книгу Хорикова (рекомендую), в которой он (что впрочем я и раньше знал) говорит следующее:
Тесты должны писаться исходя из бизнес-логики, задаваемой проектом и заказчиками ДО написания реализации классов. Ни в коем случае не ориентируясь на содержимое классов.
Что вы подавали на вход АИ? Сами классы?
В крайнем случае, можно подавать интерфейсы с подробной документацией, что должно выполняться в рамках этого интерфейса, и давать задание проверять имплементацию в виде того или иного класса.
Вместо радости от самостоятельного вскапывания поля, я теперь просто дергаю за рычаги и нажимаю на педаль газа.
Если серьезно - вы хотя бы по-русски (по-английски) научитесь писать, внятно излагать свои мысли и вообще научитесь коллаборации, делегированию обязанностей и архитектурному мышлению.
Более того, тест хорошо работает для низкого диапазона, но плохо работает для высокого, потому что его пишут... нет, не дебилы, но условно говоря, люди с IQ=100.
Это не значит, что методика не работает вообще, это значит, что конкретно эти тесты (кстати, какие конкретно тесты использовались в этом исследовании, кто их разрабатывал? В каких областях разработчики являются учеными и являются ли вообще учеными?) не годятся для тестирования умных людей.
Может, если бы Фейнману дали бы задание разработать IQ тесты, его тесты хорошо бы работали для высоких диапазонов?
Смешно, конечно. Как дебилам оценить в баллах интеллект умных людей? Как муравью оценить интеллект человека? Как человеку оценить интеллект представителя цивилизации III типа по шкале Кардашева?
Нэймспейсы не особо относятся к ООП. Вполне можно их реализовать без ООП. Приватные поля элементарно решаются без ООП, путем определения методов доступа в том-же модуле, где определена структура.
Я тоже не понимаю "нет метрик". Элементарно - по времени, которое требуется для не читавшего данный код разработчика (но обладающего нужными компетенциями в предметной области, конечно) сделать минимальное изменение в функционале. Если для кода от одного разработчика требуется полчаса, а для кода от другого - полдня - можно уже делать определенные выводы.
Как вариант - насколько легко данный функционал покрывается юнит-тестами. Вполне можно сделать так, чтобы код писался одним разработчиком, а на покрытие отправлялся другому. Если тестер начинает материться - необходимо просто вернуть опус разработчику (и заставить его переделывать работу до тех пор, пока ее не пример тестер).
Сейчас бардак в разработке, потому что работу никто не контролирует, никто не тестирует, в шарагах нет (я гарантирую вам это!) ни внятных процедур контроля качества, ни стандартов качества, вообще ничего.
Ключевая ошибка разработчиков. Код пишется для бизнеса, чтобы он решал их проблему. Он пишется, в первую очередь, чтобы вписаться в бюджет, сроки, технические ограничения и т.д, а не для того, чтобы быть "читаемым" для кого-то в дальнейшем.
В машиностроении и строительстве есть такое понятие как "ГОСТ" на оформление чертежей и "нормоконтроль". И те и другие были сформированы в позапрошлом веке.
Правила оформления были созданы не сдуру, и не просто так, чтобы усложнить жизнь разработчиков. Они были созданы для того, чтобы все инженеры могли свободно читать чертежи других инженеров. Именно для того, чтобы быть читаемыми для кого-то в дальнейшем, без всяких кавычек. Не думаете же вы, что наши предки были дураками и не хотели вписываться в бюджет?
В ИТ вообще и во многих шарагах в частности, творится бардак. Однако во многих компаниях уже начинают наводить порядок, и по-сути, вводят нормоконтроль на оформление кода. По различным постам на Хабре - в Сбере (причем в негативном ключе, с точки зрения авторов), и в Гугле (насколько я понял, прочитав "Делай как в Гугл").
Способ был бы, если бы в Java можно было бы писать другим способом. Это не способ, и даже не инструмент, а парадигма, в рамках которой мы ВЫНУЖДЕНЫ писать программы на JAVA, а для того, чтобы обходить проблемы, навязываемые этой парадигмой, приходится выдумывать паттерны, фреймворки и велосипеды, тысячи их!
ООП, как вы привели пример из Линукса - это всего лишь организация кода, и подозреваю, не единственно возможный. Довольно странно реализовывать и зашивать ПРЯМО В ЯЗЫК эту организацию.
Потому как вы правильно заметили, не везде ООП нужен. А где он не нужен, начинаются траблы, пляски и десятки книжек, начиная от Банды Четырех и кончая Дядей Бобом.
Имхо, достаточно было бы в Си добавить средства, облегчающие организацию VMT, и на этом стоило бы закончить.
Апд. Еще бы, имхо, полезно было бы добавить модули и переменные модулей с системой инициализации, чтобы можно было организовать что-то типа Spring с DI, и было бы вообще замечательно.
Ну да, скажите это инженерам НАСА. Там тысячи инженеров-конструкторов. Или на УВЗ, в одном только Уральском Конструкторском Бюро Вагоностроения - порядка 500 конструкторов. Все там прекрасно со взаимозаменяемостью (ну, кроме Главных, конечно). И со специализацией отлично - конструктора двигателисты, прочнисты, ....-ты, каждый только по своей специальности работают годами.
Это только в ИТ есть понятие, немыслимое нигде в других отраслях - Fullstack, который есть суть мастеровой, который и ложе вытачивает, и ствол кует, и замок пилит, и резьбу делает.
Можно делать по-нормальному, читайте "Делай как в Гугл" - у них есть подвижки в правильную сторону.
Один сварщик шестого разряда не может быть один на заводе - это не завод тогда, а гаражный кооператив.
Бгг. Вы на производстве-то вообще были? Прежде чем писать предложение с многоточием, неплохо бы и в цехе поработать. Полно женщин и среди токарей. Среди шлифовщих - большинство женщин. Штамповики (которые на листоштамповочных прессах работают, ну кроме тех, которые с большими тяжелыми деталями работают) - одни женщины. Крановщицы - одни женщины.
Вы сравниваете сейчас нормальное промышленное производство (токари и сварщики) с гаражным и индивидуальным производством.
Да, в гаражном и частном производство есть такая "шляпа" - работники невзаимозаменяемые. В промышленности, уже с восемнадцатого века, когда цеховая система производства ушла, работники взаимозаменяемые. Это один из главнейших основ промпроизводства.
ИТ находится в состоянии цехового производства, где работники невзаимозаменяемые, стандартизации, специализации и разделения труда нет. Любая ИТ-фирма (кроме в некоторой степени Гугла и Сбера) - это разожравшийся на бешеных деньгах стартап, не смогший и не пожелавший из гаражного производства превратиться в нормальное промышленное предприятие.
Об этом цитата совершенно справедливо и говорит.
Сплошные противоречия. Я разочарован.
"Работодатель не хочет брать женщин" - "Девушки не хотят учить программирование, хотят крутить попой перед камерой"
"На рынке дефицит программистов" - "Работодатели не хотят брать женщин" (по каким-то выдуманным предлогам)
Женщина уйдет в декрет - да молодые парни не задерживаются на одной работе больше двух лет, текучка в ИТ страшнейшая.
Перерыв в росте компетенций - работодателям точно нужен рост компетенций?
Добавлю. У нас треть программистов - женщины. В техподдержке, аналитиках, менеджменте - подавляющее большинство женщины.
Теперь нужно следующее исследование - с какого конца разбивать яйца энергетически выгоднее - с тупого или с острого конца.
Все это прикольно, но обладает единственным пороком, ставящим крест на идее генерить тесты с помощью АИ.
Только что прочитал книгу Хорикова (рекомендую), в которой он (что впрочем я и раньше знал) говорит следующее:
Тесты должны писаться исходя из бизнес-логики, задаваемой проектом и заказчиками ДО написания реализации классов. Ни в коем случае не ориентируясь на содержимое классов.
Что вы подавали на вход АИ? Сами классы?
В крайнем случае, можно подавать интерфейсы с подробной документацией, что должно выполняться в рамках этого интерфейса, и давать задание проверять имплементацию в виде того или иного класса.
Вместо радости от самостоятельного вскапывания поля, я теперь просто дергаю за рычаги и нажимаю на педаль газа.
Если серьезно - вы хотя бы по-русски (по-английски) научитесь писать, внятно излагать свои мысли и вообще научитесь коллаборации, делегированию обязанностей и архитектурному мышлению.
ПС. Кропотливо набирать блоки кода уже, честно говоря, надоело.
Простите, я не понял. Эти сигналы с разных приборов и с разных обсерваторий?
Не будем развивать эту тему дальше...
Наврал, на протон, электрон и антинейтрино
Добавка: в России claude code недоступен.
Между Spring Data JPA и Spring Data JDBC радикальная разница. И проявляется она именно в примере с
Более того, тест хорошо работает для низкого диапазона, но плохо работает для высокого, потому что его пишут... нет, не дебилы, но условно говоря, люди с IQ=100.
Это не значит, что методика не работает вообще, это значит, что конкретно эти тесты (кстати, какие конкретно тесты использовались в этом исследовании, кто их разрабатывал? В каких областях разработчики являются учеными и являются ли вообще учеными?) не годятся для тестирования умных людей.
Может, если бы Фейнману дали бы задание разработать IQ тесты, его тесты хорошо бы работали для высоких диапазонов?
Смешно, конечно. Как дебилам оценить в баллах интеллект умных людей? Как муравью оценить интеллект человека? Как человеку оценить интеллект представителя цивилизации III типа по шкале Кардашева?
Стучу локтем по столу. Стучу мышью мышью без необходимости. Что делать?
Нэймспейсы не особо относятся к ООП. Вполне можно их реализовать без ООП. Приватные поля элементарно решаются без ООП, путем определения методов доступа в том-же модуле, где определена структура.
Я тоже не понимаю "нет метрик". Элементарно - по времени, которое требуется для не читавшего данный код разработчика (но обладающего нужными компетенциями в предметной области, конечно) сделать минимальное изменение в функционале. Если для кода от одного разработчика требуется полчаса, а для кода от другого - полдня - можно уже делать определенные выводы.
Как вариант - насколько легко данный функционал покрывается юнит-тестами. Вполне можно сделать так, чтобы код писался одним разработчиком, а на покрытие отправлялся другому. Если тестер начинает материться - необходимо просто вернуть опус разработчику (и заставить его переделывать работу до тех пор, пока ее не пример тестер).
Сейчас бардак в разработке, потому что работу никто не контролирует, никто не тестирует, в шарагах нет (я гарантирую вам это!) ни внятных процедур контроля качества, ни стандартов качества, вообще ничего.
В машиностроении и строительстве есть такое понятие как "ГОСТ" на оформление чертежей и "нормоконтроль". И те и другие были сформированы в позапрошлом веке.
Правила оформления были созданы не сдуру, и не просто так, чтобы усложнить жизнь разработчиков. Они были созданы для того, чтобы все инженеры могли свободно читать чертежи других инженеров. Именно для того, чтобы быть читаемыми для кого-то в дальнейшем, без всяких кавычек. Не думаете же вы, что наши предки были дураками и не хотели вписываться в бюджет?
В ИТ вообще и во многих шарагах в частности, творится бардак. Однако во многих компаниях уже начинают наводить порядок, и по-сути, вводят нормоконтроль на оформление кода. По различным постам на Хабре - в Сбере (причем в негативном ключе, с точки зрения авторов), и в Гугле (насколько я понял, прочитав "Делай как в Гугл").
Способ был бы, если бы в Java можно было бы писать другим способом. Это не способ, и даже не инструмент, а парадигма, в рамках которой мы ВЫНУЖДЕНЫ писать программы на JAVA, а для того, чтобы обходить проблемы, навязываемые этой парадигмой, приходится выдумывать паттерны, фреймворки и велосипеды, тысячи их!
ООП, как вы привели пример из Линукса - это всего лишь организация кода, и подозреваю, не единственно возможный. Довольно странно реализовывать и зашивать ПРЯМО В ЯЗЫК эту организацию.
Потому как вы правильно заметили, не везде ООП нужен. А где он не нужен, начинаются траблы, пляски и десятки книжек, начиная от Банды Четырех и кончая Дядей Бобом.
Имхо, достаточно было бы в Си добавить средства, облегчающие организацию VMT, и на этом стоило бы закончить.
Апд. Еще бы, имхо, полезно было бы добавить модули и переменные модулей с системой инициализации, чтобы можно было организовать что-то типа Spring с DI, и было бы вообще замечательно.