5 основных ошибок программистов
1. Теперь этот ёжик будет жить с нами ¶
Сын-выпускник школы говорит вечером своему отцу:
- Папа, у меня сегодня выпускной, будем пить, гулять, домой приду поздно, пьяный, ты не ругайся, пожалуйста.
Утром сынуля просыпается-голова болит, весь в синяках, ссадинах, папаша рядом с кроватью стоит.
Сын:
- Папа, я же просил тебя вчера, зачем ты меня избил?
Папа:
- Когда ты вчера в задницу пьяный приперся домой в три часа ночи, и проломил входную дверь-я стерпел,
когда ты сломал унитаз и облевал весь туалет - я стерпел, но когда ты посредине комнаты наложил кучу говна,
воткнул в нее спички и сказал, что этот ёжик будет с нами жить - мои нервы не выдержали......
Программисты очень не любят удалять свои говнорешения. Они придумывают всякие оправдания, ухищрения только для того, чтобы оставить какой-то кусок кода в проекте. Почему? Потому что:
- "Я весь день писал эти 10 строк кода. Я не буду их удалять!"
- "Тут уже столько кода написано, куда мы это денем?"
- "Это не говнокод! Я понимаю, что там написано!"
И ещё много причин, чтобы оставить "ёжика" в проекте. В конечном счёте это увеличивает технический долг и вязкость кода.
НЕ НАДО ТАК!
Помните, что исправить "ёжика" в самом начале проще, чем когда проект запустится и начнёт работать.
2. Я не буду рисовать блок-схему/диаграмму, тут и так всё понятно ¶
Если программист не может нарисовать процесс, который он пытается воплотить в коде, то ... и так всё понятно. Он родит "ёжика", к которому привяжется, как к родному, и оставит жить с нами...
РЕБЯТА, рисовать блок-схемы НУЖНО! Не можете нарисовать? Значит, не понимаете решение задачи. Не можете нарисовать простую и понятную диаграму? Значит и в коде будет мешанина.
Нужно понимать, что есть разные уровни блок-схем. Вам нужен уровень проектирования, где показаны основные компоненты системы и стрелочками бизнес-процессы. Пример:
Блок-схемы уровня проектирования нужны, чтобы любой участник проекта мог легко понять, что вы делаете и зачем. Именно поэтому польза будет только от простых схем, сложные только запутывают.
Блок-схемы уровня реализации (UML-диаграммы) обычно бесполезны из-за высокой сложности, вот на них можно "забить".
3. Я не я, хата не моя, моя хата с краю, ничего не знаю ¶
Господа программисты, берите, пожалуйста, на себя ответственность за код, который вы пишете. Это значит:
- Не надо говорить, что этот кусок говнокода вы написали "потому что так сказали" (вам ставят задачи, а говнокод вы пишете сами).
- Прежде, чем хвататься за клавиатуру, досконально разберитесь в задаче (схемы, например, порисуйте), напишите пару тестов.
- Если уж накосячили, то так и говорите: "Да, это косяк, сейчас исправим".
Одну и ту же задачу можно решить десятком способов. Найти оптимальный способ - задача программиста. Рассматривайте разные варианты решения ДО того, как писать код, чтобы потом не говорить: "да, этот ёжик теперь будет жить с нами".
4. Как в задаче написано, так и делаю ¶
Медицинская сестра катит коляску с пациентом по больничному
коридору, больной жалобно спрашивает:
- А может, лучше в отделение реанимации?
Сестра сердито отвечает:
- Больной, не занимайтесь самолечением! Врач сказал в морг,
значит в морг!
Перед тем, как бросаться за задачу, подумайте, а насколько правильно она поставлена? Может быть её вообще НЕ НУЖНО делать. Люди, которые пишут задачи, тоже люди, а значит могут ошибаться. Ещё подумайте, какую проблему вы решите, сделав эту задачу. Может быть есть другой способ?
5. Я только пишу код, у нас 100% покрытие юнитами, континиус интегрейшин, все дела, а вы идите в... к аналитикам ¶
Господа, товарищи, комрады, не забывайте, пожалуйста, что код вы пишете для ЛЮДЕЙ! А не чтобы покрыть его тестами. Конечными потребителями вашего продукта всегда являются люди (менеджеры, покупатели, другие программисты). Ориентируйтесь на людей, думайте, как сделать удобно им, а не тестам.
Если вам говорят, что "ваша система говно", принюхайтесь, может так оно и есть.
Послесловие ¶
Любите проекты, любите людей, которые ими пользуются. А код подтянется, если не бояться признавать ошибки и стараться исправлять их, делать решения проще и чище.