О каких худших вещах забывают неопытные разработчики? [закрыто]

15

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

Какие ошибки допускают неопытные разработчики, которые могут привести к разочарованию более опытных разработчиков?

awmckinley
источник
1
Я бы не стал называть безопасность чем-то, что можно было бы включить в «контрольный список» - безопасность должна рассматриваться на всех уровнях проекта, а не добавляться как запоздалая мысль. Функции безопасности! = Функции безопасности!
Билли ОНил
Возможно, «контрольный список» подразумевает неправильную вещь. Я не ищу список вещей для размышления в конце разработки; Мне интересно , какие вещи следует рассматривать , как вы разрабатываете приложение. У вас есть предложение, как я мог бы сформулировать свой вопрос?
awmckinley
@awmckinley: Тогда ваш вопрос «как мне разработать приложение», но этот вопрос слишком широк, чтобы отвечать за него.
Билли ОНил
@Billy ONeal: только что отредактировал мой вопрос. Это имеет больше смысла?
awmckinley
1
Это имеет больше смысла, но, к сожалению, он все еще не требует большего, чем просто список лучших практик. Конструктивные вопросы действительно должны касаться конкретных проблем или, по крайней мере, требовать, чтобы ответы были более чем однострочными самонадеянными замечаниями.
Ааронаут

Ответы:

12

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

  • Проверка в коде, который нарушает сборку
  • Не использовать повторно код, который уже есть
  • Делать все по-своему, а не так, как все - что делает обслуживание дорогим

Это не значит, что их код не работает совершенно изолированно, но они больше не работают изолированно.

Garry
источник
+1: по сути, это те проблемы, с которыми вы сталкиваетесь. Младший кодер может плохо кодировать, но некоторые опытные тоже плохо кодируют. Основным отличием являются такие предметы.
gbjbaanb
8
  1. Тесты.
  2. Тесты.
  3. Больше тестов.
  4. Управления источником
  5. Налоги соответствуют любой программе, на которую вы ориентируетесь.

В Windows эти налоги :

  • Работа с средами с высоким разрешением
  • Перемещаемые профили пользователей
  • Быстрое переключение пользователей
  • Удаленный рабочий стол (например, вы не хотите использовать двойную буферизацию, когда работает RDP
  • Приятно играть с Hierarchical Storage Management
  • Несколько мониторов
  • 64-битная Windows

Практически на каждой платформе вам придется иметь дело с:

  • Unicode
  • локализация
  • Управление питанием
Билли ОНил
источник
Прости, Билли. Может быть, я не совсем понял, как я задал свой вопрос: я не особо ищу практики разработки (например, контроль версий). Я думаю, что это было довольно хорошо освещено в разделе Что бы вы добавили в этот контрольный список проектов разработки программного обеспечения? , Раздел "налоги" определенно полезен, хотя.
awmckinley
3
@awmckinley: причина, по которой я привожу управление исходным кодом, заключается в том, что вы не сможете эффективно управлять релизами, если у вас не будет нескольких руководителей разработки, даже если вы являетесь единственным разработчиком. Вам нужно думать о выпуске n + 1, даже когда вы работаете над выпуском n.
Билли ОНил
5

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

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

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

Саймон Уитакер
источник
3

Действительно широкий вопрос; ответить подробно это ... несколько книг.

Вот общий контрольный список определения систем, чтобы вы начали -

  • Каковы критические ресурсы в системе и как могут изменяться требования к ним?
  • Каковы возможности производительности системы и как они могут расти?
  • Какие области требований могут стать ненужными и устраняемыми?
  • Есть ли необходимость иметь разные версии системы с разными возможностями?
  • Каковы последствия для трудовых и компьютерных ресурсов, если выявленные изменения произойдут?
  • Какое влияние новая система окажет на существующие операционные системы?
  • Какие области функций имеют больше шансов потребовать изменений в свете опыта работы с системой?
  • Кто будущие пользователи системы?
  • Каковы будущие сопровождающие системы?
  • Какие будущие улучшения, которые будущие пользователи системы могут определить как вероятные?
  • Как система вписывается в общие планы пользователя и как они должны развиваться?
Стивен А. Лоу
источник
1

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

И как быстро вы сможете восстановить свою машину для разработки?

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

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

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

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

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

gbjbaanb
источник
1

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

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

Поскольку вы спрашивали худшие вещи, то мой ответ таков:

  1. Забыл подумать о дезинфекции машины разработки от программ-шпионов, вредоносных программ и троянских вирусов.
  2. Забыл подумать о регулярном сохранении резервных копий в безопасных хранилищах в разных географических точках.
кспорт
источник
0

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

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

Калеб Хуитт - Джуитт
источник