Такой выбор был всегда — и 10 и 20 лет назад.
Что касается проблемы отрыва образования от реальности — по-идее, она должна решаться тем что называется «производственная практика». Другое дело, что у нас сейчас это чаще всего чисто ради галочки.
Комбинат VEB Robotron был создан в 1961 году и выпускал самые разные компьютеры, и массу другой электроники. Скорее всего вы имеете в виду домашние машины — Robotron KC 85 и KC 87, выпускались с 1984 года.
Хотел было написать что у вас вышел неплохой обзор. Но взгляд зацепился за «8D».
В отличие от остальных 8-разрядных компьютеров «Правец», «Правец 8Д» — это НЕ клон Apple. В данном случае прототипом послужил компьютер Oric Atmos.
Пример интересный, но для собеседования этот вопрос не подходит.
Допустим, кандидат не знает ответ на вопрос. Значит ли это что он плохой .net-программист? нет, не значит, ровно как и не значит что плохой. Если он знает ответ на вопрос (думаю что это меньше 0,5% кандидатов), то скорее всего, он либо очень глубоко знает именно этот топик, либо (скорее всего) увидел пример в инете.
У меня вопрос по поводу фотографий. Если они вашего авторства или у вас есть доступ к правообладателю, то не могли бы вы какие-либо из них предоставить под свободной лицензией? В Википедии очень нехватает подобных иллюстраций.
Мне тоже стало оч интересно — то ли они усиленно делают вид что не знают про MAME/MESS и хотят чисто попилить 4 млн, то ли реально хотят достичь заявленной цели — тогда логичным шагом стало бы объявить кампанию по раздаче денег за весомый вклад в развитие этих эмуляторов.
Ещё один вариант развития событий — наберут команду и сделают совершенно новый проект, по какой-то причине сильно похожий на доработанный MAME/MESS, и быстренько спортируют под него существующие эмуляторы.
А у вас есть время делать рефакторинг кода, вы успеваете отрефакторить все необходимые места? Вы проводите перекрёстные ревью, чтобы убедиться что все такие места отрефакторены?
Если в данном конкретном месте проведена оптимизация и нет комментария об этом — вам не страшно что кто-то не поймёт что тут сделано и выкинет вашу работу?
Если стоит переменная, которая не используется но служит например для блокировок при одновременной работе — вы не считаете что нужно поставить комментарий?
Вы считаете что все 100% вашего кода понятны без комментариев? другие участники проекта тоже так считают?
Опять же, список подобных примеров и вопросов не исчерпан.
Я считаю, Фаулер ради популяризации рефакторинга дал программистом повод отлынивать от документирования кода.
> не каждому программисту дано изложить свою мысль четко
И это значит что не нужно и пытаться?
> в данном случае используются тесты
Тесты не являются комментариями тоже.
Их можно рассматривать как примеры использования кода (и то не всегда), но не как документацию, поскольку чтение комментариев заменяется на чтение кода плюс чтение кода тестов — больше работы, больше потраченного времени, результат не гарантирован.
Эту идею в явном виде я встречал в известной книге про рефакторинг.
В реальной жизни программисты активно ссылаются на это суждение для того чтобы не писать комментарии.
На деле программист часто ошибается в оценках понятности своего кода, откладывает рефакторинг «на потом», а комментарии принципиально не пишет.
Но даже предполагая, что вы делаете регулярный рефакторинг и ваш код в принципе понятен, его тем не менее легче будет читать по комментариям чем по самому коду. Также существуют случаи когда без комментария не обойтись — например, в данном месте поставлена оптимизация или обход проблемы, хак итп.
> Поэтому первое задание, которое я даю пришедшему работать в мою команду — Code Review. Если не забываю, то я предупреждаю, что приходится исправлять баги самостоятельно.
Code Review по сути своей не предполагает исправление багов тем кто их находит. Иначе это не ревью. Исправление багов в чужом ещё не освоенном коде — чревато новыми ошибками в уже протестированных местах.
> Я не комментирую код, я пишу его понятным.
Известное заблуждение. Отговорка чтобы не писать комментариев.
Вообще, текст пронизан идеей что вы сами решаете что вам делать и как. Обычно, чаще всего, это не так. Времени всегда не хватает. Начальство старается влезть в работу и порезать «лишнее». Программисты занимаются тем что им интересно а не тем что нужно.
В первой части подкаста, где Александр отвечал на вопросы — почему-то ощущение натянутого общения и чтения по бумажке.
Из приглашённых гостей хотел бы услышать Ромуальда Здебского.
Посмотрите на стиль оформления дискуссий во французской википедии: fr.wikipedia.org/wiki/Discussion_Portail:Architecture_et_Urbanisme
— тоже можно сделать с помощью стилей.
Что касается проблемы отрыва образования от реальности — по-идее, она должна решаться тем что называется «производственная практика». Другое дело, что у нас сейчас это чаще всего чисто ради галочки.
На самом деле у статьи есть ещё большой рекламный слой — собственно то ради чего она и написана :)
www.old-computers.com/museum/computer.asp?c=956
В отличие от остальных 8-разрядных компьютеров «Правец», «Правец 8Д» — это НЕ клон Apple. В данном случае прототипом послужил компьютер Oric Atmos.
www.pravetz.info/en/pravetz-8d.html
Допустим, кандидат не знает ответ на вопрос. Значит ли это что он плохой .net-программист? нет, не значит, ровно как и не значит что плохой. Если он знает ответ на вопрос (думаю что это меньше 0,5% кандидатов), то скорее всего, он либо очень глубоко знает именно этот топик, либо (скорее всего) увидел пример в инете.
users.livejournal.com/_adept_/93301.html
88% получается только если убрать воздержавшихся, что ИМХО не совсем корректно.
Ну а собственно причины изменения изложены здесь:
meta.wikimedia.org/wiki/Licensing_update/Questions_and_Answers/ru
Если кратко, то во времена создания Википедии, CC-BY-SA ещё не придумали, и сейчас на неё переходят чтобы преодолеть ограничения GFDL.
Ещё один вариант развития событий — наберут команду и сделают совершенно новый проект, по какой-то причине сильно похожий на доработанный MAME/MESS, и быстренько спортируют под него существующие эмуляторы.
Если в данном конкретном месте проведена оптимизация и нет комментария об этом — вам не страшно что кто-то не поймёт что тут сделано и выкинет вашу работу?
Если стоит переменная, которая не используется но служит например для блокировок при одновременной работе — вы не считаете что нужно поставить комментарий?
Вы считаете что все 100% вашего кода понятны без комментариев? другие участники проекта тоже так считают?
Опять же, список подобных примеров и вопросов не исчерпан.
Я считаю, Фаулер ради популяризации рефакторинга дал программистом повод отлынивать от документирования кода.
И это значит что не нужно и пытаться?
> в данном случае используются тесты
Тесты не являются комментариями тоже.
Их можно рассматривать как примеры использования кода (и то не всегда), но не как документацию, поскольку чтение комментариев заменяется на чтение кода плюс чтение кода тестов — больше работы, больше потраченного времени, результат не гарантирован.
В реальной жизни программисты активно ссылаются на это суждение для того чтобы не писать комментарии.
На деле программист часто ошибается в оценках понятности своего кода, откладывает рефакторинг «на потом», а комментарии принципиально не пишет.
Но даже предполагая, что вы делаете регулярный рефакторинг и ваш код в принципе понятен, его тем не менее легче будет читать по комментариям чем по самому коду. Также существуют случаи когда без комментария не обойтись — например, в данном месте поставлена оптимизация или обход проблемы, хак итп.
> Поэтому первое задание, которое я даю пришедшему работать в мою команду — Code Review. Если не забываю, то я предупреждаю, что приходится исправлять баги самостоятельно.
Code Review по сути своей не предполагает исправление багов тем кто их находит. Иначе это не ревью. Исправление багов в чужом ещё не освоенном коде — чревато новыми ошибками в уже протестированных местах.
> Я не комментирую код, я пишу его понятным.
Известное заблуждение. Отговорка чтобы не писать комментариев.
Вообще, текст пронизан идеей что вы сами решаете что вам делать и как. Обычно, чаще всего, это не так. Времени всегда не хватает. Начальство старается влезть в работу и порезать «лишнее». Программисты занимаются тем что им интересно а не тем что нужно.
Из приглашённых гостей хотел бы услышать Ромуальда Здебского.
fr.wikipedia.org/wiki/Discussion_Portail:Architecture_et_Urbanisme
— тоже можно сделать с помощью стилей.