Что вы наиболее противоречивое мнение программирования?

Не стесняйся, брось исключение. Исключения являются вполне допустимым способом оповещения о сбое и намного более понятны, чем любая система с кодом возврата. «Исключительный» не имеет ничего общего с тем, как часто это может происходить, и не связан с тем, что класс считает нормальными условиями выполнения. Бросать исключение, когда происходит деление на ноль, просто прекрасно, независимо от того, как часто это может происходить. Если проблема вероятна, защитите свой код, чтобы метод не вызывался с неверными аргументами.

Это не инструменты, это вы

Всякий раз, когда разработчики пытаются сделать что-то новое, например, создавать диаграммы UML, диаграммы любого рода, управление проектами, они сначала ищут идеальный инструмент для решения. эта проблема. После бесконечных поисков неуместного инструмента их мотивация истощается. Осталось только жалобы на отсутствие полезного программного обеспечения. Это понимание того, что план, который должен быть организован, умер в отсутствие какого-либо программного обеспечения.

Ну, только вы сами имеете дело с организацией. Если вы привыкли к организации, вы можете сделать это с помощью программного обеспечения или без него (а большинство обходятся без него). Если вы не привыкли организовываться, никто не сможет вам помочь.

Таким образом, «отсутствие правильного программного обеспечения» - это самое простое оправдание неорганизованности вообще.

Сборка мусора переоценена

Многие считают, что сборка мусора в Java - одно из самых больших улучшений по сравнению с C ++. Я считаю, что введение в лучшем случае очень незначительное, хорошо написанный код C ++ выполняет все управление памятью в нужных местах (с помощью таких методов, как RAII), поэтому сборщик мусора не требуется.

Отражение не имеет места в производственном коде

Отражение разрывает статический анализ, включая инструменты рефакторинга и проверку статического типа. Отражение также нарушает обычные предположения разработчиков о коде. Например: добавление метода в класс (который не затеняет какой-либо другой метод в классе) никогда не должен иметь никакого эффекта, но когда используется отражение, другой фрагмент кода может «обнаружить» новый метод и принять решение назови это. Фактически определить, существует ли такой код, трудно.

Я думаю, что нормально использовать рефлексию и тесты, а также в генераторах кода.

Да, это означает, что я стараюсь избегать рамок, которые используют рефлексию. (очень плохо, что Java не имеет надлежащей поддержки метапрограммирования во время компиляции)

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

Все это знают, но по какой-то причине практика все еще сохраняется!

Реляционные базы данных - пустая трата времени. Вместо этого используйте объектные базы данных!

Поставщики реляционных баз данных пытаются обмануть нас, полагая, что единственное масштабируемое, постоянное и безопасное хранилище в мире - это реляционные базы данных. Я сертифицированный администратор баз данных. Вы когда-нибудь пытались оптимизировать запрос и не знали, что происходит? Реляционные базы данных не позволяют вам создавать собственные пути поиска, когда они вам нужны. Вы отдаете большую часть контроля над скоростью вашего приложения в руки людей, которых вы никогда не встречали, и они не настолько умны, как вы думаете.

Конечно, иногда в хорошо поддерживаемой базе данных они предлагают быстрый ответ на сложный запрос. Но цена, которую вы платите за это, слишком высока! Вы должны выбирать между написанием необработанного SQL каждый раз, когда хотите прочитать запись ваших данных, что опасно. Или используйте объектный реляционный картограф, который добавляет больше сложности и вещей вне вашего контроля.

Что еще более важно, вам активно запрещается придумывать интеллектуальные алгоритмы поиска, потому что каждый проклятый обходной путь к базе данных стоит вам около 11 мс. Это слишком много. Представьте, что вы знаете этот алгоритм суперграфа, который ответит на конкретный вопрос, который в свое время может даже не выразиться в SQL !, Но даже если ваш алгоритм линейный, а интересные алгоритмы не линейные, не забудьте объединить его с реляционной базой данных, поскольку перечисление большой таблицы займет у вас часы!

Сравните это с SandstoneDb или Gemstone для Smalltalk! Если вы в Java, попробуйте db4o.

Итак, мой совет: используйте объектную базу данных. Конечно, они не идеальны, и некоторые запросы будут выполняться медленнее. Но вы будете удивлены, сколько будет быстрее. Потому что загрузка объектов не потребует всех этих странных преобразований между SQL и данными вашего домена. И если вам действительно нужна скорость для определенного запроса, в объектных базах данных есть оптимизатор запросов, которому вы должны доверять: ваш мозг.

На своем рабочем месте я пытался представить больше привычек разработки Agile / XP. Непрерывный дизайн - это то, что я чувствовал больше всего сопротивления на данный момент. Возможно, я не должен был формулировать это как «давайте соберем всю команду архитекторов и застрелим их» ...;)

Emacs лучше

Задача программирования - это весело, пока она невозможна, до того момента, когда вы убедите себя, что сможете успешно ее решить.

Именно поэтому, я полагаю, именно поэтому многие из моих проектов заканчиваются наполовину в папке, которая называется «до _ быть _ продолжение» ».

Не допускается, чтобы персонал, не занимающийся вопросами развития, управлял персоналом, занимающимся вопросами развития.

Исправление: Персонал с нулевым опытом развития не должен иметь права управлять персоналом по развитию.

Вам не всегда нужна база данных.

Если вам нужно хранить менее нескольких тысяч «вещей» и вам не нужна блокировка, плоские файлы могут работать и лучше во многих отношениях. Они более портативны, и вы можете отредактировать их вручную в крайнем случае. Если у вас есть правильное разделение между вашими данными и бизнес-логикой, вы можете легко заменить плоские файлы базой данных, если это понадобится вашему приложению. И если вы разрабатываете это с учетом этого, это напоминает вам о надлежащем разделении между вашими данными и бизнес-логикой.

-
Bmb

Мое противоречивое мнение: объектно-ориентированное программирование - это абсолютно худшее, что когда-либо случалось в области разработки программного обеспечения.

Основная проблема с ООП - это полное отсутствие строгого определения, с которым все могут согласиться. Это легко приводит к реализациям, в которых есть логические дыры, или к языку, подобному Java, который придерживается этой причудливой религиозной догмы о том, что означает ООП, в то же время вынуждая программиста выполнять все эти искажения и «шаблоны проектирования», просто чтобы обойти ограничения конкретная система ООП.

Итак, ООП вводит программиста в заблуждение, что он делает такой огромный прирост производительности, что ООП является каким-то «естественным» способом мышления, в то же время заставляя программиста печатать множество ненужных шаблонов.

Тогда, поскольку никто не знает, что на самом деле означает ООП, мы тратим огромное количество времени на мелкие споры о том, является ли язык X или Y «действительно ООП» или нет, какие причудливые особенности языка грузинского культа являются абсолютно «существенными» для языка считаться «действительно ООП».

Вместо того, чтобы требовать, чтобы этот язык или этот язык был «по-настоящему упертым», мы должны смотреть на то, какие языковые особенности показаны экспериментом, чтобы фактически повысить производительность, вместо того, чтобы пытаться заставить его быть некоторый воображаемый идеальный язык или даже принуждающий наши программы соответствовать какому-то платоническому идеалу «действительно объектно-ориентированной программы».

Вместо того, чтобы настаивать на том, что наши программы соответствуют какому-то платоническому идеалу «Истинно объектно-ориентированного», как насчет того, чтобы сосредоточиться на соблюдении хороших инженерных принципов, облегчении чтения и понимания нашего кода и использовании возможностей языка, который продуктивным и полезным, независимо от того, достаточно ли они "ООП" или нет.

Я много работаю в ASP.NET / VB.NET и считаю ViewState абсолютным кошмаром. Он включен по умолчанию в большинстве полей и вызывает большое количество закодированных данных в начале каждой веб-страницы. Чем больше становится страница с точки зрения элементов управления на странице, тем больше становятся данные ViewState. Большинство людей не обращают на это внимания, но оно создает большой набор данных, который обычно не имеет отношения к задачам, выполняемым на странице. Вы должны вручную отключить эту опцию на всех элементах управления ASP, если они не используются. Это либо так, либо есть пользовательские элементы управления для всего.

На некоторых страницах, с которыми я работаю, половина страницы состоит из ViewState, и это действительно позор, поскольку, вероятно, есть лучшие способы сделать это.

Это только один небольшой пример, который я могу представить с точки зрения языка / технологии. Это может быть спорным.

Кстати, вы можете захотеть отредактировать голосование в этой теме, оно может сильно нагреться;)

Хороший программист ненавидит кодирование

Аналогично «Хороший программист - ленивый программист» и «Меньше кода - лучше». Но, следуя этой философии, мне удалось написать приложения, которые в противном случае могли бы использовать в несколько раз больше кода (и занимать в несколько раз больше времени разработки). Короче говоря: подумайте, прежде чем код. Большинство частей моих собственных программ, которые впоследствии вызывали проблемы, были частями, которые мне действительно нравилось кодировать, и поэтому у меня было слишком много кода, и, следовательно, они были плохо написаны. Так же, как этот абзац.

Хороший программист - это дизайнер

Я обнаружил, что в программировании используются те же концепции, что и в дизайне (как и в тех же концепциях дизайна, которые используются в искусстве). Я не уверен, что большинство других программистов находят то же самое правдой; может быть, это правый мозг / левый мозг. Слишком много программ ужасно, от их кода до пользовательского интерфейса командной строки и графического пользовательского интерфейса, и ясно, что разработчики этих программ на самом деле не были дизайнерами.

Хотя корреляция может и не подразумевать причинно-следственную связь, я заметил, что по мере того, как я стал лучше в дизайне, я стал лучше в кодировании. Один и тот же процесс приведения вещей в порядок и и для правильного восприятия можно и нужно использовать в обоих местах. Если код не чувствует себя хорошо , это вызовет проблемы, потому что либо а) он не верен, либо б) вы будете считать, что он работает так, как «чувствует себя хорошо» позже, и тогда опять не правы.

Искусство и код не находятся на противоположных концах спектра; код может быть использован в искусстве и сам может быть формой искусства.

Отказ от ответственности: к сожалению, не весь мой код хорош или «прав»,

Не комментируйте свой код

Комментарии не являются кодом, и поэтому, когда все меняется, очень легко не изменить комментарий, который объяснил код. Вместо этого я предпочитаю рефакторировать дерьмо из кода до такой степени, что нет причин для комментариев. Пример:

if(data == null)  // First time on the page

to:

bool firstTimeOnPage = data == null;
if(firstTimeOnPage)

Единственный раз, когда я действительно комментирую, это когда это TODO или объяснение почему

Widget.GetData(); // only way to grab data, TODO: extract interface or wrapper

Это нормально, быть Мортом

Не каждый программист "рок-звезды"; некоторые из нас делают это, потому что это хорошая жизнь, и мы не заботимся обо всех последних причудах и тенденциях; мы просто хотим делать свою работу.

C (или C ++) должен быть первым языком программирования

Первый язык НЕ должен быть легким, он должен быть тем, который настраивает ум студента и готовит его к серьезная информатика.
C идеально подходит для этого, он заставляет студентов думать о памяти и обо всех вещах низкого уровня, и в то же время они могут научиться структурировать свой код (у него есть функции!)

C ++ имеет дополнительное преимущество что это действительно отстой :), таким образом, студенты поймут, почему люди должны были придумать Java и C #

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

Булевы переменные используются для хранения данных, которые могут принимать только два возможных значения. Проблемы, возникающие при их использовании, часто упускаются из виду:

• Программисты часто не могут правильно определить, когда какой-то фрагмент данных должен иметь только два возможных значения
• Люди, которые инструктируют программистов, что делать такие как программные менеджеры или те, кто пишет спецификации, которым следуют программисты, часто тоже не могут правильно идентифицировать это
• Даже если часть данных правильно идентифицирована как имеющая только два возможных состояния, эта гарантия может не сохраниться в будущем ,

В этих случаях использование булевых переменных приводит к запутанному коду, который часто можно предотвратить с помощью перечислений.

Пример

Скажем, программист пишет программное обеспечение для автосалона, который продает только легковые и грузовые автомобили. Программист разрабатывает тщательную модель бизнес-требований для своего программного обеспечения. Зная, что единственными проданными типами транспортных средств являются легковые и грузовые автомобили, он правильно определяет, что может использовать логическую переменную внутри класса Vehicle, чтобы указать, является ли транспортное средство легковым или грузовым автомобилем.

class Vehicle {
 bool isTruck;
 ...
}

Программное обеспечение написано так, что когда isTruck является истиной, транспортное средство является грузовиком, а когда isTruck является ложным, транспортное средство является автомобилем. Это простая проверка, выполняемая много раз по всему коду.

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

Как программист должен это реализовать? isTruck является логической переменной, поэтому она может содержать только два состояния. Он может изменить его с логического на другой тип, который допускает много состояний, но это нарушит существующую логику и, возможно, не будет обратно совместимым. Самым простым решением с точки зрения программиста является добавление новой переменной, чтобы представить, является ли транспортное средство мотоциклом.

class Vehicle {
 bool isTruck;
 bool isMotorcycle;
 ...
}

Код изменяется так, что когда isTruck истинно, транспортное средство является грузовиком, когда isMotorcycle истинно, транспортное средство является мотоциклом, и когда они оба ложны, транспортное средство является автомобиль.

Проблемы

Есть две большие проблемы с этим решением:

• Программист хочет выразить тип транспортного средства, которое является одна идея, но решение использует две переменные для этого. Кому-то, незнакомому с кодом, будет сложнее понять семантику этих переменных, чем если бы программист использовал только одну переменную, которая полностью определяет тип.
• Решение этой проблемы мотоцикла путем добавления нового логического значения не облегчает программисту работу с такими ситуациями, которые произойдут в будущем. Если дилерский центр начнет продавать автобусы, программист должен будет повторить все эти шаги снова, добавив еще одно логическое значение.

Разработчик не виноват в том, что бизнес-требования его программного обеспечения изменились, что потребовало от него пересмотра существующего кода. Но использование булевых переменных в первую очередь сделало его код менее гибким и трудным для изменения, чтобы удовлетворить неизвестные будущие требования (менее «ориентированные на будущее»). Когда он реализовал изменения самым быстрым способом, код стал труднее читать. Использование логической переменной в конечном итоге было преждевременной оптимизацией.

Решение

Использование перечисления в первую очередь предотвратило бы эти проблемы.

enum EVehicleType { Truck, Car }

class Vehicle {
 EVehicleType type;
 ...
}

Чтобы приспособить мотоциклы в этом случае, все, что должен сделать программист, это добавить Motorcycle в EVehicleType и добавить новую логику для обработки мотоциклетных дел. Нет необходимости добавлять новые переменные. Существующая логика не должна нарушаться. И тот, кто не знаком с кодом, может легко понять, как хранится тип транспортного средства.

Заметки Клиффа

Не используйте тип, который может хранить только два разных состояния, если вы не уверены, что двух состояний всегда будет достаточно. Используйте перечисление, если есть какие-либо возможные условия, при которых в будущем потребуется более двух состояний, , даже если логическое значение будет соответствовать существующим требованиям . [Тысяча сто тридцать два]

Если ваш текстовый редактор не выполняет хорошее завершение кода, вы напрасно тратите время.

Быстрое запоминание тысяч списков аргументов, написания и возвращаемых значений (не говоря уже о классовых структурах и аналогичных сложных организационных моделях) - это задача, на которой компьютеры хороши, а люди (сравнительно) - нет. Я искренне согласен с тем, что немного замедлить себя и избежать культа гаджетов и функций - это отличный способ повысить эффективность и избежать ошибок, но просто бесполезно тратить 30 секунд на излишнюю охоту по исходному коду или документам, когда вы можете потратить ноль .. особенно если вам просто нужно написание (что чаще, чем нам хотелось бы признать).

Конечно, если нет редактора, который предоставляет эту функциональность для вашего языка, или задача достаточно проста для выполнения за время, необходимое для загрузки более тяжелого редактора, никто не скажет вам, что Eclipse и 90 плагинов это правильный инструмент. Но, пожалуйста, не говорите мне, что способность HJKL обходить вас, как будто это 1999 год, действительно экономит вам больше времени, чем запускать escape каждый раз, когда вам нужна сигнатура метода ... даже если вы чувствуете себя менее "хакерским", делая это.

Мысли?

Клиент не всегда прав.

В большинстве случаев, с которыми я имею дело, клиент - владелец продукта, иначе говоря, «бизнес». Слишком часто разработчики просто кодируют и не пытаются обеспечить свою долю в продукте. Существует слишком большое заблуждение, что ИТ-отдел - это «компания внутри компании», что является полным мусором.

Я чувствую, что моя роль заключается в том, чтобы помочь бизнесу выразить свои идеи - при обоюдном понимании, что я заинтересован в понимании бизнеса, чтобы я мог предоставить наилучший возможный опыт. И этот маршрут подразумевает, что будут времена, когда владелец продукта просит что-то, что, по его / ее мнению, является следующей революцией в вычислительной технике, оставляя кому-либо либо согласиться с этим фактом, либо объяснить более вероятную причину того, почему никто не делает что-то определенное путь. Это взаимовыгодно, потому что владелец продукта понимает мысль, которая входит в продукт, а команда разработчиков понимает, что они делают больше, чем просто сшивают код.

Это фактически начало вести нас по пути повышения производительности. Как? Поскольку связь улучшилась из-за разногласий по обеим сторонам таблицы, более вероятно, что мы соберемся раньше в процессе и придем к взаимовыгодному решению определения продукта.

Чтобы создавать отличное программное обеспечение, вам нужны как специалисты в предметной области, так и хорошие разработчики.

Сгенерированная документация почти всегда совершенно бесполезна.

Или, как следствие: Вашему API требуется отдельный набор документации для сопровождающих и пользователей.

На самом деле есть два класса людей, которым нужно понимать ваш API: сопровождающие, которые должны понимать мелочи вашей реализации, чтобы быть эффективными в своей работе, и пользователи, которым нужен общий обзор, примеры и подробные сведения о влиянии каждого метода, к которому они имеют доступ.

Я никогда не встречал сгенерированную документацию, которая преуспела ни в одной области. Как правило, когда программисты пишут комментарии к инструментам для извлечения и создания документации, они стремятся к чему-то посередине - просто достаточно деталей реализации, чтобы утомлять и запутывать пользователей, но недостаточно, чтобы значительно помочь сопровождающим, и недостаточно общего обзора, чтобы реальная помощь пользователям.

Как сопровождающий, я бы всегда предпочел бы иметь чистые, четкие комментарии, не смешанные с какой-либо странной разметкой, необходимой вашему инструменту auto-doc, которая скажет мне, почему вы написали этот странный оператор switch так, как вы это делали или какую ошибку исправляет эта кажущаяся избыточной проверка параметров, или что еще мне нужно знать, чтобы на самом деле сохранить код чистым и без ошибок, пока я работаю над ним. Я хочу, чтобы эта информация была прямо в коде рядом с кодом, о котором идет речь, поэтому мне не нужно выслеживать ваш сайт, чтобы найти его в состоянии, пригодном для чтения.

Как пользователь, я всегда предпочел бы иметь тщательный, хорошо организованный документ (набор веб-страниц был бы идеальным, но я бы тоже согласился на хорошо структурированный текстовый файл). ) рассказывая, как устроен ваш API, какие методы делают и как я могу достичь того, что я хочу использовать для вашего API. Я не хочу видеть внутри себя, какие классы вы написали, чтобы позволить мне выполнять работу, или файлы, в которых они находятся. И я, конечно же, не хочу загружать ваш источник, чтобы точно понять, что происходит за кулисами. Если бы ваша документация была достаточно хорошей, мне бы не пришлось.

Так или иначе, я так вижу.

Мнение: рамки и компоненты третьей части следует использовать только в качестве крайней меры.

Я часто вижу, как программисты сразу выбирают среду для выполнения задачи, не изучая базовый подход, который требуется для работы. Что-то неизбежно сломается, или мы найдем ограничение, которое мы не учли, и мы сразу же застрянем, и нам придется переосмыслить основную часть системы. Рамки хороши в использовании, если они тщательно продуманы.

Самое спорное мнение программирования является то, что найти проблемы с производительностью не о измерения , речь идет о захвата .

Если вы охотитесь на слонов в комнате (в отличие от мышей), вам нужно знать, насколько они велики? НЕТ! Все, что вам нужно сделать, это посмотреть. Именно их величие позволяет легко их найти! Нет необходимости сначала их измерять.

Идея измерения была обычной мудростью, по крайней мере, со времен статьи gprof ( Сьюзен Л. Грэм и др., 1982 ) *, когда все это время находилось прямо у нас под носом. был очень простым и прямым способом найти код, который стоит оптимизировать .

В качестве небольшого примера, вот как это работает. Предположим, вы взяли 5 выборок случайного времени из стека вызовов и случайно увидели конкретную инструкцию на 3 из 5 выборок. Что это говорит вам?

.............   .............   .............   .............   .............
.............   .............   .............   .............   .............
Foo: call Bar   .............   .............   Foo: call Bar   .............
.............   Foo: call Bar   .............   .............   .............
.............   .............   .............   Foo: call Bar   .............
.............   .............   .............   .............   .............
                .............                                   .............

Он говорит вам, что программа тратит 60% своего времени на работу, запрошенную этой инструкцией . Удаление его удаляет эти 60%:

...\...../...   ...\...../...   .............   ...\...../...   .............
....\.../....   ....\.../....   .............   ....\.../....   .............
Foo: \a/l Bar   .....\./.....   .............   Foo: \a/l Bar   .............
......X......   Foo: cXll Bar   .............   ......X......   .............
...../.\.....   ...../.\.....   .............   Foo: /a\l Bar   .............
..../...\....   ..../...\....   .............   ..../...\....   .............
   /     \      .../.....\...                      /     \      .............

Примерно.

Если вы можете удалить инструкцию (или вызвать ее намного реже), это примерно в 2,5 раза быстрее. (Обратите внимание - рекурсия не имеет значения - если слон беременен, он не меньше.) Затем вы можете повторять этот процесс, пока вы действительно не приблизитесь к оптимуму.

• Это не требовало точности измерений, синхронизации функций, подсчета вызовов, графиков, сотен выборок, чего-либо такого типичного для профилирования.

Некоторые люди используют это всякий раз, когда у них есть проблемы с производительностью, и не понимают, в чем дело.

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

* Фактически, в этой статье утверждалось, что целью gprof было «помочь пользователю оценить альтернативные реализации абстракций». Он не претендовал на то, чтобы помочь пользователю найти код, требующий альтернативной реализации, на более тонком уровне, чем функции.

Мое второе самое противоречивое мнение - это , или может быть, если бы его не было так трудно понять.

Ковбойские кодеры делают больше.

Я провожу свою жизнь в атмосфере стартапа. Без кодеров Cowboy мы бы тратили бесконечные циклы, чтобы убедиться, что все сделано «правильно».

Как мы знаем, в принципе невозможно предвидеть все проблемы. Ковбойский кодер сталкивается с этими проблемами и вынужден решать их гораздо быстрее, чем тот, кто пытается их предвидеть.

Хотя, если вы кодируете Ковбой, у вас должен быть лучший рефакторинг спагетти, прежде чем кто-то другой должен его поддерживать. ;) Лучшие из тех, кого я знаю, используют непрерывный рефакторинг. Они выполняют множество задач, не тратят время на попытки предсказать будущее, и благодаря рефакторингу это становится поддерживаемым кодом.

Процесс всегда мешает хорошему Ковбою, независимо от того, насколько он проворен.

Чем больше процесса ты вкладываешь в программирование, тем хуже становится код

Я заметил кое-что за 8 или около того лет программирования, и это кажется смешным. Единственный способ получить качество - это нанять качественных разработчиков и убрать из них как можно больше процессов и формальностей. Модульное тестирование, стандарты кодирования, рецензирование кода и т. Д. Только снижают качество, а не повышают его. Это звучит безумно, потому что должно быть наоборот (больше модульного тестирования должно привести к лучшему коду, хорошие стандарты кодирования должны привести к более читаемому коду, обзоры кода должны улучшить качество кода), но это не так.

Я думаю, что это сводится к тому, что мы называем это «Разработка программного обеспечения», когда на самом деле это дизайн, а не разработка вообще.

Некоторые цифры, подтверждающие это утверждение:

От редактора

Программное обеспечение IEEE, ноябрь / декабрь 2001 г.

Количественная оценка мягких факторов

от Стив Макконнелл

...

Ограниченная важность зрелости процесса

... При сравнении проектов среднего размера (100 000 строк кода), проект с худшим процессом потребует в 1,43 раза больше усилий, чем проект. один с лучшим процессом, при прочих равных условиях. Другими словами, максимальное влияние зрелости процесса на производительность проекта составляет 1,43 . ...

... Что не подчеркивает Кларк, так это то, что для программы из 100 000 строк кода несколько ориентированных на человека факторов влияют на производительность больше, чем процесс. ...

... Только факторы, ориентированные на стаж работы (AEXP, LTEX, PEXP) оказывают влияние 3,02. Семь факторов, ориентированных на персонал, вместе (ACAP, AEXP, LTEX, PCAP, PCON, PEXP и SITE § ) оказывают ошеломляющий диапазон влияния 25,8! Этот простой факт объясняет большую часть причины того, что организации, не ориентированные на процессы, такие как Microsoft, Amazon.com и другие влиятельные предприниматели, могут испытать лидирующую в отрасли производительность при кажущемся сокращении процесса. ...

Итог

... Оказывается, что сложность торгового процесса для обеспечения непрерывности работы персонала, опыта в области бизнеса, частных офисов и других ориентированных на человека факторов является разумным экономическим компромиссом , Конечно, лучшие организации одновременно достигают высокой мотивации и сложности процессов, и это является ключевой задачей для любой ведущей организации по разработке программного обеспечения.

§ Прочитайте статью для объяснения этих сокращений.

Хорошо, если ты не знаешь. Но вы уволены, если не можете даже погуглить.

Интернет - это инструмент. Это не делает тебя глупее, если ты учишься у него.

Большинство программистов бесполезны при программировании

(Вы сказали «спорный»)

Я сидел в своем офисе дома, размышляя над какой-то проблемой программирования, и я закончил глядя на мою копию «Полной разборки ПЗУ Spectrum» на моей книжной полке и размышляя:

«Сколько программистов сегодня могут написать код, используемый в ПЗУ Spectrum?»

. те, кто не был знаком с ним, имели базовый язык программирования, который мог выполнять простую двумерную графику (линии, кривые), файловый ввод-вывод и вычисления с плавающей запятой, включая трансцендентные функции, все в 16K кода Z80 (< 5 МГц 8-битный процессор, который не имел FPU или умножение целых чисел). Большинству выпускников сегодня будет сложно написать программу Hello World, которая была такой маленькой.

Я думаю, что проблема в том, что абсолютное количество программистов, которые могли бы это сделать, почти не изменилось, но в процентном отношении оно быстро приближается к нулю. Это означает, что качество написанного кода снижается по мере того, как все больше программистов не соответствуют требованиям.

Там, где я сейчас работаю, есть семь программистов, включая меня. Из них я единственный, кто постоянно обновляется, читая блоги, книги, этот сайт и т. Д. И занимаясь программированием «для удовольствия» дома (моя жена постоянно этим восхищается). Есть еще один программист, который заинтересован в написании хорошо структурированного кода (интересно, он проделал большую работу с использованием Delphi) и реорганизации плохого кода. Остальные, ну, не велики. Поблагодарив об этом, вы могли бы описать их как программистов «грубой силы» - они будут заставлять неуместные решения, пока они не будут работать по моде (например, использование массивов C # с повторяющимся массивом. Изменение размера для динамического добавления элементов вместо использования List).

Так вот, я не знаю, является ли место, в котором я сейчас нахожусь, типичным, хотя с моих предыдущих позиций я бы сказал, что это так. Оглядываясь назад, я вижу общие шаблоны, которые определенно не помогли ни одному из проектов (отсутствие экспертной оценки кода для одного).

Итак, 5 из 7 программистов - мусор.

Skizz

Большинство программистов-консультантов отстой , и им нельзя разрешать писать производственный код.

ИМХО - Вероятно, около 60% или более

Объектно-ориентированное программирование используется слишком часто

Иногда лучшим ответом является простой ответ.