Відповіді:
Завжди є кращий спосіб написати свій код.
Незалежно від того, наскільки відмінно ви знайдете написаний вами код, ви здивуєтеся, як це погано, якщо переглянете його через кілька років. Просто тому, що за кілька років до цього ви не знали про деякі зразки, які ви знаєте сьогодні, чи якісь мовні особливості, яких ви навчилися тим часом тощо.
Подумайте, перш ніж розпочати кодування.
Немає нічого більш постійного, ніж тимчасові рішення :)
Якщо вирішити проблему дуже важко, швидше за все, сама проблема погано поставлена з самого початку.
Ваше програмне забезпечення буде жити значно довше, ніж ви думаєте, що буде в той момент, коли ви його пишете.
Я почав свою кар’єру в 80-х. Я почав розробляти програмне забезпечення, яке виникло в 70-х роках і все ще використовувалося в 90-х (можливо, довше, я не знаю напевно його долі). Деякі з моїх власних кодів з відкритим вихідним кодом проходять на півдорозі другого десятиліття.
Робота з іншими дуже важлива.
"Покажіть мені своє" Іди до хлопця ", і я покажу тобі свою проблему"
Герої кодери Slapdash - ті, хто просто викручує код, не враховуючи умовності, читабельності або будь-якого іншого, що працює - може принести більше шкоди, ніж користі.
Не кажучи про те, що люди, які можуть написати тонни хорошої якості коду, - це погана річ. Просто рідкісний.
Вивчення нових мов - частина роботи
Я дізнався про чотири мови програмування в школі ще в 80-х, але використовував одну з них у роботі. У мене було чотири робочі місця, де я навіть не знав мови, якою я був найнятий.
Загалом, я навчився і професійно використовував десяток мов у своїй кар’єрі, включаючи FORTRAN, c, c ++, c #, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript і кілька невеликих DSL. Займаючись невеликою математикою, я, мабуть, використовую нову мову кожні пару років, хоча багато перетинається.
Якщо щось було постійною моєю кар’єрою, це зміни.
Програмне забезпечення ніколи не є повноцінним.
Завжди є якісь зміни в вимогах, удосконаленнях, виправлення помилок, з якими потрібно бути готовим впоратися. Таким чином, будьте гнучкими та приймайте той факт, що "software is never complete"завжди має місце для вдосконалень.
Продовжуйте вчитися кожен день. Знання сьогодні завтра застарілі.
За іронією долі ця відповідь має бути застарілою і завтра. Але насправді вивчіть важко один-два речі та отримайте сертифікацію, якщо це можливо, будьте Богом цих речей (можливо, мови програмування чи адміністрування системи / мережі / бази даних) і завжди слідкуйте за іншими незначними речами, як інші мови, не важливі для ти.
Я маю на увазі, наприклад, бути приголомшливим професіоналом адміністрування БД Java та Oracle, але вивчіть трохи Python, PHP, C ++, HTML5, Javascript, хоча ні до рівня сертифікації. Вивчіть усі існуючі в Інтернеті чи мовні рамки. Вивчіть або спробуйте мати деякий (базовий) досвід роботи з кожною наявною базою даних, як SQL Server, MySQL, Cassandra, HBase, PostgreSQL, і весь світ No-SQL, як MongoDB і CouchDB. Спробуйте мати певний досвід роботи з адміністрацією та віртуалізацією Linux.
Це найбільший урок, який я дізнався зі свого 16-річного досвіду. Я майже 10 років був одномовним програмістом, використовуючи Pascal у свою епоху, Visual Basic 6 на початку тисячоліття, і розробник PHP з 9 років тому. Але з того часу я дізнаюся, що розробникам потрібно знати хоч трохи про все.
Я дізнався, що найкращий принцип дизайну - це KISS (Нехай це буде просто, дурне!) .
Я дізнався, що основним завданням має стати збереження вашого коду простим та чистим, і кожен член команди повинен розуміти, який у вас код. The KISS principleстверджує, що більшість систем працюють найкраще, якщо їх просто, а не складно, тому простота повинна бути ключовою метою дизайну, а зайвих складностей слід уникати.
Немає спроб
Скажімо, у вас є завдання або купа завдань, які, як передбачається, займуть 4 дні. Тоді ваш начальник або керівник проекту запитує, чи можете ви спробувати зробити це через два дні з якоїсь важливої причини. Бажаючи бути добрим, гнучким працівником, ви можете спокусити сказати: впевнений, ви можете спробувати. Найімовірніші результати цього полягають у тому, що ви або пропустите кінцевий термін, або збираєтесь зробити хакерство на півдорож, щоб це зробити. І це не вина вашого начальника в тому, що він попросив вас це зробити, це його робота. Вина, що ви не сказали "ні", це ваша робота.
Ви не можете торгуватися з часом. Ви можете торгуватися з розмахом. Будьте професійними і не продайте себе коротко.
Написати код легко. Читання коду складно. Навіть якщо код ваш. Тому, коли це можливо, ідіть на читабельний підхід.
Ви не розумніші за інших. Ніколи не думайте, що ваш підхід найкращий тільки тому, що ваш.
Зверніть увагу на те, що сказано, а не про кого сказано. Блискучі ідеї можуть прийти для найнесподіваніших джерел.
Не лінуйся. Знайдіть свій час, щоб написати приємний код. Вам доведеться це все-таки виправити за більшу ціну.
Не використовуйте модні функції OOP лише тому, що можете! - ЯГНІ (вам це не знадобиться)
Use fancy OOP featuresоскільки вони мають конкретну, наочну користь для проблеми, яку ви намагаєтеся вирішити . Ти смієшся, але я це бачу весь час. Більшість програмістів ніколи не зустрічали об'єкт, який їм не сподобався. Я думаю, що має бути навпаки: ці методи винні, поки не будуть доведені невинні в суді KISS .