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

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

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

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

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

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

1. Тесты.
2. Тесты.
3. Больше тестов.
4. Управления источником
5. Налоги соответствуют любой программе, на которую вы ориентируетесь.

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

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

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

• Unicode
• локализация
• Управление питанием

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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