Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте
Время на прочтение
4 мин
Количество просмотров 80K
…, даже если проект не планируется развивать и вы не собираетесь делиться исходными кодами, потому что через 20 лет какой-нибудь маньяк будет изучать и дорабатывать машинный код вашего продукта, и он может захотеть вас найти.
Вообще я достаточно редко играю в компьютерные игры. Бывало, не играл по несколько лет подряд. Но иногда во мне просыпается маленький реверс-инженер, который мотивирует меня забраться в машинный код какой-нибудь любимой игрушки из прошлого. В последний год я занимался доработкой Need For Speed III: Hot Pursuit (1998 года). Это моя любимая игра в жанре, но теперь я, к своему сожалению, знаю о том, насколько отвратительно она написана. Большое количество маленьких багов в самых неожиданных местах — прямое следствие низкого качества кода.
Насколько всё плохо?
В исполняемом файле огромное количество кода, который остался в наследство от предыдущих частей игры и не используется, то есть устаревший код не удалялся разработчиками, причём мне встречались случаи, когда какой-то устаревший код вызывался, но результаты его работы игнорировались, потому что обновлённому коду они уже были не нужны. В игре всюду используются статичные массивы фиксированного размера, во многих случаях отсутствуют проверки выхода за пределы массива, что приводит к падениям, когда какого-то зарезервированного объёма памяти не хватает. В игре используется большое количество грязных хаков. Например, функция гонки по отражённому варианту трассы реализована не отражением модели трассы при её загрузке, а переворотом каждого кадра при рендеринге, с инверсией кнопок «лево» и «право» и ряда аналогичных подмен там, где разработчики не забыли добавить соответствующий код. Из-за этого надписи на машинах (например, копов) отражены, а во время гонок копы путают «право» и «лево» при переговорах по рации. Есть и ошибки, явно связанные с использованием магических чисел в коде вместо именованных констант, когда значение константы в процессе разработки было изменено, но остался код, который использует старое значение и работает неправильно. Но один случай оказался забавным настолько, что мне захотелось поделиться им в рамках небольшой заметки.
Сколько ошибок может быть в 4 вариантах одного и того же кода?
В игре присутствовал один незначительный баг, связанный с отступами в выпадающих меню. Например, если был выбран режим «Hot Pursuit», левый отступ всех верхних выпадающих списков значительно увеличивался без явной на то необходимости.
Я предположил, что это связано с ошибкой в коде, который добавляет пространство для вывода иконок прохождения в выпадающем списке трасс, которые как раз и должны отображаться только в режиме «Hot Pursuit».
Обычные выпадающие списки тоже имели проблемы с отступами в зависимости от режима, но не в такой явной форме. Поскольку я как раз копался рядом с соответствующим кодом, решил заодно исправить и это странное поведение.
Тут стоит отметить, что в коде игры не встречаются следы вещей вроде наследования, так что скорее всего она писалась на чистом C. В игре реализован код, который читает списки элементов меню и их свойства из внешних текстовых файлов, но разработчики часто ленились добавлять поддержку какого-то нового свойства, и писали дополнительный код, опираясь просто на имя элемента. Например, код вывода выпадающих списков сам проверяет название текущего элемента и какие-то другие переменные, и в зависимости от этого может применять какую-то дополнительную логику.
Так оказалось и здесь. Поскольку в меню используется два разных типа выпадающих списков (обычный и верхний), весь код работы с ними был целиком продублирован дважды. Помимо этого оказалось, что левый отступ выбирается разными фрагментами кода при вычислении левой и правой границы выпадающего списка. Итого — по идее у нас должно быть 4 копии одного и того же кода. Как бы не так!
Вариант 1 (при вычислении отступа левой границы обычной выпадашки):
На C это выглядело примерно так:
dw_padding = (stricmp(str_element_name, "tracks") == 0 && dw_cfg_race_type == 3) ? 35 : 15;
Вариант 2 (при вычислении отступа правой границы обычной выпадашки):
На C это выглядело примерно так:
dw_padding = (stricmp(str_element_name, "tracks") == 0 || stricmp(str_element_name, "rectrk") == 0) ? 35 : 15;
Варианты 3 и 4 (при вычислении отступа левой и правой границ выпадашки под заголовком):
На C это выглядело примерно так:
dw_padding = (dw_cfg_race_type == 3) ? 35 : 15;
Все варианты вместе (для наглядности):
dw_padding = (stricmp(str_element_name, "tracks") == 0 && dw_cfg_race_type == 3) ? 35 : 15;
dw_padding = (stricmp(str_element_name, "tracks") == 0 || stricmp(str_element_name, "rectrk") == 0) ? 35 : 15;
dw_padding = (dw_cfg_race_type == 3) ? 35 : 15;
Какой же вариант правильный? Ответ: ни один! Только если мы объединим все проверки вместе, мы можем получить единственно верный вариант кода, и выглядел бы он примерно так:
dw_padding = (dw_cfg_race_type == 3 && (stricmp(str_element_name, "tracks") == 0 || stricmp(str_element_name, "rectrk") == 0)) ? 35 : 15;
Итого у нас 4 варианта одного и того же кода, при этом в разных вариантах допущено 3 разные ошибки! Просто уникальный случай и отличная демонстрация того, почему копипаста — это плохая идея.
Как это было исправлено?
О том, как вносятся изменения в машинный код, я писал ранее. Для исправления проблемы я написал одну функцию:
Все приведённые выше фрагменты кода были заменены на вызов этой функции. Теперь отступы в списках выбираются правильно 
И это лишь одно из более чем 200 изменений, которые были сделаны в патче. Описанное изменение на самом деле одно из самых маленьких, но зато сама ошибка, на мой взгляд, была интересной (как демонстрация вреда от соответствующего антипаттерна).
Выводы?
А теперь подумайте. Если здесь нашёлся самозванец, который взялся исправлять без спроса чужие баги в программе без исходных кодов, может найтись и тот, кто в итоге будет настолько зол, что у него появится желание отыскать разработчика или его родственников. А оно вам надо? Пишите качественный код
Не зависимо от экономических подъемов и спадов хороших программистов всегда не хватает, а жизнь слишком коротка, чтобы тратить ее на работу в отсталом учреждении при наличии множества лучших вариантов.
Программисты склонны рассматривать менеджеров как низшую ступень технической эволюции, где-то между одноклеточными организмами и мамонтами, вымершими в ледниковый период.
Помните! Тестирование может указать только на наличие, но не отсутствие ошибок.
Похвалите себя за чтение этой книги. За это время вы продвинулись вперед гораздо дальше, чем большинство ваших коллег, потому что объем этой книги превышает годичный объем чтения большинства программистов.
Новые инструменты полезны, но они не заменяют ясность мышления.
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
Абстракция — один из главных способов борьбы со сложностью реального мира.
«Когда вместе собираются критики, они говорят о Теме, Композиции и Идее. Когда вместе собираются художники, они говорят о том, где купить дешёвый скипидар».
Пабло Пикассо.
Если требования [к проекту] нестабильны, рассматривайте работу над ними как отдельный проект.
Джон Бентли говорит, что программист должен быть способен сесть у камина со стаканом бренди, хорошей сигарой, охотничьей собакой у ног и «сформулировать программу» подобно тому, как писатели создают романы.
Один из пионеров информатики Эдсгер Дейкстра обращал внимание на то, что компьютерные технологии — единственная отрасль, заставляющая человеческий разум охватывать диапазон, простирающийся от отдельных битов до нескольких сотен мегабайт информации, что соответствует отношению 1 к 109, или разнице в девять порядков (Dijkstra, 1989). Такое гигантское отношение просто ошеломляет. Дейкстра выразил это так: «По сравнению с числом семантических уровней средняя математическая теория кажется почти плоской. Создавая потребность в глубоких концептуальных иерархиях, компьютерные технологии бросают нам абсолютно новый интеллектуальный вызов, не имеющий прецедентов в истории». Разумеется, за прошедшее с 1989 г. время сложность ПО только выросла, и сегодня отношение Дейкстры вполне может характеризоваться 15 порядками.
«Планируйте выбросить первый экземпляр программы: вам в любом случае придется это сделать »
Фред Вруне
«Если вы планируете выбросить первый экземпляр программы, то выбросите и второй»
Крейг 3еруни
При инкрементной разработке вы сначала создаете самую простую версию системы, которую можно было бы запустить. Она может не принимать реальных данных, может не выполнять над ними реальных действий, может не генерировать реальные результаты — она должна быть просто скелетом, достаточно крепким,чтобы поддерживать реальную систему по мере ее разработки. Она может вызывать поддельные классы для каждой из определенных вами основных функций. Такая система похожа на песчинку, с которой начинается образование.
За ошибку, допущенную при создании простого объекта, приходится расплачиваться лишь потраченным временем и, возможно, некоторым разочарованием
Неудачное определение проблемы грозит пустой тратой времени на решение не той проблемы. Разумеется, нужную проблему вы при этом тоже не решите.
Думая о новой функции, клиенты приходят в возбуждение. Кровь у них разжижается, переполняет продолговатый мозг, и они впадают в эйфорию, забывая обо всех собраниях, посвященных обсуждению требований, о церемонии подписания и всех документах. Угомонить таких одурманенных новыми функциями людей проще всего, заявив: «Ого, это действительно прекрасная идея! Но ее нет в документе требований, поэтому я должен пересмотреть график работы и смету, чтобы вы могли решить, хотите ли вы реализовать это прямо сейчас или позднее». Слова «график» и «смета» отрезвляют куда лучше, чем кофе и холодный душ, и многие требования быстро превращаются в пожелания.
В свое время Данте отвел нижний круг ада самому Сатане.
Но с тех пор кое-что изменилось, и сейчас Сатана охотно делит нижний круг с программистами, не умеющими эффективно отлаживать программы.
# 1. Создаем список
>>> lst = [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
# 2. Добавляем элемент с типом str в конец списка
>>> lst.append('Строка')
#[1, 1, 1, 1, 1, 1, 1, 1, 1, 'Строка']
# 3. Вставляем элемент со значением 189 на место с индексом 4
>>> lst[4] = 189
# Результат: [1, 1, 1, 1, 189, 1, 1, 1, 1, 1, 'Строка']
# 4. Добавляем вложенный список ['a', 'b', 'a', 'hello']
lst.append(['a', 'b', 'a', 'hello'])
# Результат: [1, 1, 1, 1, 189, 1, 1, 1, 1, 1, 'Строка', ['a', 'b', 'a', 'hello']]
# 5. Вставляем кортеж со значением (1, 6, 89) на место с индексом -3 (3-й элемент с конца списка)
>>> lst[-3] = (1, 6, 89)
# Результат: [1, 1, 1, 1, 189, 1, 1, 1, 1, (1, 6, 89), 'Строка', ['a', 'b', 'a', 'hello']]
# 6. Получаем значение элемента с индексом 0
>>> lst[0]
1
# Получаем значение элемента с индексом -1(последний элемент списка)
>>> lst[-1]
['a', 'b', 'a', 'hello']
# 7. Удаляем элемент со значением 189
>>> lst.remove(189)
# Результат: [1, 1, 1, 1, 1, 1, 1, 1, (1, 6, 89), 'Строка', ['a', 'b', 'a', 'hello']]
# 8. Считаем количество элементов в списке со значением 1
>>> lst.count(1)
8
Созерцание кода
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете».
Стив Макконнелл «Совершенный код»
Re: Созерцание кода
> «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете». > xakep.ru
Ну и кто на ЛОРе сколько мест проживания быдлокодеров знает?
Re: Созерцание кода
>«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете».
Т.е. как бы намекают, что reiser4 пилить не стоит, ибо Рейзер рано или поздно выйдет?
Re: Созерцание кода
Сходи по ссылке и узнаешь 😉
Re: Созерцание кода
>На этом принципе построено всё программное обеспечение от Apple. На этом принципе должна строиться информационная безопасность в нашем веке.
все финиш.
на этом месте я чуть не упал
Re: Созерцание кода
я уже почти обрадовался, что сракере раз в сто лет появилась более-менее нормальная статья
Re: Созерцание кода
Так а что, до строчек про Эппл статья была ненормальная? 😉
Re: Созерцание кода
/me очень хочет узнать, где живут «разработчики» samba ;-E
Re: Созерцание кода
> Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете».
мы ж сопьемся с ним, лучше не буду.
Re: Созерцание кода
ссылка не открывается, но неважно.
Вот оно, лицо кризиса-то. отечественные журналы похоже сократили всех кто кто мог хоть что-то написать сам и стали перепечатывать рваные импортные баяны.
> «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете».
а если потом психопата сопровождающего код не появится, а вместо него нарисуются 1. психопат — начальник, который будет иметь к вам разговор за то что из-за затянутого проекта упустили крупного клиента? 2. психопатка-жена, которая будет иметь к вам очень много разговоров за то что вы без конца торчите на работе и ей внимания не уделяете? а толку от вашего торчания все равно нет потому что всвязи с кризисом всех сократили?
эти темы в оригинальной статье не раскрыты. короче пионерский максимализм как обычно.
Re: Созерцание кода
> а если потом психопата сопровождающего код не появится, а вместо него нарисуются 1. психопат — начальник, который будет иметь к вам разговор за то что из-за затянутого проекта упустили крупного клиента? 2. психопатка-жена, которая будет иметь к вам очень много разговоров за то что вы без конца торчите на работе и ей внимания не уделяете? а толку от вашего торчания все равно нет потому что всвязи с кризисом всех сократили?
> эти темы в оригинальной статье не раскрыты. короче пионерский максимализм как обычно.
дети, есть такие слово — профессионал. судя по перечисленному вы я так понимаю с ним ещё не знакомы.
Re: Созерцание кода
>»Одно время в Индии существовала практика оценки производительности труда программиста на основе количества написанного кода.»
Мда, вот откуда все пошло
Re: Созерцание кода
Re: Созерцание кода
Да, это обращение о многом говорит.
> есть такие слово — профессионал. судя по перечисленному вы я так понимаю с ним ещё не знакомы.
Профессионал — это человек, имеющий профессиональную подготовку, и/или получающий деньги за работу по некоторой профессии. _И всё_. Качество работы, мастерство и прочее — в определение не входит.
А статья — набор баянов.
Re: Созерцание кода
> Профессионал — это человек, имеющий профессиональную подготовку, и/или получающий деньги за работу по некоторой профессии. _И всё_. Качество работы, мастерство и прочее — в определение не входит.
мне почему то кажется, что вы прекрасно поняли, что именно я имею ввиду. и отсылка к формальным определениям явно не к месту. не умеешь планировать проектное время — не берись.
> А статья — набор баянов.
статью я читать не стал, хватило описания 🙂
Re: Созерцание кода
> Профессионал — это человек, имеющий профессиональную подготовку, и/или получающий деньги за работу по некоторой профессии. _И всё_. Качество работы, мастерство и прочее — в определение не входит.
TDWTF тому подтверждение.
Re: Созерцание кода
> мне почему то кажется, что вы прекрасно поняли, что именно я имею ввиду
Понял, конечно. Но мне конкретная формулировка («дети», «профессионалы») слух царапает.
Re: Созерцание кода
> Понял, конечно. Но мне конкретная формулировка («дети», «профессионалы») слух царапает.
«дети» — это лишь асимметричный ответ. ответ на штатные жалобы о жизни обобщённого лентяя классикус, который не в состоянии наконец то найти в себе силу воли взять себя за яйца и начать делать так, как нужно а не так, как получается. подобные жалобы — это подпись человека под собственной несостоятельностью. надпись «лузер» большими красными буквами. и, что самое досадное, сделанная рукой автора. кому как, но по мне это выглядит чрезвычайно унизительно и царапает слух ни чуть не меньше.
а вот «профессионал» — по мне так это как раз в кассу. это человек, который де факто способен взяться за ту или иную работу и качественно её сделать. замечу, качественно по всем пунктам включая реализацию, сроки, внедрение и тд и тп. и «обучен» — это IMHO лишь часть того, из чего состоит профи. причём не всегда образование — это самая значительная часть.
Re: Созерцание кода
> «дети» — это лишь асимметричный ответ. ответ на штатные жалобы о жизни обобщённого лентяя классикус, который не в состоянии наконец то найти в себе силу воли взять себя за яйца и начать делать так, как нужно а не так, как получается. подобные жалобы — это подпись человека под собственной несостоятельностью. надпись «лузер» большими красными буквами. и, что самое досадное, сделанная рукой автора. кому как, но по мне это выглядит чрезвычайно унизительно и царапает слух ни чуть не меньше.
если как то суммировать — никогда не жалуйтесь что бы не произошло но молча, стиснув зубы деритесь. последовательно и жёстко. и в первую очередь с самим собой. результаты окупятся с лихвой.
Re: Созерцание кода
>Так а что, до строчек про Эппл статья была ненормальная? 😉
наоборот, ее было интересно читать, но в самом конце такой жесткий прикол
Re: Созерцание кода
если же по теме, то, комментируя лишь приведённое высказывание могу с ним только согласится. делать заведомо бажный продукт — это ОЧЕНЬ дорого. чрезвычайно. это существенно дороже, нежели потратить дополнительные [в пределе все доступные] усилия к тому, чтобы продукт вышедший из под вашего пера работал на все сто. просто потому, что в уже ближайшем будущем поддержка и сопровождение кривого продукта превратится в полнейший кошмар, который перекроет любые бенефиты, которые были получены от желания сдать чуть-чуть побыстрее или немного сэкономить на том на сём или вообще на всём. btw, одно из качеств, которое обязательно при причислении разработчика к лиге профи — это умение решать подобные проблемы. и оценка и планирование и организация работы и все-все-все.
Re: Созерцание кода
> подобные жалобы — это подпись человека под собственной несостоятельностью. надпись «лузер» большими красными буквами. и, что самое досадное, сделанная рукой автора. кому как, но по мне это выглядит чрезвычайно унизительно и царапает слух ни чуть не меньше.
> а вот «профессионал» — по мне так это как раз в кассу. это человек, который де факто способен взяться за ту или иную работу и качественно её сделать. замечу, качественно по всем пунктам включая реализацию, сроки, внедрение и тд и тп. и «обучен» — это IMHO лишь часть того, из чего состоит профи. причём не всегда образование — это самая значительная часть.
тОлсто. Все, начиная от Microsoft и кончая Debian’ом имеют проблемы со сроками релизов. Те, кто проблем не имеют, оказывается имеют линию вида «релиз раз в N месяцев, какие фичи успеют такие и будут».
Один товарищь klalafuda — д’артаньян, у которого и сроки и внедрение и код пышет врутренней красотой :-))
Re: Созерцание кода
> Один товарищь klalafuda — д’артаньян, у которого и сроки и внедрение и код пышет врутренней красотой :-))
btw если посмотреть внимательно, то можно увидеть, что я этого не утверждал. к сожалению, не могу себе этого позволить с полной уверенностью. но нужно стремиться.
Re: Созерцание кода
> если как то суммировать — никогда не жалуйтесь что бы не произошло но молча, стиснув зубы деритесь. последовательно и жёстко. и в первую очередь с самим собой. результаты окупятся с лихвой.
Если ты не в стартапе с долей будущей прибыли, такое геройство не очень оценят. пока ты возишься с проектом, другие возятся с офисной политикой.
klalafuda, для статистики — вы код пишете или менеджер?
Re: Созерцание кода
> тОлсто. Все, начиная от Microsoft и кончая Debian’ом имеют проблемы со сроками релизов. Те, кто проблем не имеют, оказывается имеют линию вида «релиз раз в N месяцев, какие фичи успеют такие и будут».
вы действительно работаете в одной из указанных компаний и можете поделиться соотв. личным опытом? если нет, тогда к чему они здесь? разговор не «за вообще в мире» но за Человека как личность. по крайней мере мне так кажется.
Re: Созерцание кода
> если же по теме, то, комментируя лишь приведённое высказывание могу с ним только согласится. делать заведомо бажный продукт — это ОЧЕНЬ дорого. чрезвычайно. это существенно дороже, нежели потратить дополнительные [в пределе все доступные] усилия к тому, чтобы продукт вышедший из под вашего пера работал на все сто.
Ыыыы! разница во времени релиза иногда покрывает все, увы.
> просто потому, что в уже ближайшем будущем поддержка и сопровождение кривого продукта превратится в полнейший кошмар, который перекроет любые бенефиты, которые были получены от желания сдать чуть-чуть побыстрее или немного сэкономить на том на сём или вообще на всём.
альтернатива — хороший продукт, прозябающий из за того что не успели к разделу рынки. Кошмара поддержки нет. да и самой поддержки особо нет — покупателей чуть-чуть.
Другой вектор — написали хорошее, работает, но НЕ ТО. продакт менеджмент слажал. Если бы вы им дали забыдлокоженную альфу, то что-то можно было бы изменить, а сейчас продукт уже готов и уже поздно.
>btw, одно из качеств, которое обязательно при причислении разработчика к лиге профи — это умение решать подобные проблемы. и оценка и планирование и организация работы и все-все-все.
скажем так, даже чемпион мира по боксу может получить п%%ы. Смотря где и на кого нарвешься.
я не отрицаю ценность имения плана и организации работ. Но жизнь богаче чем просто разработка сферической программы в вакууме, и ни всегда ортодоксальная стратегия поведения является оптимальной. Это справедливо и для вас лично и для вашей компании.
Re: Созерцание кода
> Если ты не в стартапе с долей будущей прибыли, такое геройство не очень оценят. пока ты возишься с проектом, другие возятся с офисной политикой.
я достаточно долго работал не в одном стартапе и имел счастье лицезреть во всей красе, к чему в конечном итоге может приводить политика «здесь и сейчас любой ценой». к сожалению, достаточно распространённая практика. большинство проектов в последствии было переписано с нуля один или более раз соотв. образом влияя на ценник, моральный дух команды и тд и тп.
ps: а пожелание — они IMHO более общее. независимо от.
> klalafuda, для статистики — вы код пишете или менеджер?
обычно я так или иначе занимаюсь любой активностью, которая требуется для поддержания проекта за который я отвечаю или может пойти ему на пользу. впрочем, по бОльшей части это все таки это разработка ПО. ручками, ручками.
Re: Созерцание кода
> я достаточно долго работал не в одном стартапе и имел счастье лицезреть во всей красе, к чему в конечном итоге может приводить политика «здесь и сейчас любой ценой». к сожалению, достаточно распространённая практика.
угу. а почему она столь распространена? все вокруг — лузиры и непрофессионалы?
Re: Созерцание кода
> > тОлсто. Все, начиная от Microsoft и кончая Debian’ом имеют проблемы со сроками релизов. Те, кто проблем не имеют, оказывается имеют линию вида «релиз раз в N месяцев, какие фичи успеют такие и будут».
> вы действительно работаете в одной из указанных компаний и можете поделиться соотв. личным опытом?
указана одна компания — Microsoft, и я там не работаю.
> если нет, тогда к чему они здесь? разговор не «за вообще в мире» но за Человека как личность. по крайней мере мне так кажется.
для опровержения вашего тезиса о том что «все у кого помойка в коде или экстрим со сроками — непрофессионалы». Вот вам Microsoft. Они вообще хоть Папу Римского могут нанять. Если даже там — непрофессионалы, то где ж нам, грешным, профессионалов-то взять?
Re: Созерцание кода
Подолью ка я маслица:
Не имеет никакого значения что ваш код уродлив и содержит много ошибок, и никому он не нравится. Джоэл Сполски, Огонь и движение.
Re: Созерцание кода
> угу. а почему она столь распространена? все вокруг — лузиры и непрофессионалы?
непрофессионалы? да, именно так. чрезвычайно распространённая практика. а лузеры — это уж как монетка упадёт. сможет такой коллектив сорвать банк или нет. вовремя проделать работу над ошибками, учесть полученный опыт и реализовать его на практике. некоторым везёт и после N-й итерации что то получается, некоторым — нет. да и что собственно в этом удивительного? профи не рождаются но становятся путём дооолгой и целенаправленной работы. по моему, не так много людей, которые согласятся себя мучить подобным образом.
ps: да, и я там был мед-пиво пил. и, смотря сегодня на пару независимыз систем, которые активно используется по всей РФ и приносит кому-то фантастическое с точки зрения разработчика бабло, я диву даюсь, какая же все таки бывает терпеливой эта монетка. и с какой глубокой жопы всё когда то начиналось. но ведь выжили же как то. может быть потому, что никогда не жаловались но просто тупо работали.
Re: Созерцание кода
> для опровержения вашего тезиса о том что «все у кого помойка в коде или экстрим со сроками — непрофессионалы». Вот вам Microsoft. Они вообще хоть Папу Римского могут нанять.
а что собственно не так с Microsoft? ругать их можно по разному [и бывает за что], но, боюсь, называть их лузеарми может лишь действительно лузер. учитывая при этом, что продуктов у них — как грязи, и апеллировать не к конкретному продукту но к «обобщённому микрософту» — это мягко говоря бессмысленно. с таким же успехом можно обсуждать «всех OSS разработчиков».
> Если даже там — непрофессионалы, то где ж нам, грешным, профессионалов-то взять?
в зеркале? если же что то в увиденном не устраивает [а оно всегда так] — это лишь повод для дальнейшей доработки но и только.
Re: Созерцание кода
>сократили всех кто кто мог хоть что-то написать
В нашей несчастной стране всё меньше людей, кто в состоянии внятно выражать мысли/идеи/предложения (при условии, что они есть, разумеется)
Re: Созерцание кода
А теперь в школах отменили сочинения и эссе. Следующие поколения вообще ясно выражать свои мысли будут не в состоянии, даже если мыслишки коротенькие. Максимум, что им останется — SMS-язык.
Re: Созерцание кода
> отечественные журналы похоже сократили всех кто кто мог хоть что-то написать сам
Ксакеп никогда и не публиковал ничего стоящего. Кризис не виноват. Хуже не стало.
#статьи
- 1 июл 2021
-
16
«Это вообще не смешно! Это больно!» Ловите новую десятку айтишных шуток
Продолжаем переводить с программерского языка на человеческий.
Полина Суворова для Skillbox
Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.
В предыдущей подборке мы больше шутилио программировании, технологиях и языках, но почти не затронули людей, которые всё это применяют. Исправим это упущение.
Про них всякое говорят:
Что такое программист? Это автомат для превращения кофе в код.
(Источник / перевод Skillbox Media)
Некоторые до сих пор думают, что программисты и вообще все айтишники — это такие лохматые существа с вечно красными глазами, в стоптанных тапках и вытянутых свитерах. Мол, они мало спят (потому что всё время работают) и непрерывно поглощают кофе. На входе кофе, внутри — магия, на выходе — готовый код.
Хотя в опросе пятилетней давности, который провёл сайт developermedia.com, лишь 16,4% из примерно тысячи разработчиков ответили, что не пьют кофе, но времена меняются. Программисты забывают о корнях и теперь вместо кофе частенько выбирают чай, а то и вовсе цикорий 🥤
Правда, о некоторых традициях отрасли забывать всё же не стоит — например, о таком вот принципе:
Всегда пишите код так, как будто человек, который будет его поддерживать, — склонный к насилию психопат, который знает, где вы живёте.
(Источник / перевод Skillbox Media)
Разработчик, который написал фрагмент программы, не всегда занимается его сопровождением (сам правит ошибки и добавляет новые возможности). Программисты не крепостные, они меняют проекты и места работы, а вот код за ними остаётся.
Есть такое понятие, как legacy code. Это код, перешедший по наследству от разработчиков, связь с которыми уже не поддерживается.
А ещё так называют устаревший код, который сохраняют для совместимости с предыдущими версиями продукта: например, написанный на старой версии языка или для старой операционной системы.
Если этот код кривой и запутанный, а сроки на доработку горят, то несчастный наследник как минимум проклянёт своего предшественника. И не раз. А уж если он (чисто случайно) склонный к насилию психопат… 😱
В общем, лучше всегда писать отличный код, но это сложно, а потому:
Хороший программист всегда посмотрит в обе стороны, прежде чем перейти дорогу с односторонним движением.
(Отсюда / перевод Skillbox Media)
Правильно делает: психопату же законы дорожного движения не писаны 😀
По правде, шутка эта скорее не о тех, кто сопровождает код, а о пользователях готовых программ. Программисты продумывают самые разные сценарии, которые могут сломать приложение. Например, чтобы обеспечить ввод корректных данных:
- не дают вводить отрицательные денежные суммы;
- скрывают или делают неактивными кнопки, которые не должны быть нажаты раньше времени;
- добавляют проверку и форматирование в поля для ввода телефонов и email-адресов.
Но всегда находятся пользователи, которые делают что-то настолько странное, что ни программистам, ни тестировщикам и в голову не могло прийти.
Есть и второй смысл: хороший программист понимает, что спецификация на программу может быть далека от того, что на самом деле реализовано. На заборе тоже много всего написано, а за ним дрова лежат.
Поэтому говорят:
Документация как секс: средненькая всяко лучше, чем никакой, а уж если хорошая — совсем здорово.
(Источник / перевод Skillbox Media)
Совсем без документации программеры обречены вслепую копаться в чужом коде. Особенно тяжко приходится, когда нужно не просто понять, что такой код делает, а исправить в нём ошибки или добавить новые возможности.
Так что использовать какую-нибудь отлично задокументированную библиотеку — это ни с чем не сравнимое удовольствие. Почти ни с чем. Ну, вы поняли 😏
Если судить по доле шуток про баги, то может показаться, что программисты большую часть времени не пишут код, а ищут в нём ошибки. Если вы тоже программист, то уже знаете секрет: так и есть! И в этом нет ничего плохого. Не зря же говорят:
Отладить код в два раза сложнее, чем написать его с нуля. Следовательно, если вы пишете код настолько умный, насколько можете, то вы по определению недостаточно умны, чтобы отладить его.
(Отсюда / перевод Skillbox Media)
Отсюда — вредный совет: код пишите в два раза глупее, чем можете, только тогда у вас хватит ума его отладить.
Конечно, это просто шутки: программисты вовсе не пишут глупости, которые потом долго исправляют, чтобы почувствовать себя умнее. Ладно, оговоримся, не пишут глупости намеренно. Shit Bugs, конечно, happen. И с ними приходится разбираться. Говорят, что:
Найти ошибки в коде бывает непросто. И ещё сложнее — если вы уверены, что их там нет.
(Источник / перевод Skillbox Media)
Программистам не чуждо творчество, а на свои творения сложно смотреть непредвзято. Иногда так хочется верить, что вот этот фрагмент уж точно написан идеально и ошибок там быть ну никак не может.
Так что один говорит: «У меня всё работает», и другой вторит: «И у меня всё работает!» В совсем запущенных случаях никто не хочет искать ошибки, в итоге же в программе работает примерно ничего.
Наверное, лучше быть к себе критичнее, чтобы не вышло как в истории с приложением Horizon. В этой программе была какая-то древняя ошибка в алгоритме расчётов. Из-за неё в почтовой компании Post Office Ltd., которая пользовалась этой программой, на протяжении 20 лет возникали недостачи денег.
Недостачи руководители вешали на рядовых служащих. В итоге — сотни пострадавших сотрудников: одни потеряли жильё и попали в тюрьму, а некоторые даже покончили с собой.
И всё, возможно, потому, что кто-то не хотел искать ошибку в программе.
А если поразмыслить над этой фразой во время чайной церемонии, можно увидеть аналогию с афоризмом «Самое трудное — это поймать кошку в тёмной комнате, особенно когда её там нет», который часто приписывают Конфуцию. По крайней мере, его вспоминал герой известного в СССР фильма «Место встречи изменить нельзя».
Однако ещё труднее — найти эту самую кошку в трактате Конфуция, особенно если её там нет.
Не соврём ни на йоту — всё отражено в народном эпосе:
Почему не хватает времени, чтобы сразу всё сделать правильно, но всегда найдётся время, чтобы сделать больше неправильного?
(Отсюда / перевод Skillbox Media)
Эта фраза — самая что ни на есть грустная реальность, хоть и попалась нам в подборке шуток.
В настоящих проектах время на разработку ограничено: заказчикам нужно работающее приложение к определённому сроку, и мало кого волнует:
- насколько стройная у этого приложения архитектура;
- насколько оптимальны в нём алгоритмы;
- как мощны его лапищ… ой, простите, кажется, это из другого сборника шуток 🐕
- и что думают о применяемых подходах те крутые ребята на ютуб-канале о разработке.
Иногда приходится искать компромисс между тем, чтобы сделать правильно и просто сделать, чтобы работало. А если не предусмотреть для программы достаточно гибкую архитектуру, то реализация каждого нового пожелания заказчика добавляет новых и новых костылей, то есть больше неправильного.
К счастью, далеко не всегда приходится идти на такие жертвы. И даже остаётся время подумать о производительности. А уж мы знаем, как заставить программу работать быстрее:
Быстрее всего работает код, который отсутствует.
(Источник / перевод Skillbox Media)
Вы же не будете спорить, что процессор скорее справится с инструкцией, которую не надо выполнять, а браузер — со страницей, которую вовсе не надо рисовать? 😎
В этой фразе заложено по крайней мере два глубочайших смысла:
- Иногда при попытках оптимизировать код выясняется, что, если удалить целые куски, ничего не ломается. Напротив — работает, и работает быстрее.
- Не стоит доходить до крайности, стараясь ускорить и улучшить. Ведь крайность — это полное отсутствие кода.
Нет кода — нет багов.
(Отсюда / перевод Skillbox Media)
С одной стороны, это о том, что ошибки есть в любом коде. С другой — если вы удалите фрагмент программы, то можете быть уверены, что исправили в нём все ошибки.
И вот он, идеальный рецепт: хотите кода без ошибок — просто не пишите его 😄
А чтобы работа программиста не показалась вам совсем уж безрадостной и бессмысленной, закончим на позитивной ноте:
— Сколько программистов нужно, чтобы поменять лампочку?
— Размечтались, у вас же проблема с железом!
(Источник / перевод Skillbox Media)
Шутку оценят все, кто хоть раз слышал в свой адрес: «Ты ж программист!» За этой фразой может, к примеру, последовать просьба починить утюг, заменить экран смартфона или даже отремонтировать сливной бачок. В лучшем случае — переустановить Windows. Об этом мы рассказывали здесь.
«Логика» такая:
- программист работает на компьютере;
- компьютер — это техника;
- сантехника — это тоже техника (пишется же почти одинаково);
- значит, программисту можно дать любую технику и он сможет с ней работать.
Конечно, среднестатистический программист в состоянии заменить лампочку, но если он до того уже починил утюг и спас мир, то может просто не захотеть этого делать.
Так что применяйте ваших программистов по назначению — ведь теперь вы знаете в них толк 👼
Учись бесплатно:
вебинары по программированию, маркетингу и дизайну.
Участвовать
Научитесь: Введение в программирование
Узнать больше
Советы по выполнению задания Momentum
- ссылка на задание
5. Виджет «цитата дня»
Виджет «цитата дня», как и виджет погоды, предполагает использование асинхронных запросов к API.
При использовании данных API необходимо учитывать, что они могут перестать работать, в результате неработоспособным станут и созданные на их основе приложения.
Например, почти у половины лучших работ позапрошлого набора виджет «цитата дня» сейчас, спустя год, не работает. Все приведённые в материалах к заданию API с русскоязычными цитатами и некоторые API с англоязычными цитатами спустя год оказались неработоспособными.
Возможным решением может быть создание собственного JSON-файла с цитатами и их авторами.
Пример файла data.json:
[
{
"text": "Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете",
"author": "Стив Макконнелл"
},
{
"text": "Сложность программы растет до тех пор, пока не превысит способности программиста",
"author": "Артур Блох. Законы Мэрфи"
},
{
"text": "Ходить по воде и разрабатывать программы, следуя ТЗ, очень просто… если они заморожены",
"author": "И. Берард"
}
]
Данные от JSON-файла получаем асинхронно.
Для этого используем async/await функцию:
async function getQuotes() { const quotes = 'data.json'; const res = await fetch(quotes); const data = await res.json(); console.log(data); } getQuotes();
Ещё один способ работы с асинхронными данными — fetch
function getQuotes() { const quotes = 'data.json'; fetch(quotes) .then(res => res.json()) .then(data => { console.log(data); }); } getQuotes();
Пример с fetch приводится для информации и сравнения. Для написания асинхронного кода async/await функции являются более удобными с точки зрения читабельности и форматирования кода.
Вместо JSON-файла с цитатами можно было создать js-объект с цитатами и работать с ним синхронно, но так как задача предложенного задания научиться писать асинхронный код, JSON-файл предпочтительнее.