Вы уже таки прочитали главу Мартина про комментарии? Мне уже начинает надоедать ее пересказывать.
Да. На С.79 прочел, что комментарии — неизбежное зло. И далее, что совсем без них не обойтись. Дальше предлагаются примеры типовых случаев хороших и плохих комментариев. Формулируются правила, нпр.:
Короткие функции не нуждаются в долгих описаниях.
В такой осторожной формулировке с этим правилом мало кто не согласится. Тем более, что через несколько страниц (С.100) автор приводит исключение из этого правила: тело функции determineIterationLimit содержит всего две строки кода и целых три строки необходимых, по мнению автора, комментариев. Хорошо, интересно и убедительно написано. ИМХО нужно писать полезные комментарии и не писать вредные. Ok.
Однако факт, что не так много кукуевских жителей могут похвастать работой на известные зарубежные фирмы. Тут целый ряд факторов: платить можно сильно меньше, но средний житель Кукуева, как правило, хуже знает английский, чем средний житель Лондона и даже Бомбея. Если житель Кукуева украдет код и продаст его конкуренту или просто выложит в сеть, наказать его оп суду м.б. труднее чем жителя Бомбея или Лондона. Ну и образование обычно у жителя Лондона систематичнее, а у жителя Кукуева могут быть серьезные пробелы. Проблемы со связью с Лондоном и с Кукуевом и т.д.
Если человек не может хорошо работать (отсутствие знаний, быстрая утомляемость и т.д.), то как его не заставляй — ничего хорошего не получится. Если человек не хочет хорошо работать, а хочет производить только видимость работы, то ему проще дурить начальство не удаленно. Если начальник пытается управлять такими людьми, то перекладывает на себя часть ответственности за отсутствие нужного результата: «Что вы мне сказали, то я и сделал, вы — начальник, я — дурак». С этой точки зрения удаленка несет меньшие риски. Что касается кнута и пряника, то и в удаленном и в не удаленном случае принцип один: если плохо работаешь — будешь получать меньше денег, до полного отказа от твоих услуг, а если хорошо, то м.б. будешь получать больше…
Интересный вопрос о соотношении предложенных критериев с подходами software metric. Кроме примитивного подсчета числа строк были предложены и очень сложные.
Т.е. все, что неочевидно — то сложно? Пожалуй, с этим можно согласиться. Но тогда получаем, что в реальности простых задач нет, а бывают только простые участки кода сложных задач.
один и тот же алгоритм можно очень по разному написать
Вы про описание алгоритма или про его реализацию на конкретном языке программирования? В литературе по CS (и в той же википедии) алгоритмы часто описывают на естественном языке (русский, английский и т.д. + мат. формулы) или на псевдокоде. Еще один способ — это блок-схемы. Конечно же, и описание и реализация могут быть сделаны очень по разному.
У примеров есть неприятное свойство: в формате обсуждения (вроде этого) нет возможности привести достаточно сложный пример, т.к. он был бы слишком объемным. Поэтому приходится приводить простые примеры. Вы используете это свойство и еще более упрощаете ситуацию, что со стороны, если не вдумываться, выглядит весомым доводом, хотя на деле просто уловка спора. Повторю, что даже в моем простом примере возможны неочевидные случаи:
м.б. Y не равно нулю по условию подзадачи
Если посмотреть достаточно большой нетривиальный код, то там таких случаев м.б. довольно много при их большом разнообразии. Если метод реализует «в лоб» широко известный алгоритм, то достаточно комментария типа "// Алгоритм Флойда — Уоршелла". Но если в коде используется какие-то свойства матрицы расстояний, специфичные для данной задачи, то эти места кода нуждаются в комментариях. Часто бывает, что применяется оригинальный алгоритм, сделанный специально под данную задачу. Тут одних комментариев может оказаться мало и нужны будут доказательство корректности алгоритма и оценка теоретической сложности. Это уже отдельная документация, сопровождающая код. А в комментариях должна быть ссылка на соответствующий файл документации. Если алгоритм эвристический, то это нужно написать в комментарии и т.д. Отсутствие подобных пояснений превращает код в ребус и не способствует простоте. ИМХО это очевидные вещи, и мне немного странно, что мы о них спорим.
Хорошие девушки = они понимали меня, и я понимал их. Что тут непонятного? У многих не с первой девушкой складываются длительные отношения, но одно дело, когда с двух сторон понимают, что ошиблись, но при этом рады тому, что было, а другое дело, когда наоборот.
Тут, как и во многом, нет универсальных рецептов. Но возможны оптимальные близкие к оптимальным решения, компромиссы. Присутствует игровой момент. В конце СССР работал в одном очень большом образовательном учреждении. У меня было два выходных, а у студентов один, но я был старший инженер, а не препод. Однако начальник часто просил выйти в субботу. За это давал отгул. В то время увлекался сплавом по горным рекам и стал копить отгулы на майские праздники. Накопил столько, что начальник пришел в ужас. Был конфликт, но ему пришлось отдать мне эти отгулы, и у меня состоялся отличный поход.
мне лично так вот годами деградировать было бы невыносимо скучно
И мне скучно — поэтому не «сработался» в некоторых конторах: деградирующие начальники и их подчиненные воспринимают иное, как личную угрозу. Что не странно.
Это если сам препод/собеседующий либо не разбирается в предмете, либо ему всё пофиг.
Препод может и разбирается, но формализм экзамена сильно помогает хитрому студенту. При этом, если препод захочет — любого провалит. ИМХО курсовая гораздо полезнее для оценки знаний студента. Спросить по исходному коду: зачем так в этом месте сделал и для чего это нужно — сразу видно: сам студент кодил или в сетке не думая скачал или у фрилансера заказал.
И у меня выходил в стену, но отражался. М.б. от кулера зависит :)
Затем уже в ИКЕА приобрел стол
Я поступил иначе: поехал на строительный рынок с чертежами. Мне там фанеры нарезали. Там же купил кронштейны, саморезы, лак. (Дрель уже была.) Отлакировал, укрепил на стене. Доволен. ИМХО: толстая ок. 15 мм фанера лучше ДСП — можно в любое место крюк ввинтить, чтобы мешающий кабель подвязать, дополнительные розетки укрепить и т.д.
По моему опыту удаленной работы для очень маленькой (2-3 человека) софтовой фирмы (программы для обучения студентов программированию — вводный курс) США. Достаточно успешно выполнить один проект, и будет доверие. (Когда 2-3 работника — приходится доверять каждому :)
Тот квант полезной работы, который за целый день выполняет хорошо укоренённый офисный сотрудник в энтерпрайзе, удалённый работник скорее всего сможет выполнить за полчаса-час. Иногда до работы вообще дело не доходит. Приходишь утром… Пьёшь кофе, читаешь хабр… Опа! Внезапно, уже обед…
Верно. Такое бывает. Чаще в очень больших коллективах. При долговременных проектах, исследованиях. Но бывает, что рядом из другого отдела, лаборатории крутятся, как белки в колесе.
Да! И сколько тратишь времени, объясняя почему опоздал. А потом надо выдохнуть, собраться, настроиться, сконцентрироваться. Опытные работники не показывают, что они выдыхают — сидят за компом и что-то набирают, а когда выдохнут, все «набранное» идет в корзину. А неопытные пытаются сразу включиться — не помню где читал, что 50% всех багов делают в первые пол-часа начала рабочего дня.
Нормальное место. +1
И я системный блок опускал, а теперь держу на столе рядом — надоело лазить под стол, и не нравится что по ногам теплым воздухом дует. Особенно поздней весной и ранней осенью, когда отопление уже не нужно, а кондиционер включать еще рано. Не рассмотрел: 1 системный блок? У меня пара. предпочитаю использовать Mobile Rack: 4 винта — еще 1 довод для настольного размещения системного блока. Друг7ой довод — USB. А вот мониторов у меня всего два на двух рабочих местах. И еще один системный блок в углу стоит: неподключенный резерв. Но это все зависит от задач.
Конечно, нет — у меня всегда были хорошие девушки. И мы все — я, мой друг и она учились в одном классе, т.о. она быстро убедилась, что я ее не обманывал. У него оказался перелом, и мы с ней его навещали.
У меня, когда учился в школе, был случай: договорились компанией в кино пойти, билеты заранее купили. Нам с моим другом на автобусе нужно было ехать, прошел дождь, и мы перепрыгивали лужи, друг подвернул ногу так, что наступить не мог. Пока его до дома довел — он прыгал на одной ноге, держась за меня — сеанс в кино уже начался, а там была моя девушка, которой я обещал… И что мне было делать, сказать другу: «ковыляй как можешь домой, а я поеду — я же обещал»? Другой случай был уже на работе: в ночь с пятницы на субботу там в здании небольшой пожар случился. Рано утром позвонили, что надо спасать в нашем офисе то, что еще от воды недоразмокло. Все приехали, до кого дозвонились. А я своей семье обещал, что проведем день вместе. Нужно было сказать сотрудникам: «обходитесь без меня»?
В такой осторожной формулировке с этим правилом мало кто не согласится. Тем более, что через несколько страниц (С.100) автор приводит исключение из этого правила: тело функции determineIterationLimit содержит всего две строки кода и целых три строки необходимых, по мнению автора, комментариев. Хорошо, интересно и убедительно написано. ИМХО нужно писать полезные комментарии и не писать вредные. Ok.
Если посмотреть достаточно большой нетривиальный код, то там таких случаев м.б. довольно много при их большом разнообразии. Если метод реализует «в лоб» широко известный алгоритм, то достаточно комментария типа "// Алгоритм Флойда — Уоршелла". Но если в коде используется какие-то свойства матрицы расстояний, специфичные для данной задачи, то эти места кода нуждаются в комментариях. Часто бывает, что применяется оригинальный алгоритм, сделанный специально под данную задачу. Тут одних комментариев может оказаться мало и нужны будут доказательство корректности алгоритма и оценка теоретической сложности. Это уже отдельная документация, сопровождающая код. А в комментариях должна быть ссылка на соответствующий файл документации. Если алгоритм эвристический, то это нужно написать в комментарии и т.д. Отсутствие подобных пояснений превращает код в ребус и не способствует простоте. ИМХО это очевидные вещи, и мне немного странно, что мы о них спорим.
оптимальныеблизкие к оптимальным решения, компромиссы. Присутствует игровой момент. В конце СССР работал в одном очень большом образовательном учреждении. У меня было два выходных, а у студентов один, но я был старший инженер, а не препод. Однако начальник часто просил выйти в субботу. За это давал отгул. В то время увлекался сплавом по горным рекам и стал копить отгулы на майские праздники. Накопил столько, что начальник пришел в ужас. Был конфликт, но ему пришлось отдать мне эти отгулы, и у меня состоялся отличный поход.Препод может и разбирается, но формализм экзамена сильно помогает хитрому студенту. При этом, если препод захочет — любого провалит. ИМХО курсовая гораздо полезнее для оценки знаний студента. Спросить по исходному коду: зачем так в этом месте сделал и для чего это нужно — сразу видно: сам студент кодил или в сетке не думая скачал или у фрилансера заказал.
Я поступил иначе: поехал на строительный рынок с чертежами. Мне там фанеры нарезали. Там же купил кронштейны, саморезы, лак. (Дрель уже была.) Отлакировал, укрепил на стене. Доволен. ИМХО: толстая ок. 15 мм фанера лучше ДСП — можно в любое место крюк ввинтить, чтобы мешающий кабель подвязать, дополнительные розетки укрепить и т.д.
А вот здесь — не всегда так. Многие из деградонтов ухитряются не попадать под сокращение.
Собеседование — как экзамен. Есть студенты, которые обладая минимумом знаний, ухитряются сдавать лучше среднего студента…
И я системный блок опускал, а теперь держу на столе рядом — надоело лазить под стол, и не нравится что по ногам теплым воздухом дует. Особенно поздней весной и ранней осенью, когда отопление уже не нужно, а кондиционер включать еще рано. Не рассмотрел: 1 системный блок? У меня пара. предпочитаю использовать Mobile Rack: 4 винта — еще 1 довод для настольного размещения системного блока. Друг7ой довод — USB. А вот мониторов у меня всего два на двух рабочих местах. И еще один системный блок в углу стоит: неподключенный резерв. Но это все зависит от задач.