Применять практики и требовать соблюдения это две большие разницы. Пользуется человек - отлично. Нет, ну наверное быстро научится в такой конторе как ваша. Нет? Может будем тогда требовать к вакансиям десятипальцевую печать и стопроцентное зрение. Оно ведь тоже влияет.
Кто так делает? А если и так, то это такое требование к вакансии? Ладно, если есть такие, то пожалуйста, пудрите друг другу мозги. По мне так совершенно не имеющее к никакого отношения к действительности требование. Я бы лучше спросил у такого кандидата зачем он вообще такое пишет в резюме.
о чем и речь. там то это может быть оправдано, когда всё в порядке с промежуточными звеньями. а наши просто слизали не глядя методику технического собеса, ни разу не думая о том, что в реальности у нас разраб должен уметь массу посторонних вещей, скорее разбираться в целом в процессе, а не вот это всё о чем спрашивают
интересно посмотреть на способность решать логические задачи
логические задачи может стоит поинтересоваться знает ли выпускник вуза. у мидла то зачем это спрашивать. разве есть требование от команды по логическому мышлению? какая шкала тогда? что вы узнаете то? как повлияет на качество выполняемой работы логика на два и на пять?
я оцениваю техническую сторону в первую очередь
да это сколько угодно. у кандидата есть резюме. задача узнать правду ли человек написал. так? и как здесь поможет прогон по книжкам Мартина или Эванса? я это имею ввиду. написал человек что разбирается в технологии Х, посмотрите как он ей пользуется.
это классический совковый подход
ну тут вы хватанули конечно ) на западе для этого есть специальные коммуникаторы, менеджеры, аналитики. это у них лет 30 уже исправно работает. технарь там чисто технарь, ему там запрещено общаться. это у нас только внедряется. ладно.
Вы вывели свою трактовку того что написано, а затем пытаетесь её же опровергнуть. Ни кто говорит о том, что надо общаться на иностранном языке. Тезис очень простой - раз вы уже пишите код на языке основанном на английском, то почему бы и его технические атрибуты не писать на английском. И если это делать, то такой продукт будет легко адаптировать сразу на любой другой язык.
Более того, я специально оговорился, что если команда договорилась этого не делать по каким-то причинам - ради бога. Русский так русский как базовый. Опять же это никак не мешает сделать программу локализуемой изначально.
Обоснованным должно быть решение именно сделать программу для конкретного языка и под конкретную страну. А не наоборот.
Речь не о создании программ которые уже локализованы под все языки. Речь о том что бы просто предусмотреть такую возможность в будущем. Тем более что делается это совершенно просто с помощью соответствующих библиотек. Надо лишь соблюсти ряд вышеописанных условий.
На родном языке читать документацию проще.
Сомнительное заявление. Проще для кого опять же? Я говорю о подходе в принципе. Надо смотреть на мир чуть шире.
Там где поддержка нескольких языков нужна, она есть
А в какой момент у нового проекта наступает нужность добавления других языков? Кто вообще может узнать и заинтересоваться вашей библиотекой или фреймворком зарубежом, если никто просто не может понять что это?
Если имеется ввиду что надо как-то описать очень сложную внутреннюю логику, то тут кажется, что придется прибегнуть к сложным оборотам. Я понимаю о чем речь. Так часто получается, когда нужно задокументировать старый код. Но опять же по современным канонам, получается так, что это проблема скорее самого метода, значит его можно разложить на куски попроще. Либо техническое задание страдает какими-то изъянами. С другой стороны, раз этот метод уже введен в эксплуатацию и он энное время уже и так работает без документации, то надо ли вообще его документировать сейчас? )
Я бы не согласился с таким утверждением. По причине того, что нынче считается, что если класс и метод названы правильно, то в общем отдельно объяснять смысл и не нужно. А если и нужно, то описать требуется только очень специфические моменты. Ну, например, нынче вполне конвенционально назвать метод testFunctionThrowsExceptionWhenParameterIsEmpty Какой еще дополнительный уровень знания языка тут нужен? Допустим, надо пояснить, что для PHP '0' не должно рассматриваться как пустое. /* Expects '0' is not empty */
Нагромождение несвязанных между собой фактов. У телеграфа и телефона совершенно разные принципы действия. Телеграф работает на основе двоичного сигнала (замыкания и размыкания цепи), телефон - на преобразовании звуковых колебаний в электрические. Оба изобретения развивались параллельно и практически независимо друг от друга. Причем Морзе здесь играет далеко не главную роль. Морзе разработал автоматический приемник, к которому прилагалась соответствующая азбука. И никаким ученым он не был. Принцип работы и первые линии построили совершенно другие люди. В том числе и отечественные ученые и изобретатели. Вообще опираться на Википедию или патентное бюро США как на источник исторических фактов такое себе занятие.
Если рассуждать в общих абстрактных терминах, то тут напрашиваются метафоры из других сфер экономики. Разработка ПО относительно молодая индустрия, и все эти явления скорее способ системы найти энергетический оптимум. Примерно так же было практически со всеми технологиями и видами деятельности человека.
Взять медицину. Есть базовые принципы, а есть временные технологические надстройки, актуальные для текущего этапа развития. Ну, скажем, базовым принципом является анатомическая целостность организма, затем руководствуемся принципом целостности отдельных систем ну и далее можно рассуждать об отдельных органах и методах лечения болезней связанных с конкретными подсистемами и органами. Технологически в какой-то момент преобладает колдовство, траволечение, хирургия, фармацевтика, трансплантология, генетика и пр. Внутри каждой есть свои еще более специфические технологии и инструменты.
Или взять строительство. Тоже есть общее понимание геологического основания, фундамента, архитектуры. А дальше предлагаются различные строительные материалы начиная от камней и палок до 3D печати. Каждая предполагает свои нюансы и особенности технологического процесса.
Таким образом, мне кажется, что разработка ПО просто находится на стадии когда пока не очень понято где в данном случае основа, а где технологическая надстройка. Особенно учитывая, что в отличии от медицины и строительства появилось почти одновременно несколько парадигм и подходов. Индустрия переживает некий период стресса, как, скажем, медицина в военное время, или строительство после появления механической паровой тяги. Всё со временем, думаю, устаканится и успокоится. Единственное не понятно когда.
Перевод художественной литературы как-раз таки весьма творческая деятельность. И, надо сказать, хорошие переводчики отнюдь не стесняются об этом говорить.
Я не предлагаю приравнять одно другому. Отличия разумеется есть. Но они лежат не в плоскости математических знаний - вот я о чем. Разумеется программист как профессионал, в отличии от математика, ко всему прочему должен уметь обращаться с определенным специфическим набором инструментов, с разнообразными методиками и парадигмами написания кода. А главное - должен знать свое место в промышленном технологическом процессе. Это к вопросу об аналитиках, архитекторах, тестировщиках. Математик профессионал, с другой стороны, наверняка так же должен быть осведомлен о каких-то существующих передовых изысканиях, прогрессивных моделях. Про математиков не буду особенно врать, не представляю существуют ли какие-то технологические процессы и командное взаимодействие в их деятельности, но что-то специфическое наверняка есть.
Про Bombe тоже довольно стереотипная перепечатка британских заметок в духе того как Тьюринг чуть ли не в одного победил во второй мировой. Там его заслуга, если разобраться, заключается в том, что он хорошо оптимизировал алгоритмы использования польской разработки. Да, это безусловно стало неким прорывом, но на отдельное изобретение надо сильно натягивать. "Разработал", "построил", "автоматическую". Поляки тоже разработали и построили автоматические "Бомбы", просто им потом пришлось бежать из Варшавы. Да и называется в более серьезной литературе машина бомбой Тьюринга-Велчмана, что говорит о не единоличных заслугах. А касательно раскрытия планов Вермахта, так там вообще другие лица и технологии были задействованы. Штабы общались при помощи машины Лоренц, а не Энигма, и для дешифровки использовался компьютер Колосс, которого собрал другой инженер - Томми Флауерс, который в отношении раскрытия планов внес гораздо больший вклад.
ЗЫ. Ничего против Тьюринга как гениального математика не имею.
Если ключевое тут рекурсивный обход дерева, то подозреваю, что добиться "хорошего" теста будет сложно (невозможно?). С другой стороны, наверняка есть способ представить алгоритм в итеративном виде, тогда всё будет упираться в рост сложности теста по отношению к тестируемому алгоритму. В общем случае надо будет показать, что добавление дополнительного элемента не изменяет сам механизм тестирования.
В общем сдаюсь ) Честно говоря, я именно тот самый средний тырпрайз, которому не приходилось работать в идеализированных условиях. Но мне как минимум это интересно. Возьму данный пример на заметку и при случае пойду учить матчасть.
Это будет уже натягиванием совы на глобус, но, хорошо. Программисты - это математики, которые умеют формулировать и записывать алгоритмы и предикаты на языках программирования. А математики - используют для этого язык математических формул и алгебраических выражений.
Ну или если вы утверждаете, что программист только пользуется математическим аппаратом, а математик его "создает", то вот еще вариант.
Математики оперируют исходной логикой и переводят её на язык формул, а программисты переводят с языка формул на алгоритмический языки конкретных исполнителей вычислений.
Правда во втором случае становится не понятно, каким образом программисты из исходного неформального описания получают точные спецификации. То есть между постановкой задачи и её реализацией как-будто отсутствует математик, который бы сперва записал точную и однозначную формулу для программиста. Не получается ли так, что в голове у этого человека всё-таки зашит тот самый математик, присутствие которого зачем-то отрицается )
О, а вот это хорошо, слушайте. Давайте рассуждать. Является ли множество целых подмножеством рациональных чисел? Очевидно является. А еще их оба можно назвать счетными. Если математики это аналог рационального множества, а программисты целые числа, то одно в другое легко преобразовать, используя при этом третью сущность - натуральный ряд - скажем так, математику в общем смысле. То есть тут не рекурсия, а способ определения множества.
С другой стороны, почему бы и рекурсивным определениям не представлять из себя разные феномены. Ни кто надеюсь не сомневается, что, например, левое и правое два разных феномена. В то же время, левое это зеркальное отображение правого. А правое - левого. Где же тут противоречие?
Бухгалтерия это скорее свод правил, чем алгоритм, в ней нету вычислений от слова совсем. А если вам для вашей профессии нужно что-то посчитать с применением достижений современной математики, то вы безусловно в какой-то степени математик. Что не устраивает то? Почему математиком должен называться человек, который условно выдумывает теоремы и непрерывно их доказывает? Это ведь не так. Ни кто давно ничего не выдумывает. Золотой век математики как теоретической науки закончился. Сейчас работа математика сводится к более прагматическим вещам: к моделированию, к тем же численным методам. Это не звание и не титул. Это просто название профессии.
По моей логике программист - профессиональный математик, потому что использует в своих рассуждениях формальную логику и строит алгоритмы. Делает ли так дизайнер? Какой-то может и делает, но в большинстве это не так. Всё зависит от того кто такой для вас математик.
Я утрирую конечно. Но образ мышления и в том и в другом случае схож. Что-то формулируем, а потом путем логических рассуждений убеждаемся что это на самом деле так. Мысль в том, что программисты зачем-то противопоставляют свою способность к составлению алгоритмов умению доказывать истинность логических конструкций. При этом свято веря, что это у них получается интуитивно, а не потому что их научили так действовать.
Кстати о тестах. Если не верите до сих пор что вы математик по сути, то задайте себе вопрос, что такое тестирование в широком смысле? Когда вы написали спецификацию это не теорема? А тест не доказательство? Вообще есть целый раздел посвященный этому - формальная верификация. Ну или попроще, обратите внимание на то что из себя представляет мутационное тестирование.
> Я только в самых крайних и запутанных случаях формализую происходящее в программе и пытаюсь проверить корректность
Применять практики и требовать соблюдения это две большие разницы. Пользуется человек - отлично. Нет, ну наверное быстро научится в такой конторе как ваша. Нет? Может будем тогда требовать к вакансиям десятипальцевую печать и стопроцентное зрение. Оно ведь тоже влияет.
Кто так делает? А если и так, то это такое требование к вакансии? Ладно, если есть такие, то пожалуйста, пудрите друг другу мозги. По мне так совершенно не имеющее к никакого отношения к действительности требование. Я бы лучше спросил у такого кандидата зачем он вообще такое пишет в резюме.
о чем и речь. там то это может быть оправдано, когда всё в порядке с промежуточными звеньями. а наши просто слизали не глядя методику технического собеса, ни разу не думая о том, что в реальности у нас разраб должен уметь массу посторонних вещей, скорее разбираться в целом в процессе, а не вот это всё о чем спрашивают
логические задачи может стоит поинтересоваться знает ли выпускник вуза. у мидла то зачем это спрашивать. разве есть требование от команды по логическому мышлению? какая шкала тогда? что вы узнаете то? как повлияет на качество выполняемой работы логика на два и на пять?
да это сколько угодно. у кандидата есть резюме. задача узнать правду ли человек написал. так? и как здесь поможет прогон по книжкам Мартина или Эванса? я это имею ввиду. написал человек что разбирается в технологии Х, посмотрите как он ей пользуется.
ну тут вы хватанули конечно ) на западе для этого есть специальные коммуникаторы, менеджеры, аналитики. это у них лет 30 уже исправно работает. технарь там чисто технарь, ему там запрещено общаться. это у нас только внедряется. ладно.
Вы вывели свою трактовку того что написано, а затем пытаетесь её же опровергнуть. Ни кто говорит о том, что надо общаться на иностранном языке. Тезис очень простой - раз вы уже пишите код на языке основанном на английском, то почему бы и его технические атрибуты не писать на английском. И если это делать, то такой продукт будет легко адаптировать сразу на любой другой язык.
Более того, я специально оговорился, что если команда договорилась этого не делать по каким-то причинам - ради бога. Русский так русский как базовый. Опять же это никак не мешает сделать программу локализуемой изначально.
Обоснованным должно быть решение именно сделать программу для конкретного языка и под конкретную страну. А не наоборот.
Речь не о создании программ которые уже локализованы под все языки. Речь о том что бы просто предусмотреть такую возможность в будущем. Тем более что делается это совершенно просто с помощью соответствующих библиотек. Надо лишь соблюсти ряд вышеописанных условий.
Сомнительное заявление. Проще для кого опять же? Я говорю о подходе в принципе. Надо смотреть на мир чуть шире.
А в какой момент у нового проекта наступает нужность добавления других языков? Кто вообще может узнать и заинтересоваться вашей библиотекой или фреймворком зарубежом, если никто просто не может понять что это?
Если имеется ввиду что надо как-то описать очень сложную внутреннюю логику, то тут кажется, что придется прибегнуть к сложным оборотам. Я понимаю о чем речь. Так часто получается, когда нужно задокументировать старый код. Но опять же по современным канонам, получается так, что это проблема скорее самого метода, значит его можно разложить на куски попроще. Либо техническое задание страдает какими-то изъянами. С другой стороны, раз этот метод уже введен в эксплуатацию и он энное время уже и так работает без документации, то надо ли вообще его документировать сейчас? )
Я бы не согласился с таким утверждением. По причине того, что нынче считается, что если класс и метод названы правильно, то в общем отдельно объяснять смысл и не нужно. А если и нужно, то описать требуется только очень специфические моменты. Ну, например, нынче вполне конвенционально назвать метод
testFunctionThrowsExceptionWhenParameterIsEmptyКакой еще дополнительный уровень знания языка тут нужен? Допустим, надо пояснить, что для PHP '0' не должно рассматриваться как пустое./* Expects '0' is not empty */Нагромождение несвязанных между собой фактов. У телеграфа и телефона совершенно разные принципы действия. Телеграф работает на основе двоичного сигнала (замыкания и размыкания цепи), телефон - на преобразовании звуковых колебаний в электрические. Оба изобретения развивались параллельно и практически независимо друг от друга. Причем Морзе здесь играет далеко не главную роль. Морзе разработал автоматический приемник, к которому прилагалась соответствующая азбука. И никаким ученым он не был. Принцип работы и первые линии построили совершенно другие люди. В том числе и отечественные ученые и изобретатели. Вообще опираться на Википедию или патентное бюро США как на источник исторических фактов такое себе занятие.
Если рассуждать в общих абстрактных терминах, то тут напрашиваются метафоры из других сфер экономики. Разработка ПО относительно молодая индустрия, и все эти явления скорее способ системы найти энергетический оптимум. Примерно так же было практически со всеми технологиями и видами деятельности человека.
Взять медицину. Есть базовые принципы, а есть временные технологические надстройки, актуальные для текущего этапа развития. Ну, скажем, базовым принципом является анатомическая целостность организма, затем руководствуемся принципом целостности отдельных систем ну и далее можно рассуждать об отдельных органах и методах лечения болезней связанных с конкретными подсистемами и органами. Технологически в какой-то момент преобладает колдовство, траволечение, хирургия, фармацевтика, трансплантология, генетика и пр. Внутри каждой есть свои еще более специфические технологии и инструменты.
Или взять строительство. Тоже есть общее понимание геологического основания, фундамента, архитектуры. А дальше предлагаются различные строительные материалы начиная от камней и палок до 3D печати. Каждая предполагает свои нюансы и особенности технологического процесса.
Таким образом, мне кажется, что разработка ПО просто находится на стадии когда пока не очень понято где в данном случае основа, а где технологическая надстройка. Особенно учитывая, что в отличии от медицины и строительства появилось почти одновременно несколько парадигм и подходов. Индустрия переживает некий период стресса, как, скажем, медицина в военное время, или строительство после появления механической паровой тяги. Всё со временем, думаю, устаканится и успокоится. Единственное не понятно когда.
Перевод художественной литературы как-раз таки весьма творческая деятельность. И, надо сказать, хорошие переводчики отнюдь не стесняются об этом говорить.
Я не предлагаю приравнять одно другому. Отличия разумеется есть. Но они лежат не в плоскости математических знаний - вот я о чем. Разумеется программист как профессионал, в отличии от математика, ко всему прочему должен уметь обращаться с определенным специфическим набором инструментов, с разнообразными методиками и парадигмами написания кода. А главное - должен знать свое место в промышленном технологическом процессе. Это к вопросу об аналитиках, архитекторах, тестировщиках. Математик профессионал, с другой стороны, наверняка так же должен быть осведомлен о каких-то существующих передовых изысканиях, прогрессивных моделях. Про математиков не буду особенно врать, не представляю существуют ли какие-то технологические процессы и командное взаимодействие в их деятельности, но что-то специфическое наверняка есть.
Про Bombe тоже довольно стереотипная перепечатка британских заметок в духе того как Тьюринг чуть ли не в одного победил во второй мировой. Там его заслуга, если разобраться, заключается в том, что он хорошо оптимизировал алгоритмы использования польской разработки. Да, это безусловно стало неким прорывом, но на отдельное изобретение надо сильно натягивать. "Разработал", "построил", "автоматическую". Поляки тоже разработали и построили автоматические "Бомбы", просто им потом пришлось бежать из Варшавы. Да и называется в более серьезной литературе машина бомбой Тьюринга-Велчмана, что говорит о не единоличных заслугах. А касательно раскрытия планов Вермахта, так там вообще другие лица и технологии были задействованы. Штабы общались при помощи машины Лоренц, а не Энигма, и для дешифровки использовался компьютер Колосс, которого собрал другой инженер - Томми Флауерс, который в отношении раскрытия планов внес гораздо больший вклад.
ЗЫ. Ничего против Тьюринга как гениального математика не имею.
Если ключевое тут рекурсивный обход дерева, то подозреваю, что добиться "хорошего" теста будет сложно (невозможно?). С другой стороны, наверняка есть способ представить алгоритм в итеративном виде, тогда всё будет упираться в рост сложности теста по отношению к тестируемому алгоритму. В общем случае надо будет показать, что добавление дополнительного элемента не изменяет сам механизм тестирования.
В общем сдаюсь ) Честно говоря, я именно тот самый средний тырпрайз, которому не приходилось работать в идеализированных условиях. Но мне как минимум это интересно. Возьму данный пример на заметку и при случае пойду учить матчасть.
Это будет уже натягиванием совы на глобус, но, хорошо. Программисты - это математики, которые умеют формулировать и записывать алгоритмы и предикаты на языках программирования. А математики - используют для этого язык математических формул и алгебраических выражений.
Ну или если вы утверждаете, что программист только пользуется математическим аппаратом, а математик его "создает", то вот еще вариант.
Математики оперируют исходной логикой и переводят её на язык формул, а программисты переводят с языка формул на алгоритмический языки конкретных исполнителей вычислений.
Правда во втором случае становится не понятно, каким образом программисты из исходного неформального описания получают точные спецификации. То есть между постановкой задачи и её реализацией как-будто отсутствует математик, который бы сперва записал точную и однозначную формулу для программиста. Не получается ли так, что в голове у этого человека всё-таки зашит тот самый математик, присутствие которого зачем-то отрицается )
О, а вот это хорошо, слушайте. Давайте рассуждать. Является ли множество целых подмножеством рациональных чисел? Очевидно является. А еще их оба можно назвать счетными. Если математики это аналог рационального множества, а программисты целые числа, то одно в другое легко преобразовать, используя при этом третью сущность - натуральный ряд - скажем так, математику в общем смысле. То есть тут не рекурсия, а способ определения множества.
С другой стороны, почему бы и рекурсивным определениям не представлять из себя разные феномены. Ни кто надеюсь не сомневается, что, например, левое и правое два разных феномена. В то же время, левое это зеркальное отображение правого. А правое - левого. Где же тут противоречие?
Бухгалтерия это скорее свод правил, чем алгоритм, в ней нету вычислений от слова совсем. А если вам для вашей профессии нужно что-то посчитать с применением достижений современной математики, то вы безусловно в какой-то степени математик. Что не устраивает то? Почему математиком должен называться человек, который условно выдумывает теоремы и непрерывно их доказывает? Это ведь не так. Ни кто давно ничего не выдумывает. Золотой век математики как теоретической науки закончился. Сейчас работа математика сводится к более прагматическим вещам: к моделированию, к тем же численным методам. Это не звание и не титул. Это просто название профессии.
По моей логике программист - профессиональный математик, потому что использует в своих рассуждениях формальную логику и строит алгоритмы. Делает ли так дизайнер? Какой-то может и делает, но в большинстве это не так. Всё зависит от того кто такой для вас математик.
Я утрирую конечно. Но образ мышления и в том и в другом случае схож. Что-то формулируем, а потом путем логических рассуждений убеждаемся что это на самом деле так. Мысль в том, что программисты зачем-то противопоставляют свою способность к составлению алгоритмов умению доказывать истинность логических конструкций. При этом свято веря, что это у них получается интуитивно, а не потому что их научили так действовать.
Кстати о тестах. Если не верите до сих пор что вы математик по сути, то задайте себе вопрос, что такое тестирование в широком смысле? Когда вы написали спецификацию это не теорема? А тест не доказательство? Вообще есть целый раздел посвященный этому - формальная верификация. Ну или попроще, обратите внимание на то что из себя представляет мутационное тестирование.
> Я только в самых крайних и запутанных случаях формализую происходящее в программе и пытаюсь проверить корректность
И это плохо