caxapa.ru :: А кто будет решать задачу? И жвец и жнец и embedded-программист? В чём-то Evgeny_CD прав. Программист может масштабы задачи в целом со своей колокольни не представлять.

fk0, легенда (20.05.2013 14:26, просмотров: 14184) Shura

А кто будет решать задачу? И жвец и жнец и embedded-программист? В чём-то Evgeny_CD прав. Программист может масштабы задачи в целом со своей колокольни не представлять.

[ZX]

Ответить

- значит либо до него не донесли все тонкости задачи (иногда умышленно скрыли), либо это не программист встраиваемых систем, а (быдло)кодер - koyodza(20.05.2013 14:33)
  - Таки да, в чём-то кодер. Хороший программист в железе ничего не понимает. А "железячник" в программировании. А швец и жнец плох во всём сразу и такой подход работает только в курятниках любительского уровня. Хороший специалист подобен флюсу и fk0(226 знак., 20.05.2013 15:17)
    - Абстрактный уровень хорош только при проектировании систем и именно на уровне системы.Проектировать ну скажем "измеритель содержания конского навоза в ослинной моче" на абстрактном уровне невозможно. PlainUser(68 знак., 21.05.2013 07:23)
      - Все почему то воспринимают "абстракцию" как полную оторванность от реальности. А ведь абстракция вполне может учитывать очень много вещей, в том числе и доступные расходуемые ресурсы. Более того, тот, кто не в состоянии сделать нормальную =AlexD=(78 знак., 21.05.2013 08:32)
        
        Нельзя учитывать то в чем не разбираешся.А если разбираешся во всем то ... см выше.Поэтому есть абстракция сверху и делегирование оветственности за конкретные нюансы вниз. PlainUser(83 знак., 21.05.2013 10:15)
    - это Вы про "хороших программистов 1С" наверное говорите. Мы тут про программистов МК, а соваться сюда без базовых знаний в схемотехнике не стоит, ничего хорошего не получится. Естественно, программист может быть слаб в схемотехнике, но он koyodza(23 знак., 20.05.2013 15:20)
      - У нас среднее образовние обязательное. И как работает транзистор следовательно каждый должен знать. Или там про закон Ома и т.п. вещи. За основы сгодится? А вот программировать embedded программисты часто плохо умеют. И речь тоже не про Haskell fk0(750 знак., 20.05.2013 15:37)
        
        Чем лучше программист тем дальше его нужно держать от эмбеддед задач. PlainUser(744 знак., 21.05.2013 07:41)
        
        отлично сказано - koyodza(21.05.2013 11:46)
        
        Чушь полная, как в описании качеств "хорошего программиста" так и в описании методов его работы. - =AlexD=(21.05.2013 08:35)
        
        Возможно у вас другие , поздравляю. - PlainUser(21.05.2013 10:25)
        
        У меня другие представления, о том, что такое хороший программист. Причём несущественно, о какой сфере деятельности идёт речь. Тот, кого Вы описали (стиль писюко-кодеров) - суть говнокодер. - =AlexD=(21.05.2013 11:11)
        
        Обобщу , хороший специалист любого профиля четко понимает границы своих знаний и возможностей.У программистов с этим плоховато.В основном ввиду относительной молодости этой профессии и слишком мощных инструментов в руках. - PlainUser(21.05.2013 15:21)
        
        А можно примерчик? А то я и так вертел в голове Вашу фразу , и этак, и никак не смог приложить её к реальности. =AlexD=(1223 знак., 22.05.2013 08:46)
        
        Лучше бы он был похож на труд писателя документальной литературы.Те вместо собственных домыслов "как оно работает" использовались-бы факты.Это конечно намного более скучный и рутинный труд , фантазии развернуться негде. PlainUser(1148 знак., 23.05.2013 10:44)
        
        Это я к тому что стыки областей знаний программист-железячник-конструктор-разработчик_функционала-дизайнер неприкрыты и даже еще как следует не исследованы. - PlainUser(23.05.2013 10:47)
        
        И вообще, бесит, когда железячники не в состоянии сделать элементарную железяку, которая хотя бы нормально сбрасывалась по питанию, или не в состоянии описать все функции железа, включая побочные эффекты, а виноваты потом "хорошие программисты", =AlexD=(246 знак., 21.05.2013 08:44)
        
        С приличными железячниками вообще беда.Еще хуже чем с программистами. - PlainUser(21.05.2013 10:28)
        
        Вот гаднием как-раз и не надо (категорически) заниматься.Надо спросить железячника что конкретно делает его схема в такой-то ситуации. PlainUser(144 знак., 21.05.2013 10:07)
        
        Моя точка зрения: HAL уровень должны писать ТОЛЬКО железячники, возможно бывшие. PlainUser(75 знак., 21.05.2013 10:09)
        
        Кто пишет HAL уровень особого значения не имеет, т.к. это всего лишь уровень битиков регистров периферии, а особенности функционирования как правило вылезают на гораааздо более высоких уровнях. Не, я не спорю, что настройкой какого-нибудь =AlexD=(518 знак., 21.05.2013 11:22)
        
        Вы сильно отклонились от первоначальной темы - koyodza(20.05.2013 15:44)
      - Скажите, какой размер коллектива, которым Вам приходилось руководить? Мне - 34 человека + завод, который делал - там человек 50 персонала на нас работало. - Evgeny_CD(20.05.2013 15:25)
        
        никакой. Мне это не интересно koyodza(122 знак., 20.05.2013 15:48)
        
        Это просто одна из основ разницы наших подходов. - Evgeny_CD(20.05.2013 15:51)
        
        знаю - koyodza(20.05.2013 15:53)
  - Так уважаемый, приплыли! Вот Вы и постучались в стенку! Evgeny_CD(479 знак., 20.05.2013 14:38)
    - так никто не говорит, что каждый исполнитель должен быть на все руки мастер. Но каждый исполнитель должен понимать, что и зачем он делает, и не быть стеснён в выборе без веских на то причин, а не потому, что манагеру еррата показалась слишком koyodza(8 знак., 20.05.2013 15:15)
      - Манагеру надо знать о рисках, проистекающих из ераты, и о цене этих рисков. - Evgeny_CD(20.05.2013 15:32)
        
        А манагер понимает, что размер ерраты ни о чём вообще не говорит? У некоторых еррата маленькая может потому, что обратной связи с потребителем нет, а глючит не меньше. А большая еррата, несколько версий чипов --> тестируют, находят ошибки, fk0(96 знак., 20.05.2013 15:42)
        
        Размер ерраты в байтах я не сравниваю. Мне так сдается, что я могу понять суть многих из них :) - Evgeny_CD(20.05.2013 15:50)
        
        из Ваших высказываний на эту тему больше похоже на то, что важен как раз размер, а суть остаётся за кадром - koyodza(20.05.2013 15:52)
        
        +100. Да и сами ошибки бывают разные - одни вы вообще никогда не заметили бы, а другие не позволят выполнить нужное - koyodza(20.05.2013 15:43 - 15:47)
    - Херовый вывод на самом деле. Знание CONOPS изделия может очень сильно помогать в разработке. И наоборот - отсутствие этого знания приводит к разработке сфероконины, которую потом хер к чему прикрутишь без кувалды и такой-то матери. - Shura(20.05.2013 14:42)
      - Так вот, этот эксперт достаточно умен, чтобы допускать внешнее управление. Он не лезет не всвое, а другие люди в команде мыслят категориями конечного решения, и избегают сфероконины. - Evgeny_CD(20.05.2013 14:46)
        
        Всё равно вы меня не убедите, что разработчик не должен представлять себе, где и как будет использоваться его продукт. По моему опыту, это как раз одна из главнейших причин появления негодных продуктов. - Shura(20.05.2013 14:49)
        
        +1. особенно эффективно работает командировка разработчика на пуско-наладочные испытания. столько нового можно узнать не только об условиях эксплуатации, но даже о своем приборе, себе, и своих ближних и дальних родственниках. и всё за один день :> - Snaky(21.05.2013 02:53)
        
        +100500 :=) - koyodza(21.05.2013 11:45)
        
        да, согласен: когда разработчику пох (либо потому что его искусственно ограничили в информации, либо потому что он такой и есть - не важно) продукт обычно получается говняный - koyodza(20.05.2013 15:12)
        
        Этот разработчик представляет :) И охотно излагает суть и детали своей работы. Но вот только говорит он на языке матлаба... - Evgeny_CD(20.05.2013 14:51)
        
        А когда в железе потом это всё не работает, то с претензиями предлагает обращаться в MathWorks? ;-) - Shura(20.05.2013 14:53)
        
        Опытный факт, что его "матан" работает всегда. Это удивительно, но факт. И когда в результате ошибок производительность софткора проца упала чуть ни на 30%, он 3 мес пыхтел, но его софт таки заработал. МАСТЕР! Ошибки в плате исравить было уже Evgeny_CD(14 знак., 20.05.2013 14:56)
        
        такие тяжелые ошибки в плате и софте не благодаря ли изначально неверному выбору или постановке задания исполнителям возникли? - koyodza(20.05.2013 15:10)
        
        Нет. Были куплены FPGA не той скорости - снабжение про... А поскольку этот была контролируемая закупка под управлением ВП, сертификация и проч, то изменить в срок было уже невозможно. + по разным причинам делали очень сложную плату "с первого Evgeny_CD(109 знак., 20.05.2013 15:13)
        
        а кто снабжению позволил выполнить замену? И кто внёс потом эту замену в сертификационную документацию? - koyodza(20.05.2013 15:16)
        
        Для простоты можно сказать, что накосячил я, как руководитель, которого подвел подчиненный. К счатью, он больше у нас не работает. - Evgeny_CD(20.05.2013 15:19)
        
        ну вот и разобрались. "И эти люди запрещают нам ковыряться в носу" :=) koyodza(112 знак., 20.05.2013 15:24)
        
        В момент, когда закупки окончательно утверждались, я уже не был руководителем этого процесса, я перешел на другую работу. Но дало делали нанятые мною люди, так что я все равно за это отвечаю, хоть и неформально. - Evgeny_CD(20.05.2013 15:30)

Средства и методы разработки