Хуже-лучше, это очень субьективно. зависит больше от писателя, чем от читателя. Бывает изучаешь какой-нибудь проект на гитхабе и думаешь: о господи, лучше бы тут классов не было, когда на входе в класс у тебя 5-7 строк - френдзона.
Для коллекции Хабра материал весьма ценный. Никогда с Иксами не приходилось на столько низком уровне работать (только через XLib), но в случае если вдруг потребуется - статья есть. Часто находил по другим технологиям ответы на свои вопросы, когда приходилось копать до самых глубин.
Не везде реализовано ООП, если брать мои проекты - то тогда надо всё переводить на C++, а это налагает доп.требования, т.к. используются инструменты статического анализа. Это оборачивание в данном случае не даёт ничего кроме понятного ООПшникам исходного текста и лишних трудозатрат на удовлетворение анализаторов (а без них смысла применять C++ нет, т.к. на нём прострелить себе ногу в разы проще, чем на голом Си). Я кстати очень резкий противник оберточного программирования, и пресекаю любые попытки команды в него скатиться.
Если первая статья - то поздравляю с боевым крещением. А по теме - как раз интересно было бы узнать, почему производитель превращает такие изделия в кирпич.
Только личный опыт. Я видел как подобные вещи люди пытались утрамбовать в классы, в итоге больше половины времени убивали на организацию ООП, от чего страдала реализация, и в последствии структура классов признавалась неудачной. Один из модулей за год пережил 4 варианта - причем крайний был признан руководителем менее удачным по сравнению с предыдущим.
Тут мораль такова, что ООП - это шаблон мышления, и если он прибит гвоздями - то пиши пропало. А в остальных случаях он является лишь инструментом, и разработчик сам выбирает, использовать его или нет.
Как пример(из последнего с чем работал), есть EGL, DRM, X11 и некая аппаратура, которая делает из RGB/RGBA h.264, при этом наиболее комфортным вариантом использования этого было бы собрать всё в некое GUI дав управляющий фассад + полную свободу использования OpenGL не оборачивая его ни во что. С другой стороны крайне интересна работа самой аппаратуры сжатия, т.к. в режимах DRM и X11 там используются принципиально разные подходы, и это никак не приводится к общему знаменателю (можно конечно, но здесь придется очень пожертвовать производительностью ради красовости кода, либо создать псевдо-аналог Qt, где под капотом имплементоры будут очень тесно связаны друг с другом, и оверхед от использования классов будет чудовищным, и внутреннее взаимодействие зафренденых классов будет настолько сложным, что перевод всего на обычный процедурный стиль значительно упростит как разработку, так и дальнейший анализ написанного). Но это справедливо для Embedded, где решает не проц, а аппаратура. На ПЭВМ с этим проще(там как раз решает проц) - но она и дороже на порядок. Что мы имеем на выходе: некий прединициализированный UI с фассадным интерфейсом, набор ВУ-логики, где активно применяется MVC/MVP, SOLID и т.д. и набор процедур, которые всё это поднимают и работают под капотом, написанных в стиле близких к ядру Linux (т.е. С-интерфейсы без ООП вообще)
к сожалению, в бизнесе это очень оправданно, т.к. с одной стороны заказчик внятно не может объяснить, чего он хочет в долгосрочной перспективе, а с другой - команде разработки надо его грамотно "подоить". Agile - как раз для этого удачный инструмент :)
нет. у меня мышление не ООПшное изначально, и подход к разработке аппаратно-зависимый, т.к. аппаратура связана между собой и требует тесного межмодульного взаимодействия(некоторые вещи инкапсулировать не получится, а если имплиментацию зафрендить - то будет совсем дремучий лес). в ООП выносится уже совсем высокоуровневый слой, но если взять по количеству исходных текстов, то это процентов 30-40.
Я нашел баланс путем перехода на процедурный стиль без использования классов. Классы - интеграционная вещь, на голом Си - функциональная. В одном модуле можно спокойно разложить по функциям то, что спокойно заняло бы 3 уровня иерархии.
В погоне за прибылью человек совсем забывает о том, что смертен. Сеньёрами сразу не рождаются. Не будет джунов - придет время, что не станет и сеньеров, и человечество рискует потерять целые отрасли, отдав сейчас их более "дешевой" рабочей силе.
Иван, ты конечно не любишь, когда тобой пытаются манипулировать, но по сути ты сам еще тот манипулятор :)
По факту половина описанного позволяет команде существовать и развиваться, другая — откровенно личные черты характера и убеждения(местами ложные), не имеющие ничего общего с предполагаемым успехом и развитием команды
… просто кому-то давно пора завести подружку.
Программирование, личная эффективность, рассуждение о вечности в окне с 8 до 17 — не то, ой совсем не то )))
На работе добровольно отказался от M$ в пользу LibreOffice(хотя m$ стоит и лицуха есть) — тупо удобнее. в госконторах те, кто тексты набивает и почтой пользуется — затруднений быть не должно. а специализированный софт оч многий на веб-интерфейсе живет. в тех же МФЦ. Потому давно пора винду сносить. Держит скорее страх перед неизвестным.
Lineage что игра, что операционка. Функционал сделан по пронципу: либо через одно место, либо никак. Долго взвешивал для своего гнусмаса все за и против. Остался на стоковой, ибо падает линяга судя по отзывам частенько, и не всю аппаратную часть у девайсов видит: народ щебече то камеру только одну видит, то блюху в упор никак — у всех по разному.
Не претендую на 100% истиность, но имхо сеньёрить можно исключительно в конкретном месте(либо в отрасли), когда у тебя уже есть свита(тестировщики и джуниоры). Если ты солист, то каким бы талантливым не был — просто физически не получишь свой левел ап, сколько бы паттернов не знал.
Меняя работу(не дай бог отрасль) — первые пол года по любому уйдут на знакомство с предметной областью, корп.культурой и местными порядками, изучение проектов и т.д.
Людей сразу под реализацию идей тоже вряд-ли дадут, потому ты как бы будешь middle+ с перспективой.
Хуже-лучше, это очень субьективно. зависит больше от писателя, чем от читателя. Бывает изучаешь какой-нибудь проект на гитхабе и думаешь: о господи, лучше бы тут классов не было, когда на входе в класс у тебя 5-7 строк - френдзона.
Для коллекции Хабра материал весьма ценный. Никогда с Иксами не приходилось на столько низком уровне работать (только через XLib), но в случае если вдруг потребуется - статья есть. Часто находил по другим технологиям ответы на свои вопросы, когда приходилось копать до самых глубин.
так цена китайской платы с картоприемником и bluetooth 300р
Не везде реализовано ООП, если брать мои проекты - то тогда надо всё переводить на C++, а это налагает доп.требования, т.к. используются инструменты статического анализа. Это оборачивание в данном случае не даёт ничего кроме понятного ООПшникам исходного текста и лишних трудозатрат на удовлетворение анализаторов (а без них смысла применять C++ нет, т.к. на нём прострелить себе ногу в разы проще, чем на голом Си). Я кстати очень резкий противник оберточного программирования, и пресекаю любые попытки команды в него скатиться.
Если первая статья - то поздравляю с боевым крещением. А по теме - как раз интересно было бы узнать, почему производитель превращает такие изделия в кирпич.
Только личный опыт. Я видел как подобные вещи люди пытались утрамбовать в классы, в итоге больше половины времени убивали на организацию ООП, от чего страдала реализация, и в последствии структура классов признавалась неудачной. Один из модулей за год пережил 4 варианта - причем крайний был признан руководителем менее удачным по сравнению с предыдущим.
Тут мораль такова, что ООП - это шаблон мышления, и если он прибит гвоздями - то пиши пропало. А в остальных случаях он является лишь инструментом, и разработчик сам выбирает, использовать его или нет.
Как пример(из последнего с чем работал), есть EGL, DRM, X11 и некая аппаратура, которая делает из RGB/RGBA h.264, при этом наиболее комфортным вариантом использования этого было бы собрать всё в некое GUI дав управляющий фассад + полную свободу использования OpenGL не оборачивая его ни во что. С другой стороны крайне интересна работа самой аппаратуры сжатия, т.к. в режимах DRM и X11 там используются принципиально разные подходы, и это никак не приводится к общему знаменателю (можно конечно, но здесь придется очень пожертвовать производительностью ради красовости кода, либо создать псевдо-аналог Qt, где под капотом имплементоры будут очень тесно связаны друг с другом, и оверхед от использования классов будет чудовищным, и внутреннее взаимодействие зафренденых классов будет настолько сложным, что перевод всего на обычный процедурный стиль значительно упростит как разработку, так и дальнейший анализ написанного). Но это справедливо для Embedded, где решает не проц, а аппаратура. На ПЭВМ с этим проще(там как раз решает проц) - но она и дороже на порядок. Что мы имеем на выходе: некий прединициализированный UI с фассадным интерфейсом, набор ВУ-логики, где активно применяется MVC/MVP, SOLID и т.д. и набор процедур, которые всё это поднимают и работают под капотом, написанных в стиле близких к ядру Linux (т.е. С-интерфейсы без ООП вообще)
к сожалению, в бизнесе это очень оправданно, т.к. с одной стороны заказчик внятно не может объяснить, чего он хочет в долгосрочной перспективе, а с другой - команде разработки надо его грамотно "подоить". Agile - как раз для этого удачный инструмент :)
нет. у меня мышление не ООПшное изначально, и подход к разработке аппаратно-зависимый, т.к. аппаратура связана между собой и требует тесного межмодульного взаимодействия(некоторые вещи инкапсулировать не получится, а если имплиментацию зафрендить - то будет совсем дремучий лес). в ООП выносится уже совсем высокоуровневый слой, но если взять по количеству исходных текстов, то это процентов 30-40.
эмбеддед в последнее время
Я нашел баланс путем перехода на процедурный стиль без использования классов. Классы - интеграционная вещь, на голом Си - функциональная. В одном модуле можно спокойно разложить по функциям то, что спокойно заняло бы 3 уровня иерархии.
В погоне за прибылью человек совсем забывает о том, что смертен. Сеньёрами сразу не рождаются. Не будет джунов - придет время, что не станет и сеньеров, и человечество рискует потерять целые отрасли, отдав сейчас их более "дешевой" рабочей силе.
К сожалению, подобная политика производителей напрочь убивает интерес как к отечественным изделиям, так и к отечественной элементной базе.
Статья хорошая, работа проделана колоссальная, но как потенциальному пользователю с таким подходом - в принципе не интересно.
По факту половина описанного позволяет команде существовать и развиваться, другая — откровенно личные черты характера и убеждения(местами ложные), не имеющие ничего общего с предполагаемым успехом и развитием команды
Программирование, личная эффективность, рассуждение о вечности в окне с 8 до 17 — не то, ой совсем не то )))
PS: очень бы не хотелось лечиться у робота, напичканного программистами своими «если-то».
Меняя работу(не дай бог отрасль) — первые пол года по любому уйдут на знакомство с предметной областью, корп.культурой и местными порядками, изучение проектов и т.д.
Людей сразу под реализацию идей тоже вряд-ли дадут, потому ты как бы будешь middle+ с перспективой.