Детские

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

1. Невнимание к деталям. Едва ли не основным признаком профессионала является внимание к деталям. В профессиональном приложении вы никогда не увидите ничего из ниже перечисленного:
• Недоформатирование текстов/Недовыравнивание элементов форм. Куски лейбочек, который вылезают за панели; кнопки, которые перекрывают лейбы; тексты, которые уползают за край формы.
• Отсутствие единообразия в интерфейсе, форматировании тектов, расположении форм. Это тот случай, когда лучше «безобразно, но единообразно». Это же, кстати, отличает айтишников от всех остальных при использовании MS Word: айтишники используют стили, и потом могут легко менять вид документа, изменяя стили, а остальные каждый элемент форматируют вручную и при необходимости изменить вид заголовка второго уровня переформатировывают все заголовки 2го уровня в доке.
• Неучитывание возможности изменения размеров формы. Самый обычный вариант тут — просто забыть о том, что формы могут меняться, забыть установить значения минимальной и максимальной ширины и высоты. Самый некрасивый и неюзабельный — задать абсолютную привязку ко всем сторонам формы, так что контролы наедут друг на друга при её увеличении. Также часто забывают запретить “распахивать” окно, хотя запрещают “ресайз”.
• Использование названий контролов, которые за вас придумала IDE. Button1, Form2, открытьИзображениеToolStripMenuItem_Click. Этого делать нельзя, т.к. радикально ухудшает читабельность кода, а значит увеличивает стоимость его поддержки. Вообще «неговорящие» названия контролов плохо. Говорящие по-русски — спорно, т.к. часто вы будете писать приложения для заграничных заказчиков, а это означает, что русские названия методов не пройдёт процедуру приёмки исходного кода.
• Сортировка числовых значений по правилам строк. Это часто происходит, когда значения хранятся в виде цифр (15.45), а отображаются в строковом виде (15грн.45коп.). И сортировки выполняются средствами стандартных компонентов. Надо это учитывать и реализовывать сортировки как надо.
2. Смешение парадигм процедурного и объектно-ориентированного программирования. К сожалению, на собеседованиях я очень редко встречаю претендентов, которые бы могли внятно объяснить, чем ООП лучшее. Более того — мало кто может сказать, лучше чем что. Естественно, что не понимая, зачем ООП нужно, оно применяется неправильно.
• Применение ООП для отмазки. Чем применять ООП «для галочки», лучше его не применять вообще, т.к. с одной стороны выглядят эти попытки жалко, а с другой запутывают ваших товарищей, которые ожидают «правильного» использования ООП, раз уж оно вообще использовано.
• Использование «глобальных переменных». Особенно в виде «Form1.condition». Это снижает читабельность кода и является симптомом того, что вы неправильно спроектировали приложение.
• Использование статических методов, для решения бизнес-задачи. Если у вашего класса есть только поведение (методы), но нет свойств (полей), значит, вы неправильно провели анализ предметной области (не всегда, но чаще всего).
3. Неправильные комментарии. Комментарии — это отличный помощник, если их использовать по назначению. Многие игнорируют этот факт.
• Не писать вообще. Cowboy-style. Хорошо, что преподаватели стараются с этим бороться… и порождают следующую проблему.
• Писать очевидные комментарии. Когда что-то делается из-под палки, это всегда делается плохо. Так и тут — особенно умиляют комментарии вида «int a; // объявляем переменную». Выглядит как издёвка (особенно, если через две строчки следует алгоритм без единого комментария с кучей циклов, ифов, break’ов и с несколькими return’ами), а издеваться над сотрудниками (и преподавателями) мало того, что нехорошо, так ещё и чревато.
• Не описывать метод/класс. С этим старается бороться IDE. Не надо ей мешать — она знает, что делает. Автодоки сохраняют время всей команде и вам лично, когда приходит время писать документацию на проект.
4. Неследование code conventions. Стандарты кодирования позволяют вам разобраться в чужом коде (или кому-то в вашем) намного быстрее и легче. Обычно программисты подсознательно следуют какому-то одному стилю, но встречаются и такие у которых 7 пятниц на неделе. В любом случае, я советую явно выбрать подходящий стиль и стараться ему следовать. По умолчанию можно использовать стандарты кодирования pear для php, sun для java и Microsoft для семейства.net.
• Хаотичное форматирование кода. Самый клинический случай, это когда у одного и того же человека разные куски кода отличаются по форматированию. Некоторые даже говорят, что это признак маниакально-депрессивного психоза. Ну или ему просто курсовик помогали писать соседи по общаге
• Каждый член команды использует удобную ему конвенцию. Это менее плохо, но тоже не хорошо. Для работы в команде просто необходимо принять общий стандарт кодирования, иначе это будет не работа в команде, а просто работа над одним проектом.

Детские ошибки можно перечислять и перечислять, но я ограничился только теми ошибками, которые я встретил в ваших работах больше 3х раз.

Поиск по сайту: