кодирование не вводит

Это занимает время для написания кода. Большую часть времени в окне редактора, Вы просто смотрите на код, не на самом деле вводя. Не как часто, но вполне часто, Вы удаляете то, что Вы записали. Или перемещение от одного места до другого. Или переименование.

Если Вы стучите далеко на клавиатуре в течение долгого времени, Вы делаете что-то не так.

Заключение: Количество строк кода, записанных в день, не является линейным измерением производительности программистов как программист, который пишет, 100 строк за день довольно вероятно лучший программист затем тот, который пишет 20, но тот, который пишет 5000, является, конечно, плохим программистом

Оценки для меня, не для Вас

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

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

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

Например -

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

Если оценки будут только для планирования затем, то мы будем все работать к 5 дням и объяснять маленький шанс проблемы, должен он возникать.

Однако - при встрече той оценки требуется как обещание доставки, какую оценку делают Вы думаете, дан?

Если премия или обеспеченность работой разработчика зависят от встречи оценки, Вы думаете, что они высказывают свое самое точное предположение или то, которое они являются самыми уверенными, что встретятся?

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

Не используйте сохраненный procs в своей базе данных.

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

Этот определенно спорен. Каждый раз, когда я поднимаю его, люди разрывают меня.

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

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

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

Как насчет этого:

Сборщики "мусора" на самом деле повреждают производительность программистов и делают утечки ресурсов тяжелее, чтобы найти и зафиксировать

Обратите внимание, что я говорю о ресурсах в целом и не только памяти.

Использование хранимых процедур

Если Вы не пишете большую процедурную функцию, состоявшую из SQL-запросов одноразового использования, переместите свои хранимые процедуры базы данных и в управление версиями.

Мое спорное мнение? Java не сосет только Java, который делает API. Почему библиотеки Java настаивают на том, чтобы мешать делать простые задачи? И почему, вместо того, чтобы фиксировать API, они создают платформы, чтобы помочь управлять шаблонным кодом? Это мнение может относиться к любому языку, который требует, чтобы 10 или больше строк кода считали строку из файла.

Подавляющее большинство разрабатываемого программного обеспечения не вовлекает конечного пользователя при сборе требований.

Обычно это - просто некоторые менеджеры, которые обеспечивают 'требования'.

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

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

У большинства разработчиков нет подсказки

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

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

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

А-ч хорошо... жизнь несправедлива в сообществе IT, и я буду предпринимать шаги для игнорирования таких людей в будущем. Ура!

Явный self в объявлениях метода Python плохое проектное решение.

Вызовы метода получили синтаксический сахар, но объявления не сделали. Это - текучая абстракция (дизайном!), который вызывает раздражающие ошибки, включая ошибки периода выполнения с очевидной ошибкой диапазона в количестве, о котором сообщают, аргументов.

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

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

Мой:

Долгие операторы переключения являются Вашими друзьями.В самом деле. По крайней мере, в C#.

Люди склонны избегать, и обескураживать других для использования долгих операторов переключения beause они "unmanagable", и "имеют плохие рабочие характеристики".

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

Ограбьте Щуку, записал: "Данные доминируют. Если Вы выбрали правильные структуры данных и организовали вещи хорошо, алгоритмы почти всегда будут самоочевидны. Структуры данных, не алгоритмы, являются центральными к программированию".

И с этих дней любые серьезные данные находятся в миллионах записей, я удовлетворяю то хорошее моделирование данных, самый важный навык программирования (использовать ли ли rdbms или что-то как sqlite или амазонка simpleDB или Google appengine хранение данных.)

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

Случайный набор афоризмов Cook...

• Самый твердый язык для изучения является секундой.

• Самая твердая ОС для изучения является второй - особенно, если первым был универсальный компьютер типа IBM.

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

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

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

• Никакая ОС никогда не будет стабильна, если это не использует аппаратное управление памятью.

• Низкоуровневое системное программирование очень, намного легче, чем программирование приложений.

• Программист, у которого есть любимый язык, просто играет.

• Запишите руководство пользователя СНАЧАЛА!

• Политика и процедура предназначаются для тех, кто испытывает недостаток в инициативе работать иначе.

• (Кредо Подрядчика): Tell'em, в чем они нуждаются. Give'em, что они хотят. Удостоверьтесь, что проверка очищается.

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

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

• Вы можете piddle вокруг немного с небольшими блоками кода около начала испытать некоторые идеи, но в целом каждый не начинает кодировать всерьез, пока Вы НЕ ЗНАЕТЕ, как целая программа или приложение будут размеченными, и Вы ЗНАЕТЕ, что все это собирается работать ТОЧНО, как рекламируется. Для большинства проектов, по крайней мере, с определенной степенью сложности я обычно заканчиваю тем, что тратил 60 - 70 процентов времени впереди просто проникающие идеи.

• Поймите, что программирование имеет мало общего с языком и всем, чтобы сделать с алгоритмом. Все те острота geegaws с незабываемыми акронимами, которые люди придумали за эти годы, являются просто различными способами освежевать кошку реализацию. Когда Вы снимаете весь OOPiness, RADology, Методологию разработки 37 и Лучшую практику 42, все еще необходимо иметь дело с основными стандартными блоками:

  • присвоения
  • условные выражения
  • повторения
  • поток управления
  • Ввод-вывод

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

• Начало программистов работает с маленькими блоками кода. Как они приобретают опыт, они работают с когда-либо все больше большими блоками кода.
  Поскольку они получают еще больше опыта, они работают с маленькими блоками кода.

SQL мог и должен был быть добит большего успеха. Поскольку его исходная спецификация была ограничена, различные уличные торговцы расширяли язык в различных направлениях в течение многих лет. SQL, который записан для MS-SQL, отличается, чем SQL для Oracle, IBM, MySQL, Sybase, и т.д. Другие серьезные языки (берут C++, например) были тщательно стандартизированы так, чтобы C++, записанный в соответствии с одним компилятором, обычно компилировал неизмененный под другим. Почему SQL, возможно, не был разработан и стандартизирован лучше?

HTML был серьезно поврежденным выбором как языком дисплея браузера. Мы провели годы, расширяя его через CSS, XHTML, JavaScript, Ajax, Flash, и т.д. для создания применимого UI, и результат все еще не так хорош как основное приложение Windows толстого клиента. Плюс, компетентный веб-программист теперь должен знать три или четыре языка для создания достойного UI.

О, да. Венгерская запись является отвращением.

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

Кодирование - это искусство

Некоторые люди думают, что кодирование - это искусство, а другие думают, что кодирование - это наука.

Фракция «науки» утверждает, что целью является получение оптимальный код для ситуации, тогда кодирование - это наука о том, как получить этот оптимум.

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

Рекурсия - это весело.

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

Операторы "больше, чем" (>,> =) должны быть устаревшими

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

Рассмотрим общепринятое математическое обозначение «диапазона»: 0 <= i <10

Это легко аппроксимировать в коде теперь, и вы привыкнете видеть идиому, в которой переменная повторяется в середине, к которой присоединяется &&:

if (0 <= i && i < 10)
    return true;
else
    return false;

Когда вы привыкнете к этому шаблону, вы больше никогда не будете смотреть на глупости, подобные

if ( ! (i < 0 || i >= 9))
    return true;

, так же снова.

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

Кроме того, предпочтение operator < закреплено в стандартах C ++. В некоторых случаях operator = определяется в терминах него! (как ! (a )