|
1. Мы не правы Программисты зачастую имеют большое эго. Поэтому часто бывает трудно осознать, что мы не правы в чем-то. Я видел много споров относительно архитектуры проектов, где разработчики расхваливают свои идеи. Но, предположим, что мы все неправы. И отличаемся только в степени своих заблуждений.
Очень важно осознать и принять этот факт только один раз и мы будем открыты, чтобы выслушать других и использовать свои идеи, чтобы создать лучшее решение. 2. Все, что может сломаться, ломается Если вы не уверены в чем-то, если вы говорите слово «должно», то у вас проблемы. Есть только одно решение — сделать что-то, чтобы убедиться, что это не сломается. Это может быть тест, отладка или выяснение точных требований. 3. Весь код — дерьмо После 10-ти лет жалоб на дерьмовый код, который меня окружает, я пришел к замечательному выводу — весь код (включая мой) — это дерьмо. Конечно, есть множество степеней дерьмовости кода, но самый лучший код, который я видел было достаточно сложно читать. Это не означает, что усилия сделать код лучше напрасны. Напротив, есть большая разница между лучшим типом кода и худшим. 4. В программе всегда есть баг ВСЕГДА! Вопрос только в том, сколько времени потребуется, чтобы найти баг. 5. Наиболее важная вещь — это клиент Помимо многих прочих вещей клиента не заботят: технологии, которые вы используете в проекте, сколько еще необходимых действий нужно произвести, чтобы приложение было подобающим… или, если обобщить все, если вы используете правильный подход.
И я могу представить, сколько гневных комментариев я получу, если оставлю только один вышестоящий абзац. Дайте мне пояснить, что я хочу сказать. Мы никогда не должны забывать видение клиента. Иногда разработчики используют технологии или навязывают другие инженерные изыски только лишь ради правильных подходов. Но запомните, если это не добавит ценности клиенту, выбросьте их.6. Программа, изложенная на бумаге не работает Я уверовал, что если я изложу всю свою программу на бумаге и потом перенесу ее в компьютер, то она не будет работать. Процесс разработки ПО сложен и невозможно учесть все зависимости и ветвления, пока вы не «запачкаете руки». Дизайн и планирование очень помогают, но не делайте это очень тщательно. И не принимайте диаграмму за договор. 7. Меньше — лучше Или можно сказать по-другому — лучшее враг хорошего. Выкидывайте то, что не нужно. Ибо все что может сломаться — ломается. 8. Кодирование занимает 20% времени Будьте готовы потратить 80% на обдумывание, отладку, тестирование, встречи, разговоры… Другие виды деятельности тоже важны и вам следует учиться не только техническим навыкам, чтобы стать хорошим разработчиком. 9. Заказчик НИКОГДА не знает, что он хочет Заказчики имеют необходимость, идею, но они не знают деталей. Разработка ПО вся состоит из определения деталей и устранения неопределенностей, и в конеце концов из преобразования идей в код. 10. Кто-то это уже делал Не изобретайте колесо, используйте Google или еще лучше — спросите коллег. Наверняка они уже делали аналогичные или похожие вещи. Бонусный пункт! Эй! А ведь наша работа клевая!
|
