Що повинен знати кожен програміст про програмування?

Будь ласка, не зупиняйтесь на технічних питаннях , уникайте поведінки, культурних, кар'єрних чи політичних питань.

1. Помилка знаходиться у вашому коді, а не у компіляторі чи бібліотеках виконання.

2. Якщо ви бачите помилку, яка не може статися, перевірте, чи правильно ви створили та розгорнули програму. (Особливо, якщо ви використовуєте складний IDE або будуєте фреймворк, який намагається приховати від вас брудні деталі ... або якщо ваша збірка включає багато ручних кроків.)

3. Одночасно / багатопотокові програми важко записати і важче правильно перевірити. Найкраще делегувати стільки, скільки можливо, для сумісності бібліотек та фреймворків.

4. Написання документації є частиною вашої роботи програміста. Не залишайте це для когось іншого.

EDIT

Так, моя точка №1 завищена. Навіть найкращі інженерно-прикладні платформи мають свою частку помилок, і деякі з менш добре інженерних платформ наповнюються ними. Але навіть в цьому випадку , ви завжди повинні підозрювати код першим , і тільки починаєте звинувачувати компілятор / бібліотеки помилок , коли у вас є чіткі докази того, що ваш код не винне.

Ще в ті часи, коли я займався розробкою C / C ++, я пам’ятаю випадки, коли нібито «помилки» оптимізатора виявилися завдяки мені / деякому іншому програмісту, який робив речі, за якими мовна мова говорить, що не мають визначених результатів. Це стосується навіть безпечних мов, таких як Java; наприклад, довго погляньте на модель пам'яті Java (JLS, глава 17).

• Як читати код інших людей.
• Код не існує, якщо його не встановлено в Системі контролю версій.

Розрахунки з плаваючою комою не є точними.

Не припиняйте вчитися.

Те, що # 1, що ви можете зробити для підвищення якості та ремонтопридатності вашого коду, - ЗНИЖЕННЯ ДУПЛІКАЦІЇ.

Усунення несправностей та налагодження навичок

Вони навряд чи витрачають час на цю тему на будь-якому з курсів програмування, які я взяв, і, на мій досвід, це одне з найбільших визначень того, наскільки продуктивний програміст. Вам подобається чи ні, ви витрачаєте набагато більше часу на фазі обслуговування свого додатка, ніж на новій фазі розробки.

Я працював з soooooo багатьма програмістами, які налагоджували випадкові зміни речі, не маючи стратегії пошуку проблеми. Я мав цю розмову десятки разів.

Інший програміст: Я думаю, що ми повинні спробувати дізнатися, чи це це виправляє.
Я: Гаразд, якщо припустити, що це все виправить. Що це говорить про те, де джерело проблеми?
Інший програміст: Я не знаю, але треба щось спробувати .

1. Не будьте розумні; бути чітким.
2. Використовуйте перед повторним використанням.
3. Імена мають значення.
4. Функція робить 1 річ і робить це добре.
5. Мале краще, ніж велике.

Основи. В даний час програмісти вивчають технології, а не поняття. Це неправильно.

Кожен програміст повинен знати, що він постійно вводить припущення в код, наприклад, "це число буде позитивним і кінцевим", "цей код зможе підключатися до сервера весь час за мить".

І він повинен знати, що він повинен готуватися, коли ці припущення порушуються.

Кожен програміст повинен знати про тестування.

Вивчіть поняття . Ви можете надати Google синтаксис.

Критичне та логічне мислення. ви не можете зробити нічого доброго без цього.

Тестування одиниць. Це чудовий спосіб кодифікувати свої припущення щодо використання коду.

Абсолютний мінімум кожен розробник програмного забезпечення абсолютно, позитивно повинен знати про набори Unicode та символів (без виправдань!) .

Це важче, ніж ти думаєш.

Хоча легко скласти щось, що працює при нормальному використанні, справляючись з помилковим введенням, усі крайові та кутові випадки, можливі режими відмови тощо, забирає багато часу, і, ймовірно, буде найважчою частиною роботи.

Тоді ви також повинні зробити додаток теж добре.

Знання домену. Специфікація ніколи не є 100%; знаючи фактичний домен, для якого ви розробляєтесь, ВЖЕ ВИЩЕ підвищить якість продукту.

Велика нотація O та її наслідки.

Кілька корисних посилань

• http://www.perlmonks.org/?node_id=227909
• http://www.programmerinterview.com/datastruct/big-o-notation-example.php
• http://en.wikipedia.org/wiki/Big_O_notation

Покажчики, очевидно. :)

Code Complete 2 - обкладинка для обкладинки

Дані важливіші за код.

Якщо ваші дані розумні, код може бути німим.

Тупий код легко зрозуміти. Так само розумні дані.

Майже кожне алгоритмічне горе, яке я коли-небудь відчував, було пов’язане з тим, що дані знаходяться в неправильному місці або зловживають його справжнім значенням. Якщо ваші дані мають значення , введіть це значення в систему типів .

Яка мова та середовище найбільше підходять для роботи. І це не завжди ваш улюблений.

Розділяй і володарюй. Зазвичай це найкращий спосіб вирішити будь-який тип практичної проблеми від планування до налагодження.

Справжня майстерність знаходить своє відображення в здатності добре виконати просту конструкцію, а не в умінні зробити складну дизайнерську роботу.

Ця майстерність походить від більшого оволодіння основами, а не в оволодінні таємницею. Висококаліберний програміст не визначається їх здатністю кодувати те, що не можуть інші (використовуючи функції вищого рівня, вдосконалене функціональне програмування, що-у вас є), а скоріше своєю здатністю досконало просвічувати кодування. Вибір відповідного розкладу функціональності між класами; нарощування в міцності; використання прийомів оборонного програмування; і використовуючи шаблони та назви, які призводять до розширення самодокументації, це хліб та масло високого калібру програмування.

Написання хорошого коду, до якого ви чи хтось інший, можете повернутися через тиждень на місяць чи рік і зрозуміти, як використовувати, змінювати, вдосконалювати чи розширювати цей код є надзвичайно важливим. Це економить ваш час та розумові зусилля. Це змащує колеса продуктивності, видаляючи дорожні пробки, на які ви б натрапили раніше (можливо, перервавши свій потяг думок, або, можливо, відвезете години чи дні зусиль від іншої роботи тощо). Це полегшує концентрацію уваги на важких проблемах. , а іноді це робить важкі проблеми.

Одним словом: елегантність. Кожен клас, кожен метод, кожна умова, кожен блок, кожна назва змінної: прагніть до елегантності.

Ніколи не звинувачуйте користувача в тому, що можна виправити за допомогою більш чистого досвіду користувача чи кращої документації. Часто програмісти автоматично припускають, що користувач - ідіот, який нічого не може зробити правильно, коли проблема - поганий загальний досвід або відсутність спілкування. Програми мають бути використані, а ставитись до користувача з презирством - це в першу чергу пропустити точку програмування.

Кожен програміст повинен знати, як користуватися налагоджувачем, і знати, як його добре використовувати .

Структури даних

Як користуватися Google

Оцінка короткого замикання, але, мабуть, це одне з перших, чого вони навчають вас про булі операторів.

Як точно оцінити, скільки часу піде на реалізацію функції. Що ще важливіше, як донести, що ти не байдикуєш, коли подаєш цю оцінку.

Має значення стиль кодування:

• питання послідовного відступу,
• послідовне використання пробілу (наприклад, навколо операторів) має значення,
• послідовне розміщення {} s питань,
• правильно вибрані ідентифікатори мають значення,
• тощо.

... і хороший дизайн має значення.

В ідеалі програміст дізнається ці речі до (або під час) свого першого перегляду коду. У гіршому випадку програміст дізнається їх, коли начальник каже йому / їй поспішати вносити якісь нетривіальні зміни в якийсь жахливий код.