Пользователь
0,0
рейтинг
20 мая 2010 в 20:05

Разработка → 10 способов облажаться в программировании перевод

10ways
Недавно по наследству от грязного, вонючего контрактора (который утверждал, что его знания и умения так хороши, чтоб не трогать его пока, он не закончит проект) мне досталось веб-приложение. К сожалению, мы поверили ему на слово. На первый взгляд большинство функционала веб-приложения работало как надо. Однако, как только клиент начал использовать приложение в реальных условиях, – весна показала, кто где срал оно начало барахлить. Контрактор исчез после оплаты (умри репутация!), а я остался, чтобы попытаться починить то, с чем пока мучился клиент.
Я решил описать некоторые из тех ошибок, с которыми столкнулся. Это ошибки, которые, каждый хороший программист давно уже должен уметь избегать… но, очевидно, что некоторым людям нужно о них напоминанать.


#10 — Не храните настройки в конфигурацонном файле


Когда вы пишете масштабируемые приложения, такая информация, как параметры соединения с базой данных и адрес SMTP сервера, будет использоваться во всем приложении. Чтоб наверняка защитить ваше приложение от дальнейшей поддержки, переопределяйте эти параметры каждый раз, когда они вам нужны. Вместо того, чтоб вынести их в файл конфигурации (Web.config или любой другой), просто разбросайте их по всему проекту. Тот, кому в дальнейшем достанется ваше приложение, будет благодарить вас за плутание в тысячах строк кода, чтоб всего лишь изменить имя SMTP сервера. Куда веселей, когда следующий программист находит имя сервера только в 14 из 15 мест, а то, последнее 15-ое место где-то в глубине кода заставляет приложение работать неправильно. Иногда полезно строить название параметров из непонятно как слепленных строк. Активное партнерство нового разработчика и недовольного клиента будет способствовать укреплению их взаимоотношений. И если не вы, то кто создаст предпосылки для этой тесной дружбы?

#9 — Не храните переменные в [любой] памяти


Одно из преимуществ баз данных – это то, что они хранят информацию и позволяют получить доступ к ней всякий раз, когда вы в ней нуждаетесь. Чтобы убедиться, что ваше приложение ну просто ужасней некуда, обращайтесь к базе данных каждый раз, когда вам нужен хоть небольшой кусок информации. Чем чаще вам нужна эта информация, тем лучше – создавайте все новые и новые соединения с базой данных. Общая информация о пользователе системы – больше всего подходит для этого. Не пытайтесь сохранить информацию о пользователе, вроде «isAdmin», присвоив значение какой-то переменной и используя ее на протяжении всего текущего запроса. Соединяйтесь с базой данных каждый раз, когда вам нужно что-либо узнать о пользователе. В конце концов, клиент заплатил за эту базу данных, и мы должны выжать из нее максимум возможного!

#8 — Используйте хитрые плагины


Если у клиента нестандартные требования, например, форматирование таблиц которое не может сделать ваш WYSIWYG редактор (colspan – это трудно), вы определенно должны найти в интернете редкий неподдерживаемый плагин без исходного кода, которые выполнит за вас работу. Чтоб написать такой же самостоятельно – вы потратите почти целый час; лучше потратить три часа на поиск плагина, который делает примерно, но не совсем то, что вам требуется. +1 в карму, если вы сможете найти плагин, который не делает то, что вам нужно, но предлагает 15 МБ + возможностей, которые вам не нужны, однако которые нельзя убрать. +2 в карму, если документация для этого плагина написана на языке, который вы не знаете.

#7 – Никогда не удаляйте функциональность


В ходе разработки больших приложений есть моменты, когда функциональность над которой вы работали, уже не требуется. Чтоб оставить тупики и лабиринты для тех, кто будет в дальнейшем работать над этим приложением, не удаляйте эту ненужную функциональность. Можно даже в случайном порядке закомментировать некоторые небольшие куски, или даже сотни строк этого кода, но не удаляйте его. Представьте себе часы приятного препровождения будущей команды этого приложения, когда они будут распутывать клубок вашего кода и обнаружат, что он вообще не нужен! Если вы сможете сделать это так, чтоб выглядело так, что код вроде бы как нужен, а на самом деле – нет, ваш преемник побоится сам удалять такой код… Вот это будет весело! Ах, опять же бонус… если ваш проект использует средства контроля версий и несколько серверов, убедитесь, для каждого сервера и системы управления версиями — версии файлов разные (как исходники, так и бинарники). Так никто не узнает, какая версия в продакшен, а кому неохота поиграть в русскую рулетку на продакшен сервере?

#6 — К черту производительность


Большие приложения, как правило, используются для работы с большими объемами данных. Конечно, во время разработки вы создадите 20 или около того тестовых записей. Бьюсь об заклад, что нет ни малейшей необходимости беспокоиться о том, что происходит, когда у вас 25 записей, или даже 1000! Очевидно, если разбить данные на страницы — все будет прекрасно работать и производительности всегда будет отличной. Так что, если приложение компилируется, смело отдавайте его заказчику!

#5 — Запихивайте основную логику/функциональность в циклы


Как мы уже заметили в #6 — мы работаем с большими объемами данных. И неизбежно часто нужно будет пробегать по данным в циклах. Чтоб ваше приложение действительно было трудно поддерживать, вы должны вставлять основные функцонал и/или логику внутрь циклов. Например, вместо того, чтобы сделать запрос к базе данных, закинуть все данные в память и пройтись по массиву данных в цикле, получите все данные за исключением одного поля и пробегитесь в цикле по ним… Затем, в следующем цикле, вы должны опять получить все данные из базы, но на этот раз включить еще одно дополнительное поле. Это будет гарантией того, что ваше приложение ляжет от пяти одновременно работающих пользователей (Re: # 6). Закрепим материал: получите данные> создайте цикл> получите данные> работайте с данными. Уверен, что этот наработка позволит добиться полнейшего идиотизма, поэтому не стесняйтесь использовать сей хитрый прием столько раз – сколько вам захочется.

#4 — НИЧЕГО не документируйте


Всем известно, что документация – это для дебилов. Что я хочу сказать, — либо вы можете прочитать код, либо вы не можете, так? (именно так было мне сказано в одном разговоре) КОНЕЧНО ЖЕ, следующий программист сможет прочитать код. Становится интересно, когда вы абсолютно не пишите комментариев, — что, для чего, почему? Пусть теряются в догадках. Вы таинственны, как ниндзя. Не нужно, чтоб кто-то знал все о том, что вы пытались сделать. Потому что, если вы написали, что собираетесь что-то сделать, а в конечном не делаете это… ну… это просто неудобно.

#3 — Используйте нелогичные имена переменных


Если для работы над приложением нужно много переменных, необходимо выбрать фильм или телешоу в котором достаточно персонажей – вы будете использовать их имена, как переменные. Властелин колец, Звездные войны и Гриффины – отличный выбор. Может быть, вы даже сможете подружиться с переменными. Тогда вам не придется их убивать! Вы можете создать переменные-хамелеоны – и тогда вы сможете обнулять и присваивать им каждый раз что-то новое, когда потребуется переменная для новой функциональности. Они будут расти и развиваться прямо на ваших глазах! Опять же, поддержите гринпис и партию зеленых – используйте минимум переменных!

#2 — Ловите все ошибки — и ничего не делайте с ними


В наше время большинство языков/платформ имеют встроенный механизм обработки ошибок. Если программа падает — она оставляет достаточно подробные сведения через стандартный поток ошибок. Но вы не можете оставить это просто так! Начните с упаковки каждого небольшого кусочка функциональности в try/catch. А потом внутрь… catch вставьте комментарий, вроде "/ / Тут полнейшая лажа".

#1 — Дублируйте функциональность


Если клиент сообщит вам, что им нужно 2 страницы: одна для администратора – где список товаров с кнопкой удалить напротив каждого товара, и одна для обычного пользователя – список без кнопки «удалить», вам обязательно нужно создать 2 отдельные страницы. Вообще-то, если вы можете сделать отдельную страницу для каждой группы пользователей – это еще лучше. Создание отдельной страницы для каждого пользователя — это 100% успех. Сосредоточтесь и серьезно отнеситесь к делу, так как это ваша последняя линия обороны против орды квалифицированных специалистов, которые неизбежно будут недоуменно пытаться улучшить тщательно спроектированный ящик Пандоры внутри вашего приложения.

Это отнюдь не исчерпывающий список. Только на этом проекте я мог бы назвать еще 10 отстойнейших вещей. На этот раз я оставлю 10. Кто хочет добавить еще пару пунктов?
Перевод: Donnie Garvich
Артем @woworks
карма
70,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (208)

  • +7
    История картинки из топика очень даже соответствует стилю изложения текста :) Спасибо, улыбнули :)
  • +16
    Спасибо, посмеялся, написано великолепно! Вспомнились свои ранние проекты где все кишило подобным. Особой значимостью пользовался пункт «Дублируйте функциональность», а «страшное» слово рефакторинг посылалось далеко-далеко.
    • +30
      через несколько лет вы будете говорить также о текущих проектах, не переживайте.
      • +1
        Я очень надеюсь, что не буду ;)
        • +16
          Нечетко понял комментарий. Да, наверное буду, прогрессировать неоходимо!
          • +17
            блин, а я уж хотел писать злобный комментарий.
        • +1
          Наоборот, нужно надеятся что будете. Это значит, что что-то изменилось, это значит вы профессионально растете.
          • +4
            быстро соображаете =)
      • 0
        нет предела совершенству
      • –1
        Именно поэтому по-моему единственный способ облажаться в программировании, это не сохраняться и не делать бекапы.
  • +28
    Больше вложенных ifов =) чем больше вложенность тем больше + в карму ;)
    • +44
      … запрятанный где-то в глубине иерархии if-ов оператор goto (или break/continue в тех языках, где оператора goto почему-то нет) добавит вашему коду изюминку, а разбирающему его — массу интересных эмоций!
      • +15
        goto — это прошлый век. comefrom — наше всё!
        • +3
          #define true false
          • +1
            Вторая версия:

            To Do
            < — #define true false -->
            < — go to ->
            #define false true

            Ну и к базе надо обращаться не сколь часто сколь сильно — фильтры на стороне сервера придумали трусы!
            Трафик = крутость :)
            • +1
              #define if(exp) if(random(100)>50)
              • +1
                неее…

                #define if(exp) if( ( exp ) && rand(10000) > 9999 )

                так эффект будет гораздо неожиданней :)
                для надежности, random(… ) необходимо реализовать прямо в макросе, чтобы нельзя было понять, что выполняется что-то еще кроме (exp) путем step in…
            • 0
              Фильтры на стороне сервера очень нужны — без 1000 и 1 join в запросе обеспечить требуемое время реакции нереально
    • +5
      ну когда сложная логика строится в одном if — тоже не фонтан получается. в проекте, над которым сейчас работаю, есть ряд таких мест — даже трогать боюсь :)
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Вообще-то это не так уж и плохо. В процессе разработки такое встречается частенько. Это часто бывает когда знаешь что условий будет несколько, но ещё не знаешь точно какие.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Бывает…
            До этого года, к примеру, я практически нигде не встречал варианта if'а как $result = ((condition)? $val_1: $val_1); а в этом году такое сплошь и рядом… бывает.
            • 0
              это называется «тернарная операция», а не подвид ифа
              • 0
                Ваш комментарий что-то принципиально изменил?

                ЗЫ. Очень напомнило про лампочку и теристорный светодиод.
                ЗЗЫ. Кстати, не подвид, а вариант.
    • 0
      помню, смотрел исходник index.php форума phpBB
      там было столько вложенных IF, что я иногда даже терялся
      • 0
        Меня спасает подсветка соответствующей скобки
        • 0
          меня она тоже спасает)
  • +30
    в #4 я бы добавил:

    … В случае, если вы все же используете комментарии, по возможности следите за тем, чтобы они всегда отставали на 2-3 версии от комментируемого кода. Тому, кто будет разбирать ваш код, очень интересно будет проследить ретроспективу сделанных изменений. Возможно, он даже окажется поражен, насколько кардинально вам пришлось переработать ту или иную часть программы. Если вы вместе с кодом обновите и комментарии, как он узнает о вашем титаническом труде?
  • –7
    Чем вам try/catch не угодил? :)
    • +6
      отсутствием log.Write или [re]throw в блоке catch
    • +31
      если код по какой-то причине вылетает — нужно всего лишь обернуть его в try/catch. Это избавит вас от необходимости отладки, а пользователя — от лишних волнений по поводу странных сообщений об ошибках!
      • –20
        Спасибо кэп, вы как всегда вовремя.
    • +51
      try
      {
      MainLoop()
      }
      catch
      {
      // Ничо небыло, небыло н-и-и-ч-его, всё работает как надо, вам показалось
      // Бабуськи, бабуськи, бабуськи, *вуи-и-и-и-и-и*
      }
      • –28
        не хочу никого обидеть и упоминание языка связано только с тем, что используемое ПО написано на нем. Да и по вашему примеру похоже на C#. Есть у нас разработчики, которые делают так, которые, наверное, и думают как написано в комментариях кода. Вот только я как пользователь откомментировал бы так:

        Ничо небыло, небыло н-и-и-ч-его, НИЧЕГО не работает как надо и вы теперь хрен разберетесь где у меня косяк… (из личного опыта)
        • +20
          я, конечно, рискую, но спасибо, кэп!
          • –5
            простите, очевидное для вас не очевидно для всех, а то этой хрени бы уже не было…
            • +2
              вообще, очевидно для всех.
              • +4
                ну наверное вы правы…
        • +1
          этот код точно также может быть кодом на js или php (только точки с запятой после MainLoop() не хватает)
          и вообще языков с C-подобным синтаксисом довольно много.
          • 0
            по-моему я написал похоже?! см коммент выше…
      • +1
        :) спасибо за идею, сам бы не догадался весь mainloop завернуть :)
        • НЛО прилетело и опубликовало эту надпись здесь
    • +10
      Прекрасный вариант если вы будете информировать пользователя, что данные успешно записались в БД:

      $query = «insert into table_name values(1,1,1)»;

      try {
      mysql_query($query, $MySQLlink);
      } catch (Exception $e) {
      //Какая-то ошибка
      }

      echo «Все успешно записалось!»;

      Пользователь будет всегда уверен в вашем приложении и корректности его действий!
    • 0
      одно дело реагировать на ошибку, совсем другое — просто ее закрывать
      • 0
        ой. пока читал, уже народ отписался сверху %)
    • 0
      Он не был оформлен в цикле, вызывающем рекурсивную функцию, скорее всего… Это просто недопустимо с точки зрения описанного выше подхода к проектированию.
    • 0
      Интересно, что бы было в блоке catch программы управления ядерным реактором какой-нибудть Терра-электростанции…
  • 0
    Боже. Вы вскрыли, что-то невероятно опасное :)
    Плохо, когда программисты забывают о возможных проблемах любой строчки кода.
  • +7
    было очень приятно почитать. про убийство переменных — не могу согнать идиотскую улыбку до сих пор с лица
    • +1
      assasin variable
      • 0
        assassin — вторая s тоже дублируется
      • +1
        assassinate variable
        тогда уж
  • НЛО прилетело и опубликовало эту надпись здесь
    • +4
      >Результат, на вчерашний день ~1100 строк кода javascript
      это цветочки. У меня в одном проекте ~1800 строк чистого жабокрипта, без всяких jquery и прочих этих ваших фреймворков.
      Надеюсь, что не умру от икоты через пару лет, когда этим проектом будет заниматься кто-то другой
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        мало. вот админка на сто тыщь строк html и php и без всякого js — это по-мужски
        • 0
          а она вообще запускается? :)
          • +1
            на ней работают и дописывают новые модули. честно-честно, но я оттуда уже убежал
    • +2
      GWT! GWT!
  • 0
    Спасибо!) Кое с чем приходилось сталкиваться =)
  • +4
    Теперь я знаю как получить в карму плюсик :)
  • +1
    Благо ни разу не встречал ни чего подобного (кроме отсутствия документирования нечитабельного кода), и если честно я не подозревал что некоторые моменты реально встречаются в жизни.
    А ваш этот контрактер не студент случайно?
    Я, поначалу, тоже допускал в своей практике глупости, но, буквально, за пару месяцев усиленной практики, избавился от всего (разве что не научился нормальные доки писать — чисто психологически не могу — напрягает, но стараюсь)
    • 0
      >> Я, поначалу, тоже допускал в своей практике глупости, но, буквально, за пару месяцев усиленной практики

      ну так может быть его пара месяцев еще не прошла…
    • 0
      везёт вам. лично встречал в production коде 10, 7, 4, 3, 2. И это ещё не предел.
      • 0
        Лично встречал в production коде все 10, до 8 в пределах одного проекта :)
        • +3
          а, так Donnie Garvich — это вы!
        • +1
          что, серьезно называют переменные именами героев фильма? не верю!..:)
          • 0
            Ну именами героев — такого есс-но не бывает, но не говорящие названия встречаются очень часто, вот например цитата из одной CMS, где я с этим встретился в последний раз:
            global $c, $cl, $h, $u, $l, $docstart, $su, $s, $pth, $tx, $edit, $adm, $cf;
            
            Если как используются docstart, adm и edit еще можно что-то предположить — то остальные переменные… Так вот в данном случае уж лучше-бы они назывались именами героев фильмов :)
  • 0
    #2 — мне больше всего нравится, как пользователю. Жмешь на кнопку и не поймешь в чем дело.
  • 0
    По-моему в ХабраЮмор будет логичнее поместить. За топик спасибо :)
  • +38
    10 способов… я знаю как минимум 100 и активно их применяю!
  • +1
    #N Никогда, слышите, НИКОГДА не применяйте ООП в проекте. Использование функционального, а лучше вообще линейного подхода придаст Вашему коду особый шарм и привлекательность. Если же по тем или иным религиозным причинам, Вам всё таки пришлось пользоваться функциями, разносите их как можно дальше от того места, где они используются.
    Оптимальным вариантом будет тот, в котором функция будет принимать как минимум двадцать разношёрстных аргументов и, в зависимости от их вида и состава возвращать совершенно непредсказуемый набор данных. В некоторых случаях можно даже чуть-чуть приправить это всё функцией rand() для придания особого вкуса и аромата.
    • +1
      Никогда не используйте наследование, если уж применяете ООП. Сделайте 10 классов с функционалом, дублирующимся на 95%, и парой отличающихся функций. Перемешайте их местами, чтобы усложнить анализ кода и рефакторинг. Время от времени вносите несущественно, но разные изменения в дублирующийся функционал.
      • +34
        Сразу видно что ООП вы совсем не понимаете, наследовать надо ВСЁ!!! БД от конфигурации, шаблонизатор от БД, контроллер от шаблонизатора — вот тогда все это будет гибко и удобно, все под рукой! А самый первый класс конечно-же нужно от исключения наследовать, чтобы можно было сделать так:
        throw $this; // Не ожидали?
        
        • +2
          Я не могу, я смеюсь истерически :) Это в рабочем проекте такое было?
          • +2
            Ну в рабочем проекте конечно было поскромнее :) Абстрактный контроллер наследуется от смарти, сам в себе методов контроллера не содержит, зато содержит методы работы с БД, ну и от него уже контроллеры страниц, с экранированием данных в конструкторе, когда их вызывалось несколько — то и данные несколько раз экранировались, на сложной странице массив пост был экранирован 14 раз, чтобы совсем безопасно было :)
            А исключения там по-умному использовались:
            try {
              if(!isset($_POST['data'])) {
                throw Exception;
              }
              $data = $_POST['data'];
            } catch(Exception $e) {
              $data = NULL;
            }
            
            Но ученик ведь должен обойти своего учителя? :)
        • 0
          Убили
        • 0
          всё, я не могу больше смеяться
          руки трясутся )
      • +2
        Самое главное в нашем деле- забыть к чертовой матери про инкапсуляцию. Сделайте все поля public, а заодно наклепайте одноименных свойств объекту. Мы же свободу действий- человек должен иметь право творить с объектом все что он хочет!..

        А еще делайте объекты, которые делают всё. Нет, вы не поняли. Вообще ВСЁ! Если описываете объект стол, то интерфейс «Собрать, Разобрать, ПоставитьНаСтол»- жадность. Пусть стол еще сам определяет поверхность на которой стоит, свойства грунта, плотность атмосферы, и силу ветра в соседней стране.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Особое внимание уделяйте паттерну Singleton — его массированное использование гарантирует непревзойденную гибкость и легкость модификаций.
        • НЛО прилетело и опубликовало эту надпись здесь
  • +22
    «Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.»
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Перевод хороший, это единственный плюс автору :)
      • 0
        Я даже не понял, что уже читал это, пока не наткнулся на ссылку на оригинал)
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Ну тогда никаких претензий :)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          эммм, а вы вообще смотрели на эту «иконку»?
          • 0
            херню написал, какая иконка?! Смотрели левее ника автора, там какбе ссылка на оригинал.
            • НЛО прилетело и опубликовало эту надпись здесь
              • НЛО прилетело и опубликовало эту надпись здесь
                • НЛО прилетело и опубликовало эту надпись здесь
                  • +1
                    Скажу в обвинение возмущающегося — каждый топик-перевод начинается с этого вот брызганья слюной по поводу того что дескать топик-перевод не похож на топик-перевод, и на каждый такой комментарий отвечают и про иконку, и про ссылку на авторский текст — но как-бы все равно в каждом следующем топике переводе появляется новый бэтмен, возмущающийся попранием авторского права. Доколе? Whyyouwannakillme? :)
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • 0
                          Ну недоработка интерфейса — это-же не вина автора перевода. Можно понять людей которые не задумываясь обращаются к переводчику как к автору текста, как раз таки из-за недоработки интерфейса, они при этом никого не обвиняют, но когда человек готов перерыть пол-интернета в поисках оригинала, ради того только чтобы написать "%username% — ты казёл!", вместо того чтобы разглядеть повнимательнее сам топик — я этому не вижу оправданий :)
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • 0
                              Ну безусловно, сколько-либо заметная надпись «перевод» решила-бы эту проблему.
                              Но тут в принципе мне, я так думаю, понятна позиция разработчиков, мне вот лично при прочтении топика в первую очередь интересен текст топика, и что уж скрывать, мне абсолютно наплевать кто его написал, но если уж текст покажется мне настолько интересным что я захочу найти другие статьи автора — то единственное место где я могу это сделать — та самая панелька с ником автора, датой и кнопками голосования, и у топиков-переводов там как раз таки находится ссылка на оригинал, ч.т.д. :) Ведь даже если топик — не перевод — не будешь-же громогласно объявлять в комментариях: «Автор, поди сюды, пости мне ссылки на остальные твои статьи! Быро!». То есть когда есть заинтересованность в авторстве статьи — есть только один способ его узнать.
                              • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
            • +6
              вы первый пункт прочитали/поняли? интерфейс уже предлагает средства для обозначения того, что это перевод, и указания автора. как раз бля того, чтобы народ не писал везде «мопед не мой»
            • НЛО прилетело и опубликовало эту надпись здесь
        • +7
          вы вроде как давно на хабре, а о топиках переводах не знаете? иконка Z-Я означает что это топик перевод, в конце топика возле ника опубликовавшего есть ссылка на оригинал.
    • +2
      Прежде чем возмущаться, посмотрите на значок рядом с заголовком, а затем на строку под тегами.
  • 0
    #8 — достаточно спорный способ облажаться. Конечно в приведенном примере это вполне себе способ, но на практике бывает иначе, и если есть хитрый плагин который решает задачу, и пусть он дает еще 2-3 новые фичи, которые толком никому не нужны — лучше воспользоваться им и просто убрать эти 2-3 фичи, если уж совсем не нужны. Почему? Ну хотя бы потому-что изобретать велосипеды не хорошо. Да и потом, разве легче будет разобраться с куском доработанного кода для WYSIWYG? чем с более навороченным редактором или плагином таблиц для этого редактора?
  • +5
    ох… вспоминается:
    #define true false // удачного дебага
    или
    #define true ((rand() % 2? true: false)
  • +3
    О да. Спасибо автору, очень сильно улыбался. Но не оттого что смешно. А потому что 1:1 описан софт, с которым я работаю по долгу службы. Нет, правда. Такое ощущение, что «афтар» действительно держал ваш списочек под руками.

    От себя могу добавить еще кое что:

    1) Используйте новые технологии! На дворе 21 век! Какое нафиг MFC и Дельфи! Тащите в проект как можно больше всего нового и интересного! Пусть часть страниц будет генерироваться в jQuery, часть прямо в коде библиотек, часть в БД (а чего она простаивает большую часть времени, столько же денег на сервер потратили). Все будут восхищаться тем, какой крутой ваш проект и как в нем органично сочетается все новое. Разумеется вы гуру, поэтому будете применять даже то, о чем прочитали лишь сегодня на хабре. Продакшн просто создан для обкатки всего нового!

    2) COM объекты это просто рай! Их должно быть побольше! Нужно установить соединение? COM объект! Нужно сообщить об ошибке? COM объект! Нужно обработать миллион записей из базы? Ну, вы поняли… Да, обработчики тоже должны быть COM объектами и лежать в базе в виде dll. Ну и что, что четырехъядерный сервер будет ложиться при пяти клиентах. Зато вы поддержите технический прогресс! А переносимость тут вообще непричем. Я и слова-то такого не знаю.

    3) Контроль версий? Вы о чем? Настоящие индейцы пишут программу одним махом и никогда не делают ни форков, ни резервных копий дерева. Бранч для слабаков!

    4) Побольше велосипедов! Новые технологии это конечно здорово, но вы же знаете что у них есть фундаментальный недостаток — его писали не вы (ну да, это уже копипаст)! В общем не унывайте. Если вам нужен архиватор, нет ничего лучше чем написать его самому. Скриптинг тоже хорошо. Но для полноты ощущений надо сделать свой собственный ЯП! Ну вы же знаете, что если вы хотите сделать что-то хорошо, надо сделать это самому. Так что, смелее товарищи! Топчите батоны пачками. Аминь.
    • +2
      Вынужден вас расстроить — MFC и Дельфи — не последнее из обкатанного и стабильного из мира софта :)
      • 0
        Вы, пардон, читать умеете? =)

        Сдается, у народа с чувством юмора не все впорядке =)
        • 0
          Вы противопоставляете 2 вещи — использовать «MFC и Дельфи» (как что-то проверенное) vs «генерация страниц в jQuery» (как что-то новое и необкатанное). Что бы из этих двух ни было шуткой,… ну вы меня понимаете.

          Может я что-то не понял?

          P.S. Читать не, не умею, ессессно.
    • 0
      И про COM-объекты Вы тоже зря с плеча рубите. Весьма в некоторых ситуациях полезная штука.
      • +2
        По вашему, «в некоторых случаях» и «на каждый чих» это одно и то же? :)
  • +1
    Можно контакты Вашего контрактора узнать, чтоб если что, то сразу к профи? )))
  • НЛО прилетело и опубликовало эту надпись здесь
  • +13
    1. Критерии WHERE для SQL запросов лучше всего забивать в значение полей формы.
    2. Глобальные переменные наиболее гибки и универсальны, какой смысл использовать локальные?
    3. Зачем усложнять логику приложения, если многие вещи, такие как удаление пользователя, вполне реализуемы Smarty-плагином?
    4. Нужно четко следовать соглашениям, по понеденьникам называть функции через_подчеркивание, по вторникам в camelCase, по средам можнослитно, в четверг функции писать грех, обходитесь без них.
    5. К коммитам нужно писать комментарии, вариант some changes наиболее универсален.
  • +29
    • +1
      Вежливость — главное оружие… (с) :)
  • 0
    И не забывайте про обфускацию :)
  • +8
    Есть такая классическая книжка С.Макконнелла — «Совершенный Код». У данного фундаментального труда есть одно неоспоримое преимущество: увесистым томиком очень удобно бить разработчиков, которые следуют указанным в топике советам.
    Нанесенные телесные повреждения, обычно, способствуют улучшению ситуации с кодом. ^_^
  • 0
    10 заповедей говнокода.
  • +3
    в индусском коде популярны такие конструкции:

    if (someExpression)
    {
        // code
    }
    else
    {
        // точно такой же code
    }
    
    • +6
      помнится мне более веселящая конструкция примерно такого плана:

      if ($a > NINE_THOUSANDS) {
          // over9000
      } elseif ($a <= NINE_THOUSANDS) {
          // >_<
      } else {
          // PROFIT!!!
      }

    • 0
      Чего за индусами ходить? Года полтора назад сотрудник такое сморозил )
  • +1
    Дайте картинку из топика покрупнее
    • 0
      хотел попросить тоже самое.
    • +2
      Это покромсаная Airplane safety brochure from Fight Club
      Посчитал, что будет уместна к такой теме :)
  • 0
    даааа… ни кому не пожелаешь встретиться с таким произведением искусства
  • 0
    до сих пор помню, как копаясь в каком то билинге нашли шикарнейшую конструкцию:
    запрос к базе Select 1 from user; // да да да, именно 1 едеиничка!
    далее все это принимаем в массив
    затем еще раз проходим по массиву и делаем users=user+элемент массива (который единичка)
    в общем страшно =)
  • +7
    хочется добавить пару пунктов.
    1. разнести функционал который может выполнять один класс на 2-3 класса, с перекрёстными ссылками друг на друга
    2. использовать по больше интерфейсов, причем каждый интерфейс пусть реализовывается только одним классом — это очень удобно отлаживать, нажимаешь на «показать реализацию», а IDE тебя в интерфейс бросает
    3. использовать магические числа почаще. типа так: executeSomething(-12);
    4. инкапсуляция это не для нас. методы нельзя вызывать простым someObject.executeSomething(), это будет слишком просто. метод надо вызывать так:
    someObject.executeSomething(anotherObject.getSomeSettings(object3.staticField)). Таким образом мы убъём сразу трех зайцев — разработчика, администратора и саппорт.
    5. в ссобщениях пользователю обязательно должны присутсвовать слова «инициализация», «дескриптор», «процессор».
    6. очень важно чтобы в вашей программе был хотябы один цикл на 1000 строчек, пара модулей с 3-5 классами которые модифицируют приватные поля дружественных классов и по больше методов на 100-200 строк.
    7. к каждому методу и классу неплохо было бы дописать коментарии вот такого вида
    // конструктор [для конструкторов]
    // получение серверного времени [ для метода getServerTime() ]
    // менеджер печати [для класса PrintManager]

    и на последок совет: пишите побольше своего кода. много, очень много кода. фреймворки придумали враги.
    • 0
      Накипело?
      • +1
        все описанные мной и в переводе проблемы сводятся к одной простой мысли: авторы не задумываются, как их код будет сопровождать(развивать) другой программист. а ведь чаще всего этим программистом в конечном итоге через месяц становится сам автор
    • 0
      нажимаешь на «показать реализацию», а IDE тебя в интерфейс бросает
      какая-то у вас странная IDE. не то что бы я работал с большим количеством IDE, но eclipse же показывает нормально и объявление, и реализацию
    • 0
      Спасибо, посмеялся :).
    • +1
      7 пункт, каюсь ибо грешен. Вечная моя проблема стараться закоментировать заголовки всех методов
      /**
      * Get Product Id by SKU
      *
      * @param string $productSku sku of product
      * @return array[product id, store_id], or null if product not found or condition not equal
      */
      private function getProductIdBySku($productSku)

  • 0
    Почему не упомянут адский замес html и php кода на одной странице?
    Автор пропустил много интересного.
    • +1
      Ну автор просто не привязывался конкретно к PHP, а в других языках так к сожалению делать нельзя :) потому они скучные и неудобные :P
      • 0
        я могу так писать на скале )))
      • 0
        А, я не уверне, но помойму еще руби так умеет, нет?
    • 0
      добавьте к списку SQL…
  • +1
    Понравился стиль написания =) Приятно было читать.
    А вообще всегда надо контролировать процесс… это реалии.
  • +1
    Идеальная инструкция. Завтра же заменю предыдущую :)
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Представляю какая веселуха будет, после хорошенького внедрения функционального программирования в бизнес-проекты, с жесточайшими рекурсиями и веселыми лямбдами.
  • –1
    Думаю статью стоит дополнить реальными примерами.
    govnokod.ru/
  • +7
    Придумайте свой формат хранения данных. Забейте на всякие там XML, JSON и прочую хрень — ну зачем оно Вам? Напишите свой парсер. Ничего не документируйте — Ваш формат ведь простой и понятный!
  • 0
    Едко, но актуально :)
  • +1
    Старайтесь минимизировать количество файлов. Кому нужны огрызки по сто строк? Запихните весь проект в один файл. Идущий за вами будет счастливо поражён и позовёт друзей посмотреть на «смотрите, жмём PageDown, и 20 секунд оно скролится»
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    К девятому пункту могу добавить совет не закрывать соединение сразу же после получения данных — ведь довольно скоро снова нужно будет обратиться к базе.
  • +2
    А пустые catch'и — дааа, это верх мастерства просто.
  • 0
    Magento видели? — хватить ныть! =)
  • НЛО прилетело и опубликовало эту надпись здесь
    • +5
      Омайгадебл :)).
    • +4
      Извините, Вам сюда ;))
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        • +13
          от слова «кретин»? =)
    • +1
      а, то есть все остальные советы нормальные, да?
    • +2
      а ведь люди на полном серьезе пишут такие каменты…
    • 0
      Почитайте заголовок…
  • 0
    > Не пытайтесь сохранить информацию о пользователе, вроде «isAdmin», присвоив значение какой-то переменной и используя ее на протяжении всего текущего запроса. Соединяйтесь с базой данных каждый раз, когда вам нужно что-либо узнать о пользователе.

    Если доходить до крайностей, то и это и обратное вредно. Если программп полагается для определения прав пользователя только на переменную isAdmin на клиенте, то может найтись тот, кто возьмёт какой-нибудь ArtMoney и пороавит её. Если постоянно хранить все данные в уме, то к концу сеанса можеть стяться что представление программы об объекте неадекватно реальности. В общем надо по ситуации смотреть и во всём знать меру. Перефразируя Эйнштейна, можно сказать что следует делать компоненты на столько незваисимыми на сколько это возможно, но не больше.
    • +1
      Мне кажется, речь всё же шла о серверных приложениях, где ArtMoney по определению бессилен =)
      А запрос и к локальной БД можно перехватить и модифицировать путём какого-нибудь хитрого хака. Нет ничего невозможного.
      • –3
        А где ArtMoney бессилен? Давненько не пробовал. Что, теперь все компилеры стали переменные шифровать?
        • +3
          ArtMoney не сможет прочитать память сервера где isAdmin объявлен.
  • 0
    > +1 в карму, если вы сможете найти плагин, который не делает то, что вам нужно, но предлагает 15 МБ + возможностей, которые вам не нужны, однако которые нельзя убрать. +2 в карму, если документация для этого плагина написана на языке, который вы не знаете.

    +3 в карму если Вы работаете программистом не зная английского, +4 в карму если Вы найдёте плагин, для которого нет документации ни на английском ни на русском.
    • +1
      +4 в карму — это сила :) Остается только скорбеть о том что PHP не поддерживает локализованное именование переменных, функций и т.п., а-ля:
      $суньхуньвчай = new Выньсампей();
      • +1
        Разве? Помнится на хабре была статья в которой все переменные и функции были на русском.
      • +1
        я вас обрадую, поддерживает
        shock@garbing-roundabout:~> cat /home/shock/Desktop/ru.php
        <?php
        $привет 
        123;
        echo 
        $привет"\n";
        shock@garbing-roundabout:~> php /home/shock/Desktop/ru.php
        123
        • +1
          Когда я проверял — видимо что-то не срослось, может кодировка была не та… ну что-же, это открывает буквально доселе невиданные горизонты говнокода :) $Ура->товарищи()!
  • 0
    Уволился с работы в которой такое впечатление что этот пост был библией разработчика системы котору я поддерживал. Врагу не пожелаю.
    • +1
      Да, добавте в пост — надо использовать ООП в перемешку с функциональным программированием и глобальными переменными :-) Это круто, когда
      class foo{
      global $foo1;
      }
      • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    > Очевидно, если разбить данные на страницы — все будет прекрасно работать и производительности всегда будет отличной.

    С разбивкой на страницы тоже надо меру знать. Лично меня очень задалбывает когда табличка из 100 не слишком больших записей разбивается, скажем, на 5 страниц в гонке за скоростью отдельных запросов не стоит забывать о юзабилити (а я частенько это встречал). Если речь идёт о бизнес-приложении, то в идеале, мне кажется, чтобы при pagination на одну страницу по дефолту выдавалось столько записей, сколько поместится на одной странице при печати, и практически обязательно у пользователя должен быть выбор (например меня всегда напрягало отсутствие в некоторых популярных форумных движках возможности отобразить всю ветку целиком, без pagination).
  • +2
    Слишком сложно.
    Есть универсальный рецепт «многослойный говнокод»:
    1. Сначала пишем побыстрее лишь хоть как-то работало.
    2. Никогда не трогаем написанное в первом пункте лишь бы не сломалось.
    3. Применяем первые два пункта всегда и везде в проекте.
    Результат будет даже круче, чем у автора оригинала.
  • 0
    «как писать нечитаемый код (гарантированная работа на всю жизнь ;-)»
    www.nestor.minsk.by/sr/2006/02/sr60201.html
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    — Зачем платить Пете если Вася сделает в три раза дешевле.

    Петя дорабатывает, нарабатывает, матерится…

    PS Ситуация до боли знакомая. Причем мало знающий без опытный заказчик всегда выберет дешевый вариант. Поэтому людям которые хорошо владеют профессией зачастую попадаются такого рода проекты, так как к ним приходят уже на второй раз.
  • +1
    Эх, радуйтесь что код вообще читаем и разбираем, пусть и с бутылкой. Мне как-то достался почти мегабайт исходников кода, который иначе как бредом я назвать не могу. После трех дней мучительного ковыряния в IDE и с тетрадкой, в которой я кратенько записывал что там творилось, я просто с заказчика вытряс старые требования и переписал его напрочь.

  • 0
    Облажался тот, кому досталось это все разгребать за человеком, который срубил бабки и исчез
  • 0
    Всем известное высказывание Кнута как бы намекает, что #6 это больше вопрос корректного тестирования, нежели производительности.
  • –2
    Не нравится повествования статей таким типом. Типа — уйдем от противного.
    Наверное, мне не хватает таблички «Сарказм».
    • +1
      Остера в детстве не читали, наверно… Это ж классика =)
      • +1
        Читал-не читал, какая разница? Просто говорю, что лично мне не нравятся такие статьи. Просто не интересно учить. Типа подъёбывают. Не люблю подъёбы.
        • +2
          человек обычно не любит подъебы в двух случаях — нет чувства юмора (сам не умеет подъебывать, но хочет научиться), или задевает за живое (и поэтому часто становится объектом этих самых подъеб)…

          скажу честно — я ранее сочетал в себе оба варианта… и вылечился =) чего и вам желаю…
          • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              fail? =)
              • 0
                подъебали))
  • +3
    черт, про меня на хабре пишут)
  • +2
    pastebin.ru/312604
    Больше for for for!
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Не выйдет нормальных разработчиков из тех, кому плевать на систему которую они создают и еще больше плевать на необходимость понять зачем, для чего и кому она собственно нужна.
  • +1
    Хороший программист никогда не ставит комментариев в коде, что писалось с трудом, должно пониматься с трудом ©
  • +1
    Хороший программист из каждого класса делает Синглтон.
  • +2
    А если вы флешер, обязательно разносите весь ваш код по кадрам, что бы заказчик понял, как много работы вы проделали.
    • 0
      >А если вы флешер…

      … и пишете клиент-серверное приложение, засуньте ВСЮ логику внутрь switch-case внутри цикла разбора пришедшего xml беганьем по нодам.

      switch-case лучше седалать с пятью уровнями вложенности и ничего не выносить в функции
  • 0
    Спасибо, возьмем на вооружение :)
  • 0
    Обязательно выполняйте SQL запросы прямо в HTML-шаблоне — это прибавит вашей работе монументальности.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Добавьте к третьему пункту:
    ОБЯЗАТЕЛЬНО используйте разные имена для переменных пришедших из GET и POST запросов.
  • +2
    Пишите все имена с маленькой буквы, особенно имена классов, а потом создавайте переменные с таким же именем: user user = new user(); Только представьте сколько времени можно сэкономить забыв про клавишу Shift, а потом потратить его на дублирование функциональности!
  • +2
    Простите что поднял тему, но все-таки… добавлю пару пунктов заказчиков, из которых и вытекает подобное «нытье»… :)

    3. Вы заплатили 150$ за сайт, требуйте документацию кода, исходники дизайна, хостинг и техническое сопровождение ресурса минимум на 5 лет.
    2. Никогда не обращайтесь к профессионалам, есть ведь Вася Пупкин, который сделает все за 150$;
    1. Обращайтесь к профи «все в одном», ведь если один человек делает сайт, значит он лучше всех будет понимать что от него требуется, дизайн, верстка, программирование, и еще только он один сможет вывести Вас на топовые места в поисковиках.
    0. Индусы — делают все дешевле, чем Вася Пупкин, поэтому надо еще торговаться, ведь Вы можете нанять их.

    Сумбурно, но тему вы поняли…
  • 0
    ) Да уж, Vertex, +1. :)
    Насчет 7 пункта можно поспорить. Я, бывает, оставляю «мертвый» код. Или 10 раз переспрашиваю прежде, чем удалить. Бывали красавцы, которые сначала заявляют, что та или иная функция больше не нужна, а через пару недель резко передумывали ) Очень весело потом сидеть с git cherry-pick и ковыряться в логе коммитов…
  • +1
    Каждая функция или метод непременно должны иметь как минимум три точки выхода:
    — первый return пусть возвращает boolean
    — второй — integer
    — третий — структуру.
    Не забываем про Exception'ы!

    И, чтобы разработчики использующие и поддерживающие этот код окончательно погрузились в транс и нашли путь к просвещению, функция должна возвращать сообщение об ошибках во всех этих четырёх форматах… Например: false, -1, {code: 2345, msg: «Shit happens!»}, (предложите ещё три способа), etc…

    ***

    И помните, каждая функция может определить, что ей сейчас делать путём тонкого исследования call stack'a!

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.